public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joe Buck <jbuck@synopsys.com>
To: wilson@redhat.com (Jim Wilson)
Cc: snmptoddler@hotmail.com (Nathan .), gcc@gcc.gnu.org
Subject: restrict keyword [was: expalin this syntax pls]
Date: Fri, 18 Oct 2002 14:27:00 -0000	[thread overview]
Message-ID: <200210181741.g9IHfBt04104@piper.synopsys.com> (raw)
In-Reply-To: <xwu4rbkh9l3.fsf@tonopah.toronto.redhat.com> from "Jim Wilson" at Oct 17, 2002 08:30:48 PM

Jim Wilson writes:

> restrict is a new keyword in ISO C99.  It is a type qualifier, like const
> and volatile.  See the ISO C99 standard, or see a book that explains the
> ISO C99 language.  This is the current version of the C language.  It became
> a standard in 1999.

Folks who want a quick-and-dirty explanation of what "restrict" does
(good enough for intuition, but not for a compiler writer) can see

http://www.devx.com/free/tips/tipview.asp?content_id=2554

By the way, there's a similar issue with "restrict" to the various
battles we've had over type-based aliasing: should gcc warn about
obvious violations?

Consider rtest.c
-----------------------------------------------
void f(const int* restrict pci, int* restrict pi);

int main()
{
	int n;
	f(&n, &n);
}
-----------------------------------------------

This is not a legal program: f's arguments are restricted pointers,
meaning that we promise the compiler that there is some data that
can be accessed only through pci, and other data that can be accessed
only through pi, yet we pass the same value to both pointers.
But gcc does not attempt to diagnose this:

gcc -Wall --std=c99 -c -O rtest.c

gives no warnings (in gcc 3.2).  Would it be worth trying to warn?  Of
course, the issue is that the warning could only be generated in simple
cases, or perhaps in somewhat more complicated cases if we're doing value
range propagation or the like, but in general only when the compiler can
tell exactly what each pointer points to.

  reply	other threads:[~2002-10-18 17:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-17 23:32 expalin this syntax pls Nathan .
2002-10-18  4:23 ` Jim Wilson
2002-10-18 14:27   ` Joe Buck [this message]
2002-10-18 18:46     ` restrict keyword [was: expalin this syntax pls] Joseph S. Myers
2002-10-18 21:53       ` Joe Buck
2002-10-18 21:55         ` Joseph S. Myers
2002-10-18 23:07     ` kwall
2002-10-19 10:17 Erik Schnetter

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=200210181741.g9IHfBt04104@piper.synopsys.com \
    --to=jbuck@synopsys.com \
    --cc=gcc@gcc.gnu.org \
    --cc=snmptoddler@hotmail.com \
    --cc=wilson@redhat.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).