<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 28, 2014 at 7:11 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Apr 28, 2014 at 5:45 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>

> On Mon, Apr 28, 2014 at 5:39 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
> wrote:<br>
>><br>
>> As far as I can see, if one of the __need_FOO macros is defined, glibc<br>
>> expects <stddef.h> to provide *only* FOO, and not any of the other pieces of<br>
>> <stddef.h>, so I don't think this patch is entirely right. It's also not<br>
>> complete -- we should also handle FOO in the set {wchar_t, size_t,<br>
>> ptrdiff_t, wint_t}.<br>
><br>
><br>
> wint_t is already handled, right below the lines my patch touches (and in<br>
> the same way as in my patch). The others don't seem to be needed at the<br>
> moment, so I'd omit them from now.<br>
<br>
</div>Sounds like I misunderstood Richard's reply to this on IRC and he<br>
thought this was less convincing than I did :-)<br>
<br>
For comparison, here are two other possible patches:<br>
<br>
* clang-neednull-2.patch changes things so that if __need_NULL is<br>
defined, stddef.h defines NULL and nothing else. It also changes<br>
stddef.h so that __need_win_t defines only wint_t and does nothing<br>
else – this latter part happens to break a test, so the patch also<br>
updates that test. As far as I can tell from inspection, the test<br>
wouldn't pass with gcc's stddef.h either, so this improves<br>
compatibility but it might break existing code.<br>
<br>
* clang-neednull-3.patch also adds support for the rest of FOO in the<br>
set {wchar_t, size_t, ptrdiff_t}.<br>
<br>
Let me know which one of the 3 patches (with 1 being the one I<br>
originally sent) you like best. If it's 3, I'll add a few more tests<br>
for that.</blockquote><div><br></div><div>I strongly prefer patch 3 over 2. (With just patch 2, I worry that some libc header would say "give me NULL and FOO", and just get NULL.)</div><div><br></div><div>Instead of repeating an 'ifdef _STDDEF_H_imp' test, could you define all the __need_* macros in the _STDDEF_H_imp section? I'd find that slightly easier to reason about.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>> The intent appears to be to support libc headers such as <stdlib.h> (which<br>
>> provides NULL and size_t, but is *not* allowed to provide any of the other<br>
>> parts of <stddef.h>), and *not* to recover from the <linux/*>, <asm/*>, etc.<br>
>> headers breaking the definition of NULL. I can see no evidence of any header<br>
>> including the broken NULL definition and trying to fix it, only headers<br>
>> asking for subsets of <stddef.h>.<br>
>><br>
>> So... I'm not opposed to this patch, if it does the right thing, but I<br>
>> don't think it's a (complete) solution to the problem of getting a bad<br>
>> definition of NULL from <linux/stddef.h>.<br>
>><br>
>><br>
>> On Mon, Apr 28, 2014 at 1:45 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On Mon, Apr 28, 2014 at 1:16 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
>>>><br>
>>>> On Mon, Apr 28, 2014 at 1:05 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
>>>>><br>
>>>>> Even if we commit this workaround, can we report this as a bug to<br>
>>>>> upstream Linux?<br>
>>>><br>
>>>><br>
>>>> As mentioned above, I'm guessing Linux probably doesn't want to depend<br>
>>>> on C standard headers, so they wouldn't see this as a bug in Linux.<br>
>>><br>
>>><br>
>>> Just FYI, there is a more subtle distinction here.<br>
>>><br>
>>> Linux probably wants to not depend on a C standard library. But stddef.h<br>
>>> and the definition of NULL is actually available even in a *freestanding*<br>
>>> implementation of C which has no standard library. It's required to be<br>
>>> provided by the compiler. As such, I actually think Linux would be OK with<br>
>>> including stddef.h from a technical perspective. Any barrier here would be<br>
>>> historical or political.<br>
>>><br>
>>> That said, either historical or political barriers would be barriers all<br>
>>> the same, and more pressingly we can't retroactively change all of the<br>
>>> existing linux kernel headers and glibcs deployed around the world and<br>
>>> trying to use Clang. So suggesting *only* changing either Linux or glibc is<br>
>>> a non-starter. We need to both change Clang to work around this, and (where<br>
>>> we can) suggest to the upstream communities a more clean solution.<br>
>>><br>
>>> _______________________________________________<br>
>>> cfe-commits mailing list<br>
>>> <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>