Re: restrict keyword [was: expalin this syntax pls]

Re: restrict keyword [was: expalin this syntax pls]

[Erik Schnetter]

You can't issue a hard error for it anyway, since the code might never 
be executed.  The key questions for issuing a warning (under its own 
option, possibly included in -Wall) are:

* Can working code wrongly triggering the warning be easily changed, 
even if automatically generated, so as not to trigger it?  (The 
relevant question for -Wall inclusion.)

If I had to translate a Fortran procedure to C, I would very likely 
declare all arguments as restricted pointers.  I think that the 
definition of "restrict" in C and of non-aliasing in Fortran are close 
enough to make that worthwhile.  This would not be possible if "-Wall" 
included a warning for passing the same pointer several times to a 
procedure.

There might also an updated version of "f2c" be written at some time.

-erik

-- 
Erik Schnetter <schnetter@uni-tuebingen.de>

Re: expalin this syntax pls

[Jim Wilson]

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.

Jim

restrict keyword [was: expalin this syntax pls]

[Joe Buck]

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.

Re: restrict keyword [was: expalin this syntax pls]

[Joseph S. Myers]

On Fri, 18 Oct 2002, Joe Buck wrote:

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

It's a perfectly legal program if f doesn't actually write through pi
(missing an optional const).  Remember that the definition of restrict was
changed substantially between the last public draft and the FDIS (at the
instigation of the UK) to a model where there can be readonly access
through multiple restricted pointers unless the data is written to.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: restrict keyword [was: expalin this syntax pls]

[Joe Buck]

I wrote:
> > 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.

Joseph S. Myers writes:
> It's a perfectly legal program if f doesn't actually write through pi
> (missing an optional const).  Remember that the definition of restrict was
> changed substantially between the last public draft and the FDIS (at the
> instigation of the UK) to a model where there can be readonly access
> through multiple restricted pointers unless the data is written to.

This means that we can't issue a hard error for it, but a warning may well
still be appropriate.  Errors are for code that is wrong, warnings are for
code that is likely to be wrong. If you insist on not issuing warnings for
such code, we have the problem that we can't use similar mechanisms to
warn about possible misuse of memcpy, whose specification implies
"restrict" even for C++, which doesn't have the keyword.

Re: restrict keyword [was: expalin this syntax pls]

[Joseph S. Myers]

On Fri, 18 Oct 2002, Joe Buck wrote:

> This means that we can't issue a hard error for it, but a warning may well
> still be appropriate.  Errors are for code that is wrong, warnings are for
> code that is likely to be wrong. If you insist on not issuing warnings for
> such code, we have the problem that we can't use similar mechanisms to
> warn about possible misuse of memcpy, whose specification implies
> "restrict" even for C++, which doesn't have the keyword.

You can't issue a hard error for it anyway, since the code might never be 
executed.  The key questions for issuing a warning (under its own option, 
possibly included in -Wall) are:

* Does anyone write real (broken) code the warning would detect?  (The 
relevant question for having the warning at all.)
* Does anyone write real (working) code the warning would wrongly trigger 
on?
* How common are these?
* Can working code wrongly triggering the warning be easily changed, even 
if automatically generated, so as not to trigger it?  (The relevant 
question for -Wall inclusion.)

In the case of memcpy, we have more information to tell whether a call
*is* a problem (rather than might be).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: restrict keyword [was: expalin this syntax pls]

[kwall]

On Fri, Oct 18, 2002 at 10:41:11AM -0700, Joe Buck wrote:
> 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

Thanks muchly, Joe. I wondered about the restrict keyword...

Kurt
-- 
For 20 dollars, I'll give you a good fortune next time ...