Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 1916 bytes --]

On Wednesday 16 January 2013 13:57:44 David Miller wrote:
> From: Mike Frysinger <vapier@gentoo.org>
> > certainly true, but the current expectation is that you don't mix your
> > ABIs. if you're programming with the C library API, then use the C
> > library headers. if you're banging directly on the kernel, then use the
> > kernel headers.  not saying it's a perfect solution, but it works for
> > the vast majority of use cases.
> 
> This isn't how real life works.
> 
> GLIBC itself brings in some of the kernel headers, as do various library
> headers for libraries other than glibc.
> 
> So you can get these conflicting headers included indirectly, and it is
> of no fault of any of the various parties involved.

the headers glibc includes tend to be pretty stand alone specifically so that 
it doesn't matter

> We have to make them work when included at the same time somehow, and
> this is totally unavoidable.

"them" is vague.  saying that every kernel header has to be usable in the same 
compilation unit as every C library header regardless of order is unrealistic 
(at least it is today).  there are cases where they define the same structure 
different because the structure as the C library expects is different from what 
the kernel syscall expects.  you could avoid that on the kernel side by giving 
them all prefixes (like __kernel_), but that didn't seem entirely palpable to 
the kernel folks.  i couldn't even get them to remove crap that breaks non-
glibc C libraries (e.g. uapi/linux/stat.h -- looks like someone inadvertently 
fixed uapi/linux/socket.h finally).

for many networking headers, the C library will provide enums & defines while 
the kernel only provides enums.  including the kernel after the C library one 
leads to parsing errors as the defines expand in the enum and kill it.  like 
linux/in.h and netinet/in.h and IPPROTO_*.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]