From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=sran=6F=gmail.com=jwakely.gcc@sourceware.org>
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	by sourceware.org (Postfix) with ESMTPS id E02723858C5F
	for <gcc-help@gcc.gnu.org>; Thu,  9 Feb 2023 17:52:52 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E02723858C5F
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-ej1-x631.google.com with SMTP id jg8so8763976ejc.6
        for <gcc-help@gcc.gnu.org>; Thu, 09 Feb 2023 09:52:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=wT6Gxu6P4eQpfX3lUCfCxPvfC4evvGko09L8Cz/fh4g=;
        b=OOTb0qLWxahSomg84QCxdmVM+JyoI7wCuhsTcQbWY3vckMv3Nf/f6WPyw1pMeyIsRg
         Fvhl9IkgVYXAvut+TJvnBpVlB5At3wYIDHa2+cwBc2mzyDfraEJwf8KCDcWsYEinTHWT
         SJ7D8CQWyb6tL2uP0IR1vTtdA2xIGMahq7dv2HG6y6PYwurBhb3Rf5sUpv55IRW4jGdy
         yzB4Yr/+UruRkwKx2Enp2+82YwZOVML332+0PK7d0UlEub05175H8q9Ru28189cWrW5X
         O/JY7aEF+xCiI70mzjpkL2TGeQBvmm8dwzXPp+XHm8NtoPsZwpglHfYIkGEM4cQCqzjN
         u7ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wT6Gxu6P4eQpfX3lUCfCxPvfC4evvGko09L8Cz/fh4g=;
        b=KSRlXxUv1gM7BzEiRtbz0EbbwDlqmvVwjfd+1jWtx+xyhNL8HRH+TsrCOkVWuHGvdx
         r/t2XwvV9JeW2rEnXWVFgs1iXL6EpcWg7wzuGOo4zEyoMjxX9gX9NLgtmiF1fcJIS5US
         xqS9p3zWN1N+nTcvUAhkaQS3rjmqF25LDmH9LGSqV3xB4cHUEMTxwF0nBaTPnJeGWnvT
         PClsM2sLnMZS9Q3dt/oEFUWypASDb9iO3eVrcm6F5QTd3DIJUZXo6Hb6td8hi+q8QuTq
         6RzHdlFo6Njnbj17q0Mp+VXucr/6pVyYnLFPP35goAimBUOQa0DXNlSrZc6u1dor0aoh
         H4tQ==
X-Gm-Message-State: AO0yUKU2eFeulepJcAzYzGZFSq9JeR6i1a0weELNEsTR8NsesMlG18cS
	NoXe24zWHUg7gDD0cBcbC0fMeJCPVqi7N9AcLXY=
X-Google-Smtp-Source: AK7set81bKV7a4lxbvg0qo2F5IOA4y0FTrf9q9oM6Wf/J1X7qjH5EvTbRJEcYjUPfVZ0ciVmPPA++FkWMftgy1tiVLw=
X-Received: by 2002:a17:906:90c1:b0:88f:9c9a:828 with SMTP id
 v1-20020a17090690c100b0088f9c9a0828mr2421152ejw.190.1675965171646; Thu, 09
 Feb 2023 09:52:51 -0800 (PST)
MIME-Version: 1.0
References: <7e6e3bbf-0dac-0632-0e8f-372bd32a6923@jguk.org>
 <CAH6eHdQes6i40QxByJ8NvzQnB9+Be+EwJs8t-jv+0+axeUzd3g@mail.gmail.com> <6e30ed8e6c6f08407a5b8259e73fd18a492376b5.camel@xry111.site>
In-Reply-To: <6e30ed8e6c6f08407a5b8259e73fd18a492376b5.camel@xry111.site>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Thu, 9 Feb 2023 17:52:40 +0000
Message-ID: <CAH6eHdR23=FG+a72JKdvFEd6ynR8XaR9kaNS5GouX5d=2J+s6Q@mail.gmail.com>
Subject: Re: std::string add nullptr attribute
To: Xi Ruoyao <xry111@xry111.site>
Cc: Jonny Grant <jg@jguk.org>, gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-help.gcc.gnu.org>

On Thu, 9 Feb 2023 at 16:30, Xi Ruoyao wrote:
>
> On Thu, 2023-02-09 at 14:56 +0000, Jonathan Wakely via Gcc-help wrote:
> > > Note, my code isn't like this, it is just an example to suggest
> > > adding the nullptr attribute, as its clearly already rejected at
> > > runtime.
> >
> > I assume you mean the nonnull attribute. That was added in 2020 and
> > then reverted because it broke some things:
>
> I remember I'd once made the same mistake when I suggested to add
> nonnull for ostream::operator<<(const string &) and I was lectured:
> nonnull is not only a diagnostic attribute, it also allows the compiler
> to assume the parameter is never null and rendering std::string(nullptr)
> an undefined behavior.

Yes, I think that's what might have happened with the std::string change.

> Then the example may just silently continue to run, instead of throwing
> an exception.  It would be an ironic example: an attempt to improve
> diagnostic finally made diagnostic more difficult.

Indeed.

Maybe we can add __attribute__((access(read, 1))) instead, which says
that we will read from the pointer, which also implies it must be
non-null.

N.B. in C++23 string(nullptr) produces an error, although
string((const char*)nullptr) doesn't, so in practice it only prevents
the dumbest calls with a literal 'nullptr' token, and not the more
realistic problems where you have a pointer that happens to be null.