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

[Richard Smith]

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>.

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/361c82f9/attachment.html>