This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Linus Torvalds <torvalds at transmeta 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: 07 Jan 2002 02:10:03 -0200
- Subject: Re: [PATCH] C undefined behavior fix
- Organization: GCC Team, Red Hat
- References: <Pine.LNX.4.33.0201061805070.31073-100000@penguin.transmeta.com>
On Jan 7, 2002, Linus Torvalds <torvalds@transmeta.com> wrote:
> Which choice do you think is the _intelligent_ one?
I'd surely go with the implementation that makes code with defined
behavior work correctly and as fast as possible. If this makes code
that invokes undefined behavior not work, fine. That's what the
aliasing rules do, and that's exactly what the strcpy->memcpy
optimization does.
When the compiler can tell that this transformation can't possibly be
well-defined, such as:
strcpy (to, "from" + 10);
it will warn the user. But when it sees:
strcpy (to, "from" + offset);
where nothing is known about the value of offset, it faces two
choices:
(a) assume the program is well-behaved, i.e., that offset is in the
0..4 range, and apply the optimization so that the code runs faster
and correctly, or,
(b) take into account the possibility that the programmer might be
willfully invoking undefined behavior and not do the optimizations, so
that the code runs slower even if it's well-defined.
I go with (a). How about you?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me