[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHqcrtM_r-pnDeQf31Lng2n732No5Vc-JPB7w7CM4+jYVA@mail.gmail.com>
Date: Wed, 10 Jul 2019 13:35:35 -0400
From: James Y Knight <jyknight@...gle.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Define NULL as __null in C++ mode when using GCC
or Clang.
On Wed, Jul 10, 2019 at 12:45 PM Rich Felker <dalias@...c.org> wrote:
> 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@...hat.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...
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
