Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
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?
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.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.