Re: Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing]

[Denys Vlasenko <vda.linux@googlemail.com>]

On Tue, Oct 13, 2015 at 5:05 PM, Rich Felker <dalias@aerifal.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.