This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Tom Rini <trini at kernel dot crashing dot org>, <gcc at gcc dot gnu dot org>
- Date: Sun, 6 Jan 2002 18:11:14 -0800 (PST)
- Subject: Re: [PATCH] C undefined behavior fix
On 6 Jan 2002, Alexandre Oliva wrote:
>
> Note: it is not necessary to verify that `offset' is in the interval
> 0..strlen("string literal"), because if it is not, undefined behavior
> is invoked, since strcpy would dereference a pointer to memory outside
> the object that was originally pointed to.
And THIS is my point.
It may be undefined behaviour, but it has a very clear and rational
implementation _despite_ the undefined behaviour. And the "memcpy()" isn't
it.
Is it undefined by the standard? Sure. Does the memcpy() "optimization"
make any sense when it is undefined? No way, ever. Does the
straightforward "do what the programmer asked for" make sense? It may. The
compiler just cannot know.
Let's say that the compiler was a smart compiler, a good compiler, and
could reason things out. Let's say that it got two choices:
- turn code that may mean something into code that certainly does NOT
mean something, and historically never has, nor is it "faster" or
better in any other way than the straightforward translation.
- turn code that may mean something into assembly that may mean
something, and historically does.
Which choice do you think is the _intelligent_ one?
Be honest now.
Linus