|
Date: Tue, 13 Oct 2015 20:02:47 +0200 From: Denys Vlasenko <vda.linux@...glemail.com> To: musl <musl@...ts.openwall.com> Cc: Aboriginal Linux <aboriginal@...ts.landley.net> Subject: Re: Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] On Tue, Oct 13, 2015 at 5:05 PM, Rich Felker <dalias@...ifal.cx> wrote: >> > > This would address the case where the kernel header is included first, >> > > but it's not a case I or most of the musl community wants to support, >> > > because there's no guarantee that the kernel's definitions of these >> > > structures will actually be compatible with use elsewhere in the libc >> > > headers, etc. >> > >> > If kernel's definition does not match yours, there is a much >> > bigger problem than "includes do not compile": >> > kernel and userspace definitions of these structs *must* match >> > (modulo harmless things like different typedef names for field types). >> > >> > So in this case either kernel or libc would need to be fixed. >> >> why? >> >> in practice most types are c abi compatible with the kernel >> because translating the types at the syscall boundary is >> painful/impossible. >> >> but even with compatible binary representation there is >> plenty space for disagreement between kernel and libc on >> the source level. (of course code that includes both libc >> and kernel headers might not care about posix namespace >> violations or undefined behaviour in kernel headers..) >> >> and libc-compat does not cover all conflicting cases >> (i assume they just add workarouds when somebody hits >> a conflict), e.g. sys/inotify.h and linux/inotify.h are >> in conflict (and linux/inotify.h is not even standard c). > > Indeed the problem here is source compatibility, not binary > compatibility. Issues like names of types, choice of distinct types > that have the same size and representation but which are not > compatible types (which make problems if you take the address of the > member, including possibly aliasing problems which are real-world > bugs), etc. It's not that bad in practice. In C, typedefs are not new types. uint16_t, u16 and __u16 are all just aliases to "unsigned short". You won't get a conflict because different typedefs were used to declare a struct member whose address you are taking and passing to some function. If signedness and width match, then it will work without casts or compiler errors.
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.