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