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

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

[aj]

Synopsis: GCC should warn about obvious violations of restrict

State-Changed-From-To: open->closed
State-Changed-By: aj
State-Changed-When: Thu Nov 29 08:35:45 2001
State-Changed-Why:
    ISO C99 does not define the semantics that allows for those
    warnings.
    
    Closed by reporter.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4967&database=gcc

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

[aj]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: aj@gcc.gnu.org
To: aj@suse.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: 29 Nov 2001 16:35:46 -0000

 Synopsis: GCC should warn about obvious violations of restrict
 
 State-Changed-From-To: open->closed
 State-Changed-By: aj
 State-Changed-When: Thu Nov 29 08:35:45 2001
 State-Changed-Why:
     ISO C99 does not define the semantics that allows for those
     warnings.
     
     Closed by reporter.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4967&database=gcc

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

[Andreas Jaeger]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: Andreas Jaeger <aj@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: <gcc-gnats@gcc.gnu.org>, <ma@suse.de>, <gcc-bugs@gcc.gnu.org>,
	<schwab@suse.de>
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: Thu, 29 Nov 2001 17:32:25 +0100

 "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
 
 > On Thu, 29 Nov 2001, Andreas Jaeger wrote:
 >
 >> whether a call is defined or not.  A call sprintf_restrict (buf, buf)
 >> would only be undefined when the function writes to both pointers but
 >> this cannot be detected at the call side for e.g. library
 >> functions:-(.
 >
 > Only when it writes to the same object via one pointer as it accesses by
 > the other, indeed.  Adding 25 to the second pointer, then copying 25 bytes
 > from the first to the second, or something more complicated where each
 > byte is only accessed via one of the pointers, would still be OK.
 >
 > You could always work out some way to annotate function declarations with
 > information about how much is read or written from each argument and
 > whether aliasing is OK (note that the restrict qualifiers in declarations
 > not part of the definition are still irrelevant and are effectively
 > ignored (6.7.5.3#15), but you could define them to be relevant in
 
 that's much more involved then the simple solution I had in mind -
 which is not ok :-(
 
 > interpreting such an attribute).  I'd like to get -Wformat-security to
 > warn about sprintf into fixed-length buffers that might be too short for
 > the format, and similar such possible security holes.
 
 I'm closing this bug report now, since what I orignally intented is
 not possible.
 
 Thanks,
 Andreas
 -- 
  Andreas Jaeger
   SuSE Labs aj@suse.de
    private aj@arthur.inka.de
     http://www.suse.de/~aj

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

[Joseph S. Myers]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Andreas Jaeger <aj@suse.de>
Cc: <gcc-gnats@gcc.gnu.org>,  <ma@suse.de>,  <gcc-bugs@gcc.gnu.org>, 
     <schwab@suse.de>
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: Thu, 29 Nov 2001 16:29:00 +0000 (GMT)

 On Thu, 29 Nov 2001, Andreas Jaeger wrote:
 
 > whether a call is defined or not.  A call sprintf_restrict (buf, buf)
 > would only be undefined when the function writes to both pointers but
 > this cannot be detected at the call side for e.g. library
 > functions:-(.
 
 Only when it writes to the same object via one pointer as it accesses by
 the other, indeed.  Adding 25 to the second pointer, then copying 25 bytes
 from the first to the second, or something more complicated where each
 byte is only accessed via one of the pointers, would still be OK.
 
 You could always work out some way to annotate function declarations with
 information about how much is read or written from each argument and
 whether aliasing is OK (note that the restrict qualifiers in declarations
 not part of the definition are still irrelevant and are effectively
 ignored (6.7.5.3#15), but you could define them to be relevant in
 interpreting such an attribute).  I'd like to get -Wformat-security to
 warn about sprintf into fixed-length buffers that might be too short for
 the format, and similar such possible security holes.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

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

[Andreas Jaeger]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: Andreas Jaeger <aj@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: <gcc-gnats@gcc.gnu.org>, <ma@suse.de>, <gcc-bugs@gcc.gnu.org>,
	schwab@suse.de
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: Thu, 29 Nov 2001 14:56:48 +0100

 Joseph,
 
 Looking at the final standard and not at a draft, convinced me that
 you're right - but I'm not happy with it ;-).  The standard implies
 that you have to know the implementation of the function to decide
 whether a call is defined or not.  A call sprintf_restrict (buf, buf)
 would only be undefined when the function writes to both pointers but
 this cannot be detected at the call side for e.g. library
 functions:-(.
 
 Andreas
 -- 
  Andreas Jaeger
   SuSE Labs aj@suse.de
    private aj@arthur.inka.de
     http://www.suse.de/~aj

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

[Andreas Jaeger]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: Andreas Jaeger <aj@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: <gcc-gnats@gcc.gnu.org>, <ma@suse.de>, <gcc-bugs@gcc.gnu.org>,
	Andreas Schwab <schwab@suse.de>
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: Thu, 29 Nov 2001 14:26:30 +0100

 "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

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

[Joseph S. Myers]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Andreas Jaeger <aj@suse.de>
Cc: <gcc-gnats@gcc.gnu.org>,  <ma@suse.de>,  <gcc-bugs@gcc.gnu.org>
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
 

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

[Andreas Jaeger]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: Andreas Jaeger <aj@suse.de>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: <gcc-gnats@gcc.gnu.org>, <ma@suse.de>, <gcc-bugs@gcc.gnu.org>
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: Thu, 29 Nov 2001 13:52:33 +0100

 "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

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

[Joseph S. Myers]

The following reply was made to PR c/4967; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Andreas Jaeger <aj@suse.de>
Cc: <gcc-gnats@gcc.gnu.org>,  <ma@suse.de>,  <gcc-bugs@gcc.gnu.org>
Subject: Re: c/4967: GCC should warn about obvious violations of restrict
Date: Thu, 29 Nov 2001 12:40:56 +0000 (GMT)

 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.
 
 > 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.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

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

[Andreas Jaeger]

>Number:         4967
>Category:       c
>Synopsis:       GCC should warn about obvious violations of restrict
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 29 04:06:03 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Andreas Jaeger
>Release:        3.1 20011125 (experimental)
>Organization:
SuSE
>Environment:
System: Linux gee 2.2.19 #1 Mon Apr 30 20:46:41 GMT 2001 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /cvs/gcc/configure --prefix=/opt/gcc-3.1-devel --enable-shared --enable-threads=posix --enable-clocale=gnu --with-gnu-as --with-gnu-ld --disable-nls --with-system-zlib --enable-languages=c,objc,c++,f77,java,ada
>Description:

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.

>How-To-Repeat:

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;
}

$ /opt/gcc-3.1-devel/bin/gcc tt.c -Wall -O2 -std=c99
gives no warning.
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: