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: 2898 bytes --]

On Wednesday 16 January 2013 12:10:11 Ben Hutchings wrote:
> On Wed, 2013-01-16 at 12:04 -0500, Mike Frysinger wrote:
> > On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:
> > > On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
> > > > Cong Wang wrote:
> > > > > (Cc'ing some glibc developers...)
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > In glibc source file inet/netinet/in.h and kernel source file
> > > > > include/uapi/linux/in6.h, both define struct in6_addr, and both are
> > > > > visible to user applications. Thomas reported a conflict below.
> > > > > 
> > > > > So, how can we handle this? /me is wondering why we didn't see this
> > > > > before.
> > > 
> > > [...]
> > > 
> > > > This is not a new issue.  In addition to this,
> > > > netinet/in.h also conflits with linux/in.h.
> > > > 
> > > > We might have
> > > > 
> > > >  #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
> > > >  
> > > >  #endif
> > > > 
> > > > around those conflicting definitions in uapi/linux/in{,6}.h.
> > > 
> > > This only solves half the problem, as <netinet/in.h> might be included
> > > after <linux/in.h>.  Also, not all Linux userland uses glibc.
> > 
> > certainly true, but the current expectation is that you don't mix your
> > ABIs.
> 
> Whose expectation?  Which ABIs are being mixed?

the kernel's view of the world and the C library's view of the world.  there 
is a lot of overlap, but it's the C library's job to provide a POSIX compliant 
interface (and then some).

obvious examples:
 - the stat structures are not the same and require translation
 - ptrace structures are not the same and you really need to use the C lib one
 - the readdir function is completely different

but to this specific question, if you're calling the kernel's network functions 
directly, then you need to include the kernel's headers for its definition of 
how things are passed.  if you're calling the C library's network functions, 
then use the C library's headers.

> > 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.
> 
> In practice most C programs for Linux will use a mixture of thinly
> wrapped system calls and higher-level APIs from the C library, and never
> really call the kernel directly (as that requires inline assembler).
> Userland programmers will work around this historical mess by tweaking
> the #include order or splitting source files.  But they shouldn't have
> to.

if you're not calling the kernel directly, why are you including the kernel 
headers ?  what is the problem people are actually trying to address here (and 
no, "i want to include both headers" is not the answer) ?
-mike

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