This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr


http://sourceware.org/bugzilla/show_bug.cgi?id=15850

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
In terms of "what do we lose?" I think the answers are:

1. People power that could be better spent elsewhere. Of course it's your right
to spend your time on what matters most to you, but glibc has a lot more
functional bugs than people to fix them all. Also, perhaps a bulk of the work
is initial support, but I suspect there will be some maintenance cost too,
which others may inherit having to deal with in the future.

2. Consistency of behavior. I would rather have the duplication of libc and
kernel headers result consistently in #error than have it work 99% of the time,
but sometimes fail when someone installs new kernel headers that weren't
properly tested.

The order-of-inclusion dependency is very bothering too. Presumably the reason
someone might include the kernel header is to get bleeding-edge things not yet
in the libc header. But if the kernel header's definitions are suppressed if
the libc version was included first, this means applications need to be very
careful to control the inclusion order, and it might get reversed if another
third-party header includes the libc header first.

I would much rather see:

#include <netinet/in.h>
#include <linux/extra_stuff_that_does_not_belong_in_in.h>

than having overlapping headers with subtle differences.

Aside from all of the above, my feeling is that history has shown that trying
to synchronize this kind of header issue, where a definition might have
different sources, is a nightmare. Think of things like the use of bool in
curses. Historically, the Linux headers have not been userspace-friendly, and
have been a source of header-incompatibility breakage, and I don't see the
value in doing anything that would encourage people to go back to using them
more...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]