Re: [PATCH] Define NULL as __null in C++ mode when using GCC or Clang.

[Rich Felker <dalias@libc.org>]

On Wed, Jul 10, 2019 at 12:18:11PM -0400, James Y Knight wrote:
> On Wed, Jul 10, 2019 at 2:34 AM Florian Weimer <fweimer@redhat.com> wrote:
> 
> > * Szabolcs Nagy:
> >
> > > it is clear that 0L is a conforming definition for all
> > > conforming c++ compilers.
> > >
> > > it is less clear if __null is so in all compilers that
> > > define __GNUC__.
> >
> > Why wouldn't something like this be valid for current C++ versions?
> >
> > static inline constexpr decltype(nullptr) __null{};
> > #define NULL __null
> >
> > I don't see a requirement that NULL must be an expression that can be
> > evaluated by the preprocessor.
> 
> 
> Is this just for the purposes of argument, or, why would you want to do
> that? More sanely, yes, `#define NULL nullptr` would now also be a
> conforming definition, but that is an undesirable change in practice for a
> variety of compatibility reasons. Toolchains have remained with `#define
> NULL __null`, and seem likely to continue to do so indefinitely.
> 
> I feel like this thread is kinda going off on a tangent now. Inventing new
> and unique ways to define NULL in C++ doesn't really seem a useful thing to
> do be doing here...

Well "do it the same way GCC's headers did it" isn't useful because
we're not using GCC's headers. If there's a definition that's
preferable to what we have now, it should stand on its own as a better
(or at least better in some ways that we decide are good trade-offs)
choice. The current definition was chosen that way, not just at
random, as you can see from the commit history.

musl explicitly does not use, require, or support the use of
standard-namespace-conflicting headers (as opposed to extensions like
vector intrinsics) shipped with the compiler, and supports as wide a
range as possible of compilers -- for building musl itself, ones
implementing a minimal subset of "GNU C", and for compiling against
musl, an even more minimal subset that can be "faked" with just some
macros if needed. So whether there are or may be "GNU C++" compilers
that lack __null is a valid question. My leaning would kinda be to use
nullptr in recent C++ versions and retain 0L for old ones if nullptr
is a valid definition in new C++ versions, but I still wonder if
having use of NULL "break maximally" isn't a better behavior with
respect to ending its use...

Rich