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
Neither was GCC's choice random, as I'm sure you'll agree.
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.
It's a question which is impossible to ever answer in the negative -- there always _may be_ any sort of terrible software implemented out there, somewhere. But, I do doubt any such relevant compilers actually exist.
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...
#define NULL nullptr is standards-valid in c++11 and later, but would be an unfortunate choice to make. Both in terms of breaking working code (code which is making unportable assumptions, granted), but also in terms of breaking ABIs on valid code: changing the type from long to decltype(nullptr) changes mangling, etc.
If you really wanted to push for that, I'd recommend starting a discussion on the gcc or clang lists -- the libc list doesn't really seem a place most likely to find C++ experts to help evaluate the pros and cons of making such a change. Certainly that all such C++ experts had previously decided it would be a bad idea to do so doesn't necessarily mean it's still the wrong thing, but it should at least be considered a strong signal...