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: Richard Henderson <rth at redhat dot com>, <dewar at gnat dot com>, <gcc at gcc dot gnu dot org>, <trini at kernel dot crashing dot org>
- Date: Sat, 05 Jan 2002 12:22:27 +0100
- Subject: Re: [PATCH] C undefined behavior fix
- References: <Pine.LNX.4.33.0201042124050.1582-100000@penguin.transmeta.com>
Linus Torvalds <torvalds@transmeta.com> writes:
> I'm saying that the standard clearly says that _any_integer_ can be
> converted into a pointer
Yes, but you have to read the whole paragraph:
[#6] Any pointer type may be converted to an integer type.
Except as previously specified, the result is
implementation-defined. If the result cannot be represented
in the integer type, the behavior is undefined. The result
need not be in the range of values of any integer type.
A less verbose version is: "Any pointer type may be converted to an
integer type, and the behavior is undefined." In fact, this section
is an example that implementation-defined behavior can include
undefined behavior.
The first requirement is necessary so that you can write "(foo *) i"
at all, otherwise the compiler would have to reject such casts in
order to be conforming.
So could we please stop this pointless discussion. Obviously, you
dislike the behavior of GCC. But GCC behavior can be changed right
now, if there's consensus, and if it is implementable in the GCC 3.1
frame. However, if we want to make a change, we need a sufficiently
detailed proposal for new behavior.