c/4967: GCC should warn about obvious violations of restrict

[Joseph S. Myers]

On Thu, 29 Nov 2001, Andreas Jaeger wrote:

> We have undefined behaviour in my example - and GCC should warn about
> this undefined behaviour.
> 
> 
> From ISO C99 6.7.3.1:
> 
>        [#8]  EXAMPLE 2 The  function  parameter declarations in the

Ignore the examples.  They are only relevant in deciding between different
possible interpretations of the normative text.  While there are many
cases in which the normative definition of restrict is unclear (see e.g.  
http://www.cbau.freeserve.co.uk/RestrictPointers.html), in this case it is
quite clear.

>                void f(int n, int * restrict p, int * restrict q)
>                {
>                        while (n-- > 0)
>                                *p++ = *q++;
>                }
> 
>        assert that, during each execution of the  function,  if  an
>        object  is  accessed  through one of the pointer parameters,
>        then it is not also accessed through the other.

That is only because the object gets modified when accessed through p.  
Though perhaps, when the formal definition of restrict was changed at a
very late stage in C9X development (to make it into a one writer or many
readers model, rather than one of unique access, so that C could be
optimised as well as Fortran 77), the wording of this example should have
been adjusted.

> >> Compile this program - it should give a warning:
> >> int
> >> sprintf_restrict (char *restrict s, const char *restrict t)
> >> {
> >>   return *s!=*t;
> >> }

There is no modification here, so 6.7.3.1#4 doesn't make this undefined.

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