mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] Define NULL as __null in C++ mode when using GCC or Clang.
Date: Wed, 10 Jul 2019 16:45:20 -0400	[thread overview]
Message-ID: <20190710204520.GU1506@brightrain.aerifal.cx> (raw)
In-Reply-To: <ABBDF625-5B9D-4CB5-AEC3-41A7B0DB7E74@adelielinux.org>

On Wed, Jul 10, 2019 at 03:11:30PM -0500, A. Wilcox wrote:
> On Jul 10, 2019, at 12:35 PM, James Y Knight <jyknight@google.com> wrote:
> > 
> > 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.
> 
> Or, put another way, it has always seemed to me that one of musl's
> tenets is to "fail fast and break hard" on egregiously invalid code.

Code != compilers. We do judge egregiously bad compilers on failing to
conform to the documented standards, but there really is no standard
for what is "GNU C" (or "GNU C++") except "GCC". The intent has always
been clear to require the minimal subset of this needed to work, so
that other current and future compilers can be usable without having
to clone all of GCC. It's a matter of reducing the barrier to entry,
which is already way too high.

> I'd argue "pretending to be GNU C++ and not having __null" is much
> more egregious than "code still using NULL in C++". Therefore it's
> better to break the invalid compiler (which could have any number of
> other bugs) than break the C++ code.

"Still using NULL in C++" is bad style but valid. Making assumptions
that it's valid for terminating variadic lists or that it will have a
type that causes particular overloads to get called is what's not
valid.

Rich


  parent reply	other threads:[~2019-07-10 20:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 19:19 James Y Knight
2019-07-09 19:38 ` Rich Felker
2019-07-09 23:04   ` James Y Knight
2019-07-10  2:03     ` Szabolcs Nagy
2019-07-10  6:34       ` Florian Weimer
2019-07-10  8:46         ` Szabolcs Nagy
2019-07-10 16:18         ` James Y Knight
2019-07-10 16:44           ` Rich Felker
2019-07-10 17:35             ` James Y Knight
2019-07-10 20:11               ` A. Wilcox
2019-07-10 20:19                 ` Michael Everitt
2019-07-10 20:45                 ` Rich Felker [this message]
2019-07-10 20:48               ` Rich Felker
2019-07-10 21:11                 ` Szabolcs Nagy
2019-07-10 21:16                   ` Rich Felker
2019-07-10 21:44                     ` Szabolcs Nagy
2019-07-10 16:01       ` James Y Knight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190710204520.GU1506@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).