This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]