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]

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.



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