public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Dmitri Gribenko <gribozavr@gmail.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
	gcc@gcc.gnu.org, cfe-dev <cfe-dev@lists.llvm.org>
Subject: Re: [cfe-dev] ISO C3X proposal: nonnull qualifier
Date: Tue, 23 Nov 2021 12:45:06 +0100	[thread overview]
Message-ID: <93576cba-19f8-8cf6-6597-7377bda9647f@gmail.com> (raw)
In-Reply-To: <CA+Y5xYe_6uz06wX6OsT3=tjGJKzO+FBPOfQaaemtpY_2_gefAA@mail.gmail.com>

Hi Dmitry,

On 11/23/21 12:17, Dmitri Gribenko wrote:
> Hi Alejandro,
> 
> On Tue, Nov 16, 2021 at 1:34 PM Alejandro Colomar (man-pages) via
> cfe-dev <cfe-dev@lists.llvm.org> wrote:
>> First of all,
>> I see unnecessary (probably over-engineered) qualifiers:
>>
>> - _Null_unspecified seems to me the same as nothing.
>> If I didn't specify its nullability,
>> it's by definition unspecified.  Right?
>>
>> - _Nullable seems to me also the same as nothing.
>> The language allows for a pointer to be NULL,
>> so if you don't specify if it can or not be null,
>> you better stay on the safe side and consider it as nullable.
> 
> _Nullable is used in conjunction with the `#pragma clang
> assume_nonnull begin/end` pragma that flips the default:
> 
> ```
> #pragma clang assume_nonnull begin
> int *global_int_ptr; // implicitly _Nonnull
> #pragma clang assume_nonnull end
> ```
> 
> Within these pragma brackets, you need to use _Nullable to get the
> opposite behavior.
> 
> The pragma itself is useful because it reduces the amount of noise the
> annotations introduce. When these annotations were adopted in Apple
> SDKs, it was found that in practice most pointers are non-nullable. So
> if we only had _Nonnull, we would have to annotate most pointers.
> Instead, Apple's SDKs bracket every header contents with this pragma,
> and instead annotate nullable pointers, significantly reducing the
> amount of annotations.

That's interesting.  Most of my functions also tipically are full of 
[[gnu::nonnull]], so the _Nonnull default seems the best thing.

However, would that be viable in old code that relies on standard C?
I think that it would, but maybe you have more experience.  Do you agree 
with the following?

Let's imagine a scenario where C3X specifies that non-qualified pointers 
are nonnull.  And there's only a qualifier, _Nullable, to allow NULL. 
Asigning _Nullable to nonnull would issue a diagnostic.

Old code will stop compiling if it uses NULL, but that can easily be 
fixed by marking the pointers as _Nullable, and maybe while at that, 
programmers will find a few bugs.

Compilers will have to be carefull, because memcpy() will make NULL 
members of structures, so they'll need to know if that can be done or 
not, and many structure members will need to be marked as _Nullable, if 
the structure is expected to be bzero()ed.

Also, do you have any experience in avoiding to diagnose a _Nullable to 
nonnull assignment _after_ explicitly comparing to NULL?  I.e., allow 
the following:

int *_Nullable p;
int *q;

if (!p)
	q = p;

Thanks,
Alex

  reply	other threads:[~2021-11-23 11:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 16:01 Alejandro Colomar (man-pages)
2021-11-15 16:30 ` Alejandro Colomar (man-pages)
2021-11-15 20:18 ` Joseph Myers
2021-11-15 21:09   ` Alejandro Colomar (man-pages)
2021-11-15 22:17     ` Joseph Myers
2021-11-15 22:35       ` Alejandro Colomar (man-pages)
2021-11-15 22:47         ` Joseph Myers
2021-11-16 12:34           ` Alejandro Colomar (man-pages)
2021-11-17  0:06             ` Alejandro Colomar (man-pages)
2021-11-20 16:47               ` Ping: " Alejandro Colomar (man-pages)
2021-11-23 11:32               ` [cfe-dev] " Dmitri Gribenko
2021-11-23 11:17             ` Dmitri Gribenko
2021-11-23 11:45               ` Alejandro Colomar (man-pages) [this message]
2021-11-23 12:45                 ` Dmitri Gribenko
2021-12-01 22:24                   ` Alejandro Colomar (man-pages)
2021-12-02  0:39                     ` Dmitri Gribenko
2021-12-02  1:00                       ` Alejandro Colomar (man-pages)
2021-12-02 20:24             ` Alejandro Colomar (man-pages)
2021-12-02 20:31               ` Alejandro Colomar (man-pages)
2021-12-02 20:36               ` Joseph Myers
2021-11-16  9:30     ` Jonathan Wakely
2021-11-16 17:13       ` [cfe-dev] " Arthur O'Dwyer

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=93576cba-19f8-8cf6-6597-7377bda9647f@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=cfe-dev@lists.llvm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gribozavr@gmail.com \
    --cc=joseph@codesourcery.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.
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).