This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: <dewar at gnat dot com>, <gcc at gcc dot gnu dot org>, <rth at redhat dot com>, <trini at kernel dot crashing dot org>
- Date: Sat, 05 Jan 2002 12:19:35 +0100
- Subject: Re: [PATCH] C undefined behavior fix
- References: <Pine.LNX.4.33.0201041947290.1371-100000@penguin.transmeta.com>
Linus Torvalds <torvalds@transmeta.com> writes:
> I brought up the issue of "implementation defined" simply because the
> arguments I saw were bogus. They claimed that the behaviour was undefined,
> which it isn't, with some simple syntactic changes.
You mean "semantic changes", I think. We aren't talking about syntax.
> To take the example that Richard had, for example, which was something
> like:
>
> int a[5];
> int b[5];
>
> for (i = 0; i < 10; i++)
> a[i] = b[0];
>
> and Richard (correctly, in my opinion) claims that the compiler can and
> should be able to see that b[0] is constant, even if the programmer laid
> out "a" and "b" consecutively in memory (and thus changing "a[5]" really
> does change the memory location that b[0] has).
The programmer didn't lay out "a" and "b" consecutively in memory, at
least if the above code is from a C program.
> - the C language clearly _does_ have different rules for pointer
> arithmetic and for "integer arithmetic with cast pointers" (the first
> one ends up being undefined and allows more aggressive optimization,
> while the second one is implementation-defined and thus tends to
> disallow some of those optimizations).
Repeating this over and over again doesn't make it true.