This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: restrict keyword [was: expalin this syntax pls]
- From: Joe Buck <jbuck at synopsys dot com>
- To: jsm28 at cam dot ac dot uk (Joseph S. Myers)
- Cc: Joe dot Buck at synopsys dot COM (Joe Buck), gcc at gcc dot gnu dot org
- Date: Fri, 18 Oct 2002 17:12:13 -0700 (PDT)
- Subject: Re: restrict keyword [was: expalin this syntax pls]
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.