This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
restrict keyword [was: expalin this syntax pls]
- From: Joe Buck <jbuck at synopsys dot com>
- To: wilson at redhat dot com (Jim Wilson)
- Cc: snmptoddler at hotmail dot com (Nathan .), gcc at gcc dot gnu dot org
- Date: Fri, 18 Oct 2002 10:41:11 -0700 (PDT)
- Subject: restrict keyword [was: expalin this syntax pls]
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.