[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Oct 2012 19:15:53 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Clash between 'netinet/if_ether.h' and 'linux/if_ether.h'
On Tue, Oct 09, 2012 at 04:13:43PM -0700, Isaac Dunham wrote:
> > It's a bug to be including linux/if_ether.h, and there's no way to
> > work around this without depending on kernel headers, which musl will
>
> Patch that does work around it:
>
> -#ifndef _NETINET_IF_ETHER_H
> +/* Check for <linux/if_ether.h> - _LINUX_IF_ETHER_H will also work */
> +#if !defined(_NETINET_IF_ETHER_H) || !defined(ETH_ALEN)
> #define _NETINET_IF_ETHER_H
> +#define _LINUX_IF_ETHER_H /* linux/if_ether.h defines the same stuff */
That is a clever workaround, but the way it's written it breaks
include-guard heuristics. Instead, it should be..
#ifndef _NETINET_IF_ETHER_H
#define _NETINET_IF_ETHER_H
#ifndef ETH_ALEN
...
#endif
#endif
But does it work the other way around, i.e. if <netinet/if_ether.h> is
included first?
I'd still rather just press upstream to fix this stupid bug if we can.
This is the kind of thing that only affects a small number of broken
applications, and as such, I really question whether it merits ugly
workarounds.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
