linux-kernel - Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d9ab212-6c80-f7fa-4be5-87b567ada949@redhat.com>
Date:   Tue, 25 Apr 2017 15:22:00 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Carlos O'Donell <carlos@...hat.com>, linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>, linux-api@...r.kernel.org,
        musl@...ts.openwall.com, Rich Felker <dalias@...ifal.cx>
Subject: Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of
 uapi definitions

On 03/09/2017 01:14 AM, Szabolcs Nagy wrote:
> the other way (linux header included first) is
> problematic because linux headers don't follow
> all the standards the libc follows, they violate
> namespace rules in their struct definitions, so
> the libc definitions are necessarily incompatible
> with them and thus different translation units can
> end up refering to the same object through
> incompatible types which is undefined.
> (even if the abi matches and thus works across
> the syscall interface, a sufficiently smart
> toolchain can break such code at link time,
> and since the libc itself uses its own definitons
> that's what user code should use too).

I don't think this is relevant in this context.  LTO implementations 
have to deal with this already.  For glibc's sake alone, it must be 
supported to link together code using differing feature test macros.

Thanks,
Florian