From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14378 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: James Y Knight Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Define NULL as __null in C++ mode when using GCC or Clang. Date: Wed, 10 Jul 2019 13:35:35 -0400 Message-ID: References: <20190709193826.GR1506@brightrain.aerifal.cx> <20190710020357.GI21055@port70.net> <871ryycs9n.fsf@oldenburg2.str.redhat.com> <20190710164446.GS1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000832a0c058d571c7c" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="260788"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14394-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 10 19:36:21 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hlGVw-0015hO-Ib for gllmg-musl@m.gmane.org; Wed, 10 Jul 2019 19:36:20 +0200 Original-Received: (qmail 9857 invoked by uid 550); 10 Jul 2019 17:36:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9835 invoked from network); 10 Jul 2019 17:36:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=grxTiIjXO5QWwItsMtmYbOCYlX3uIZPL23UIdUjyRqQ=; b=CxeUEaPVOs7wP37tZkvz3YlD80swhzBvl73ILkLpvGpkKoPuBrt/Hnx7eI7fIau8+L PS2CUdJfyImx0JwnrlXXmR06rWDxggJk0f4b8a1f+spYGiwnEHyG8PocnA8ktS24f7vv 3kBnCmhoqJmVkZz8JU1R4LATpBAabfpIL+t7aQGIcbRSYIq4HIvRpcKv0Zs7e0xyaCBc WhduC6tJN3MLrkKIqAdOxB0jbnJyUlCe5WA1RVbqRRbpQ+m7IEgZRSyieoVRpJ1PIShr T6omfrxGlhLDXf9pY+z/CTOyxF5BrVk9edEzs7k6rMnrJYpPjK71cheBqMSIC9VWK9lc NjPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=grxTiIjXO5QWwItsMtmYbOCYlX3uIZPL23UIdUjyRqQ=; b=mmI6FQmcPjQbkT6n18LxnQiGltDn5WHSwdH55yEtn2L3z1XheE6pLu7rjP5zoRxSVr lFSPhhP4J8VCs5hYM+wojq6+UxbX5jji+mnCG9ES7x6lZvYMFTbypEGKLjD0r/e/ZCNv yUDDYOLt33y218jRDpruMiilWo6kmI5TGNAG7GCymnr3AvOropp3icj/c7ezCSkJLAn8 OnY55i6J5UZ29T1sZK6nDa8BgXQRAOJ+R6ezlUNTLljWNMUXrE1N1nSc+aAC6wTUTD5I cEq+MnjCmegU1HchCz3+IOKQguxLbPnT0J06zhBxj/ZNo9cjZzovjs3I/+b9UlC5udlR PMhw== X-Gm-Message-State: APjAAAVjPhPkWg693aFI3H9PIiXZhYgDHNSdETrPy1lwYEDFNZlnIZCU Lx8iB557hu45/aAiDAsBBH9N7eyF8Scbrb2YhGJm2C/8Y8U= X-Google-Smtp-Source: APXvYqz2UpAJHOoivqLv66flDa+3vOCP2OPeFu1dHlxmM+Qw7k+mHJ/SDZeecHX6Qc97niEjjNY4JghspvLLcMskHgQ= X-Received: by 2002:a67:db89:: with SMTP id f9mr17459132vsk.150.1562780163539; Wed, 10 Jul 2019 10:36:03 -0700 (PDT) In-Reply-To: <20190710164446.GS1506@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14378 Archived-At: --000000000000832a0c058d571c7c Content-Type: text/plain; charset="UTF-8" On Wed, Jul 10, 2019 at 12:45 PM Rich Felker 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 > 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... --000000000000832a0c058d571c7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 10, 2019 at 12:45 PM Rich= Felker <dalias@libc.org> wrot= e:
On Wed, Jul 1= 0, 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++ ver= sions?
> >
> > static inline constexpr decltype(nullptr) __null{};
> > #define NULL __null
> >
> > I don't see a requirement that NULL must be an expression tha= t can be
> > evaluated by the preprocessor.
>
>
> Is this just for the purposes of argument, or, why would you want to d= o
> that? More sanely, yes, `#define NULL nullptr` would now also be a
> conforming definition, but that is an undesirable change in practice f= or a
> variety of compatibility reasons. Toolchains have remained with `#defi= ne
> 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 usef= ul 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

<= div>Neither was GCC's choice random, as I'm sure you'll agree.<= /div>

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 again= st
musl, an even more minimal subset that can be "faked" with just s= ome
macros if needed. So whether there are or may be "GNU C++" compil= ers
that lack __null is a valid question.

It= 9;s a question which is impossible to ever answer in the negative -- there = always _may be_ any sort of terrible software implemented out there, somewh= ere. But, I do doubt any such relevant compilers actually exist.
=
My leaning woul= d 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 NU= LL nullptr is standards-valid in c++11 and later, but would be an unfortuna= te choice to make. Both in terms of breaking working code (code which is ma= king unportable assumptions, granted), but also in terms of breaking ABIs o= n valid code: changing the type from long to decltype(nullptr) changes mang= ling, etc.

If you really wanted to push for t= hat, I'd recommend starting a discussion on the gcc or clang lists -- t= he libc list doesn't really seem a place most likely to find C++ expert= s to help evaluate the pros and cons of making such a change. Certainly tha= t 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...
--000000000000832a0c058d571c7c--