From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14377 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker 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 12:44:46 -0400 Message-ID: <20190710164446.GS1506@brightrain.aerifal.cx> References: <20190709193826.GR1506@brightrain.aerifal.cx> <20190710020357.GI21055@port70.net> <871ryycs9n.fsf@oldenburg2.str.redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="38884"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14393-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 10 18:45:05 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 1hlFiI-0009zE-Fw for gllmg-musl@m.gmane.org; Wed, 10 Jul 2019 18:45:02 +0200 Original-Received: (qmail 19514 invoked by uid 550); 10 Jul 2019 16:45:00 -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 19491 invoked from network); 10 Jul 2019 16:44:59 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14377 Archived-At: 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. 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