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. > > You could say that it's a bug in glibc that they include headers that pull > in Linux's internal linux/stddef.h in glibc headers used by applications, > but based on previous interactions with glibc I would guess that their > reply would be "we do include this internal linux header, but we're careful > to define __need_NULL and re-include stddef.h to fix the issues caused by > that". (I'm happy to file a bug like this if you think it has a chance of > not being WontFixed immediately.) > I don't think they'll be responsive. > The test case you have shows how this definition of NULL is broken on >> x86_64, even in C with gcc: >> > > The Linux header does > > #if c++ > #define NULL 0 > #else > #define NULL (void*)0 > #endif > > so that should be fine (?) > Great, so they have a definition that follows the letter of the C++ standard, but not the intention. I doubt they will change their headers to be more C++-friendly. IIRC they were famous for using C++ keywords in headers in the past. Let's commit the workaround. It's what glibc wants.
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
