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

[Andreas Jaeger <aj at suse dot de>]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> On Thu, 29 Nov 2001, Andreas Jaeger wrote:
>
>> The compiler should use the restrict keyword of ISO C99 when invoking
>> functions and check that the aliasing rules are not violated on the
>> call side.
>
> Why?  The keyword provides no information whatsoever to the call side,
> since the function needn't access the objects pointed to by its arguments
> at all.

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
       following example

               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.

       [#9] The benefit of the restrict  qualifiers  is  that  they
       enable a translator to make an effective dependence analysis
       of function f without examining any of the calls of f in the
       program.  The cost is that the programmer has to examine all
       of those calls to ensure that none give undefined  behavior.
       For  example,  the  second  call  of  f  in  g has undefined
       behavior because each of  d[1]  through  d[49]  is  accessed
       through both p and q.

               void g(void)
               {
                       extern int d[100];
                       f(50, d + 50, d); // valid
                       f(50, d +  1, d); // undefined behavior
               }



>> Compile this program - it should give a warning:
>> int
>> sprintf_restrict (char *restrict s, const char *restrict t)
>> {
>>   return *s!=*t;
>> }
>> 
>> 
>> 
>> int main (void)
>> {
>>   char buf[64];
>> 
>>   sprintf_restrict (buf, buf);
>> 
>>   return 0;
>> }
>
> The program is perfectly valid; while sprintf_restrict could have a const
> on the target type of its first parameter, there's no need for it to have
> one.

No, the program is not valid, the call "sprintf_restrict (buf, buf)"
invokes undefined behaviour

Sorry, I should have been more clear in my first email,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj