This is the mail archive of the gcc-bugs@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: c/4967: GCC should warn about obvious violations of restrict

[Get raw message]
"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

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

It seems that you're missing my point.  Please reread my emails,
especially those parts that you have deleted.

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

Replace that with and treat it as a black box:
extern int sprintf_restrict (char *restrict s, char *restrict t);

I'm not concerned with that function, I'm concerned with this call:
sprintf_restrict (buf, buf);

It is undefined since the two pointer are obviously aliasing each
other,

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


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