From: Paul Eggert <eggert@cs.ucla.edu>
To: Bruno Haible <bruno@clisp.org>
Cc: "Tim Rühsen" <tim.ruehsen@gmx.de>,
bug-gnulib@gnu.org,
"Mats Erik Andersson" <mats.andersson@gisladisker.se>
Subject: Re: restrict
Date: Mon, 17 Feb 2020 14:28:00 -0800 [thread overview]
Message-ID: <093b79e2-9020-0424-9401-3b61c39c2c85@cs.ucla.edu> (raw)
In-Reply-To: <2610262.aAAoKc2UlG@omega>
On 2/17/20 12:55 PM, Bruno Haible wrote:
> it's pretty rare that people use 'void *' pointers and cast them
> to pointers of different types.
It's not rare in some of the code I write. :-) Plus, my example had no casts.
> Also, even a small variation of this code does not produce a warning any more:
Interesting. I don't see why GCC doesn't warn there.
GCC's heuristics for generating warnings must be even trickier than what's in
the C standard about 'restrict' - which is another reason not to base code off
when exactly GCC warns.
> Actually, GCC doesn't warn here, even with 'restrict', because the 3rd argument
> is a const-pointer and the 4th argument, being variadic, is treated like a
> const-pointer as well.
Fair enough, but there are similar examples where 'restrict' will still be
useful, such as if the 3rd argument is not a const-pointer.
> Given the confusion around what 'restrict' is actually about,
> the "signal to humans" is fuzzy.
Using 'restrict' in a nonstandard way will make that signal even fuzzier. It's
better to be systematic about it, and to use the same system that the C standard
and POSIX do.
Like Dennis Ritchie and 'noalias'[1], I'm not a big fan of 'restrict'. But we
have it and it's standardized and it's better to use it as intended rather than
invent a not-quite-the-same use for it.
> I meant the "glibc bug" the other way around: Someone could tell the glibc people
> that it makes sense to _add_ 'restrict' to the declarations of splice,
> printf_arginfo_size_function, openpty, re_set_registers, copy_file_range.
Yes, that would be worth doing.
[1] https://www.lysator.liu.se/c/dmr-on-noalias.html
next prev parent reply other threads:[~2020-02-17 22:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 14:44 Possible testing case of snprintf Mats Erik Andersson
2020-02-09 15:24 ` Tim Rühsen
2020-02-10 3:02 ` restrict Bruno Haible
2020-02-10 8:39 ` restrict Jeffrey Walton
2020-02-10 10:11 ` restrict Tim Rühsen
2020-02-16 21:44 ` restrict Paul Eggert
2020-02-16 23:49 ` restrict Bruno Haible
2020-02-17 0:14 ` restrict Bruno Haible
2020-02-17 2:46 ` restrict Paul Eggert
2020-02-17 3:53 ` restrict Bruno Haible
2020-02-17 9:51 ` restrict Tim Rühsen
2020-02-17 21:03 ` restrict Bruno Haible
2020-02-17 18:03 ` restrict Paul Eggert
2020-02-17 20:55 ` restrict Bruno Haible
2020-02-17 22:28 ` Paul Eggert [this message]
2020-02-17 21:19 ` restrict - summary Bruno Haible
2020-02-22 22:51 ` Bruno Haible
2020-02-24 19:17 ` Eric Blake
2020-02-23 12:39 ` Bruno Haible
2020-02-23 13:30 ` Bruno Haible
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
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=093b79e2-9020-0424-9401-3b61c39c2c85@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=mats.andersson@gisladisker.se \
--cc=tim.ruehsen@gmx.de \
/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).