[patch] Let stddef.h redefine NULL if __need_NULL is set

[Nico Weber]

On Mon, Apr 28, 2014 at 5:39 PM, Richard Smith <richard at 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}.
>

wint_t is already handled, right below the lines my patch touches (and in
the same way as in my patch). The others don't seem to be needed at the
moment, so I'd omit them from now.


> 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>.
>
> 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 <chandlerc at google.com>wrote:
>
>>
>> On Mon, Apr 28, 2014 at 1:16 PM, Nico Weber <thakis at chromium.org> wrote:
>>
>>> On Mon, Apr 28, 2014 at 1:05 PM, Reid Kleckner <rnk at 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 at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140428/fa6029f2/attachment.html>