public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonny Grant <jg@jguk.org>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Xi Ruoyao <xry111@xry111.site>, gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: std::string add nullptr attribute
Date: Mon, 13 Mar 2023 19:55:10 +0000	[thread overview]
Message-ID: <34990756-ffc0-98d8-3194-cd6be23347a5@jguk.org> (raw)
In-Reply-To: <CAH6eHdRkKWPCToJ+HoeiDJg2N2hCqz45c4Z1LUwG3ipaxNLBWw@mail.gmail.com>



On 13/03/2023 10:10, Jonathan Wakely wrote:
> On Sun, 12 Mar 2023 at 22:10, Jonny Grant wrote:
>>
>>
>>
>> On 09/02/2023 17:52, Jonathan Wakely wrote:
>>> 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.
>>
>> How about adding a method that is called by these operators that has the __attribute__ ((nonnull)) ?
>>
>> example:
>> https://godbolt.org/z/bqW86PP34
>>
>>>> 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.
>>
>> There is a way to generate a build error for even string((const char*)nullptr)
>>
>> I made another example that detects nullptr being passed around (should such stupid code occur) at build time providing optimizer is on. With -O0 it just gives the error always; so I put in an __OPTIMIZE__ check. This example doesn't need -fanalyzer.
>>
>> https://godbolt.org/z/TdGnno4K5
>>
>> #if __OPTIMIZE__
>> void nullptr_compile_abort() __attribute__((error("nullptr compile error")));
>> #endif
>>
>> static void f2(const char * str)
>> {
>> #if __OPTIMIZE__
>>     if (str == nullptr) nullptr_compile_abort();
>> #endif
>> }
>>
>> int main()
>> {
>>     f2((const char *)nullptr);
>> }
> 
> This causes compilation to fail for code which is never executed at
> run-time, which is not permitted by the standard.
> 
> You can use __attribute__((warning(""))) instead, but that is broken^W
> inconvenient for inline functions. You need a non-inline definition of
> the function, which means exporting a new function from the shared
> library just for this diagnostic.
> 
> All these techniques you're rediscovering have been tried before :-)

Is there any link you can refer me to for these techniques?

Regards, Jonny

      reply	other threads:[~2023-03-13 19:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 13:26 Jonny Grant
2023-02-09 14:56 ` Jonathan Wakely
2023-02-09 16:30   ` Xi Ruoyao
2023-02-09 17:52     ` Jonathan Wakely
2023-02-10 21:30       ` Jonny Grant
2023-02-10 22:03         ` Jonathan Wakely
2023-02-10 22:38           ` Jonny Grant
2023-02-11  0:32             ` Jonathan Wakely
2023-02-13 22:02               ` Jonny Grant
2023-02-19 20:43               ` Jonny Grant
2023-02-19 21:33                 ` Jonny Grant
2023-02-20 10:26                   ` Xi Ruoyao
2023-02-20 10:37                     ` Jonathan Wakely
2023-02-20 10:54                       ` Xi Ruoyao
2023-02-20 11:10                         ` Gabriel Ravier
2023-02-20 11:18                           ` Marc Glisse
2023-02-20 11:28                             ` Segher Boessenkool
2023-02-20 12:00                               ` Jonny Grant
2023-02-20 14:50                               ` Gabriel Ravier
2023-02-20 11:44                             ` Jonny Grant
2023-02-21 15:02                             ` Jonny Grant
2023-02-20 11:38                           ` Jonny Grant
2023-02-20 11:30                       ` Jonny Grant
2023-02-20 12:59                         ` Xi Ruoyao
2023-02-20 13:44                           ` Jonathan Wakely
2023-02-20 19:21                             ` Jonny Grant
2023-02-20 19:35                               ` Jonathan Wakely
2023-02-20 19:39                                 ` Jonny Grant
2023-02-22 20:27                                 ` Jonny Grant
2023-02-21 15:04                           ` Jonny Grant
2023-02-21 22:48                           ` Jonny Grant
2023-03-04 15:00                           ` Jonny Grant
2023-02-20 11:25                     ` Jonny Grant
2023-03-12 22:10       ` Jonny Grant
2023-03-13 10:10         ` Jonathan Wakely
2023-03-13 19:55           ` Jonny Grant [this message]

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=34990756-ffc0-98d8-3194-cd6be23347a5@jguk.org \
    --to=jg@jguk.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=xry111@xry111.site \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).