From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14376 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 12:18:11 -0400 Message-ID: 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: multipart/alternative; boundary="000000000000ad5427058d560755" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="201800"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14392-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 10 18:18:56 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 1hlFJ2-000qQ8-Hf for gllmg-musl@m.gmane.org; Wed, 10 Jul 2019 18:18:56 +0200 Original-Received: (qmail 20142 invoked by uid 550); 10 Jul 2019 16:18:52 -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 20116 invoked from network); 10 Jul 2019 16:18:51 -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=pc6BDNVUYcRFAs82/VH9tUnOStL0IOUSSX5wdAPGf/s=; b=t13w++Tg/SfG22uikTX+TBsoUsgqIJeFbPU4salAD9uY4XauO7cJ/yHnHgXLZyaSpW bR2omymJIHpUvAACkcmregWIncWDpguPg4yU+lDin71L5iKOvjyyWFsuyZk8/x9e2Wq3 j4ND11WcB5C6S215Iz6NqPOUINEv4sVfeJp00q9Tam/2njk9crUp38bYf7YKVw1UQUss 5Dk1eQ/J0MGH6NSkNNax4YDyp9wlQHY5Ha/JB03wUuJ7DeXzZPS+NA53pfVQ1HKFrlSW zMgbX53BO+wRsgQYSbHc/1YfIJiLci+KGzv/n7UflKG4+pqwxLxGmLQ3b2Z27TeT9F17 Oxfg== 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=pc6BDNVUYcRFAs82/VH9tUnOStL0IOUSSX5wdAPGf/s=; b=Gruukag7LFSOC2TwTZYCK6OwkhRxt4TJ984YiEVYCgf4chd2DfKTg59mZ55AQUJJZB UT+QAEIwtndSlr26cP8TIFRCI6UNaOp739AWTJtk58ddlQJOO+GoS7jtAqK8K8NhFynz XS/5047BfLJAd6UL9Lis3Fe9CelD/rS/Juh2681DWQ1HdwjGlf+rZZc69SS9Id4w8amb CkwGzNRIAIRu3BWnKLQTQRs6WaGFfASeEFFpKYWfFdWTmZgVR06WEXcQf825lb1oW7zF zHf6gtH06aGEt9biqYe9Qa5ksdZdpUUeIvoBqve5bD7OqwaVXN0S9TpMbNyi3YBqZuse UhjA== X-Gm-Message-State: APjAAAVx18LndGHomya7HCet5xmUbe9lZtHMQVUis7OMXER85VoXSW5B ghhZsjA7mUY7/aCiEJRi5jXDHJg9nPLS3MypPoS0/uTK0EE= X-Google-Smtp-Source: APXvYqyFyI+kun/kfhhxiQrFh3wrYwCljL2bZsdMDYs/Yd9Jukaab965PKDZyo9eulm/SSIoGfTxlVTJVPhD0czaTjw= X-Received: by 2002:a1f:1e47:: with SMTP id e68mr10805639vke.37.1562775519033; Wed, 10 Jul 2019 09:18:39 -0700 (PDT) In-Reply-To: <871ryycs9n.fsf@oldenburg2.str.redhat.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14376 Archived-At: --000000000000ad5427058d560755 Content-Type: text/plain; charset="UTF-8" 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... --000000000000ad5427058d560755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 10, 2019 at 2:34 AM Flori= an Weimer <fweimer@redhat.com&= gt; wrote:
* Sza= bolcs 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.

I= s 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 d= efinition, but that is an undesirable change in practice for a variety of c= ompatibility reasons. Toolchains have remained with `#define NULL __null`, = and seem likely to continue to do so indefinitely.

I feel lik= e 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...
--000000000000ad5427058d560755--