On Mon, Apr 28, 2014 at 5:39 PM, Richard Smith <rich...@metafoo.co.uk>wrote:
> As far as I can see, if one of the __need_FOO macros is defined, glibc
> expects <stddef.h> to provide *only* FOO, and not any of the other pieces
> of <stddef.h>, so I don't think this patch is entirely right. It's also not
> complete -- we should also handle FOO in the set {wchar_t, size_t,
> ptrdiff_t, wint_t}.
>
> The intent appears to be to support libc headers such as <stdlib.h> (which
> provides NULL and size_t, but is *not* allowed to provide any of the other
> parts of <stddef.h>), and *not* to recover from the <linux/*>, <asm/*>,
> etc. headers breaking the definition of NULL. I can see no evidence of any
> header including the broken NULL definition and trying to fix it, only
> headers asking for subsets of <stddef.h>.
>
The commit message of
https://sourceware.org/git/?p=glibc.git;a=commit;h=6e502e19455c6110dd4487d91b7b7d6d8121f9bais
evidence I think.
> So... I'm not opposed to this patch, if it does the right thing, but I
> don't think it's a (complete) solution to the problem of getting a bad
> definition of NULL from <linux/stddef.h>.
>
>
> On Mon, Apr 28, 2014 at 1:45 PM, Chandler Carruth <chandl...@google.com>wrote:
>
>>
>> On Mon, Apr 28, 2014 at 1:16 PM, Nico Weber <tha...@chromium.org> wrote:
>>
>>> On Mon, Apr 28, 2014 at 1:05 PM, Reid Kleckner <r...@google.com> wrote:
>>>
>>>> Even if we commit this workaround, can we report this as a bug to
>>>> upstream Linux?
>>>>
>>>
>>> As mentioned above, I'm guessing Linux probably doesn't want to depend
>>> on C standard headers, so they wouldn't see this as a bug in Linux.
>>>
>>
>> Just FYI, there is a more subtle distinction here.
>>
>> Linux probably wants to not depend on a C standard library. But stddef.h
>> and the definition of NULL is actually available even in a *freestanding*
>> implementation of C which has no standard library. It's required to be
>> provided by the compiler. As such, I actually think Linux would be OK with
>> including stddef.h from a technical perspective. Any barrier here would be
>> historical or political.
>>
>> That said, either historical or political barriers would be barriers all
>> the same, and more pressingly we can't retroactively change all of the
>> existing linux kernel headers and glibcs deployed around the world and
>> trying to use Clang. So suggesting *only* changing either Linux or glibc is
>> a non-starter. We need to both change Clang to work around this, and (where
>> we can) suggest to the upstream communities a more clean solution.
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
