This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/4967: GCC should warn about obvious violations of restrict
- From: Andreas Jaeger <aj at suse dot de>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: <gcc-gnats at gcc dot gnu dot org>, <ma at suse dot de>, <gcc-bugs at gcc dot gnu dot org>,Andreas Schwab <schwab at suse dot de>
- Date: Thu, 29 Nov 2001 14:26:30 +0100
- Subject: Re: c/4967: GCC should warn about obvious violations of restrict
- References: <Pine.LNX.4.33.0111291301220.29531-100000@kern.srcf.societies.cam.ac.uk>
[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