bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
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


  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).