public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: JeanHeyd Meneide <phdofthehouse@gmail.com>,
	gcc@gcc.gnu.org, cfe-dev@lists.llvm.org
Subject: Re: ISO C3X proposal: nonnull qualifier
Date: Mon, 15 Nov 2021 22:09:17 +0100	[thread overview]
Message-ID: <56a1a945-608e-0e5e-7610-c35481abb980@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2111152016210.369620@digraph.polyomino.org.uk>

Hi Joseph,

On 11/15/21 21:18, Joseph Myers wrote:
> lvalue-to-rvalue conversion loses qualifiers, which makes any rules based
> on whether the RHS of an assignment was nonnull-qualified very
> problematic.  (The specification of restrict is exceedingly tricky and
> very unlikely to be a good basis for specifying any other feature.)

Hmm.
restrict was the closest thing to a
const-like level of safety that I could think of.
It would allow a compiler to keep track of nullness
of every pointer,
and issue appropriate diagnostics
probably better than what -fanalyzer already does.

How is restrict handling that problem of lvalue-to-rvalue already?

Can you think of any other way nonnull-ness could be passed
to nested function calls with language enforcement?

The other option would be to propose plain [[gnu::nonnull]],
which couldn't be enforced across nested function calls
(or I could't think of how yet).
Well, the simplest cases (i.e., not pointer-to-pointer)
could be detected by the compiler,
but other than that, it's impossible.
But if that's the only way,
it's better than nothing.

> 
> I don't think a manpage is a good form for proposing a language feature.
> Actual proposed normative wording for the C standard, showing all relevant
> changes to all relevant subclauses, is better.
> 

My intention is that the final PDF to be sent to the committee
will have those diffs.
But I have no clue of how to do that kind of things,
so for an initial draft to discuss on,
before even presenting it to the committee,
I think my "native" language for writing technical documents
will be easier.

Also,
I'm curious,
do you do those diffs usually by hand?
I mean, you can't diff(1) a PDF, can you? :)

Considering that C moves at a 10-years pace,
and we're late for C2X,
I have until around 2030 to learn how to do that :-)


Thanks!
and kind regards,
Alex


-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2021-11-15 21:09 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) [this message]
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)
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=56a1a945-608e-0e5e-7610-c35481abb980@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=cfe-dev@lists.llvm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=phdofthehouse@gmail.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).