public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 21:27 Joseph S. Myers
0 siblings, 0 replies; 10+ messages in thread
From: Joseph S. Myers @ 2001-11-21 21:27 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 22:59 aj
0 siblings, 0 replies; 10+ messages in thread
From: aj @ 2001-11-21 22:59 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 22:57 Andreas Jaeger
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Jaeger @ 2001-11-21 22:57 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 22:56 Joseph S. Myers
0 siblings, 0 replies; 10+ messages in thread
From: Joseph S. Myers @ 2001-11-21 22:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 22:49 aj
0 siblings, 0 replies; 10+ messages in thread
From: aj @ 2001-11-21 22:49 UTC (permalink / raw)
To: aj, gcc-bugs, gcc-gnats, gcc-prs, nobody
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 21:36 Andreas Jaeger
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Jaeger @ 2001-11-21 21:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 21:36 Andreas Jaeger
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Jaeger @ 2001-11-21 21:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 21:18 Andreas Jaeger
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Jaeger @ 2001-11-21 21:18 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 21:16 Joseph S. Myers
0 siblings, 0 replies; 10+ messages in thread
From: Joseph S. Myers @ 2001-11-21 21:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* c/4967: GCC should warn about obvious violations of restrict
@ 2001-11-21 21:15 Andreas Jaeger
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Jaeger @ 2001-11-21 21:15 UTC (permalink / raw)
To: gcc-gnats; +Cc: ma
>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:
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2001-11-29 16:46 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-21 21:27 c/4967: GCC should warn about obvious violations of restrict Joseph S. Myers
-- strict thread matches above, loose matches on Subject: below --
2001-11-21 22:59 aj
2001-11-21 22:57 Andreas Jaeger
2001-11-21 22:56 Joseph S. Myers
2001-11-21 22:49 aj
2001-11-21 21:36 Andreas Jaeger
2001-11-21 21:36 Andreas Jaeger
2001-11-21 21:18 Andreas Jaeger
2001-11-21 21:16 Joseph S. Myers
2001-11-21 21:15 Andreas Jaeger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).