From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17346 invoked by alias); 29 Nov 2001 13:16:08 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 17295 invoked by uid 71); 29 Nov 2001 13:16:04 -0000 Date: Wed, 21 Nov 2001 21:27:00 -0000 Message-ID: <20011129131604.17293.qmail@sourceware.cygnus.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Joseph S. Myers" Subject: Re: c/4967: GCC should warn about obvious violations of restrict Reply-To: "Joseph S. Myers" X-SW-Source: 2001-11/txt/msg00713.txt.bz2 List-Id: The following reply was made to PR c/4967; it has been noted by GNATS. From: "Joseph S. Myers" To: Andreas Jaeger Cc: , , Subject: Re: c/4967: GCC should warn about obvious violations of restrict Date: Thu, 29 Nov 2001 13:11:55 +0000 (GMT) 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