This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] C undefined behavior fix



On Sat, 5 Jan 2002, mike stump wrote:
>
> We have a choice, the choice is to define it to render the expression
> into the same category as the standard undefined behavior.

No, you don't have that choice.

And that's not just my opinion - see the independent posting by Zack
Weinberg on an "unofficial ruling" by a member of the C standards
committee on comp.std.c. (subject line: "May an implementation document
implementation-defined behavior as undefined?")

"implementation-defined" simply _cannot_ be "undefined". You get a choice,
and the implementation has to document the choice.

> Our choice has been made, if you wish to contest it, please quote the
> standard that says that we are not allowed to make this choice in this
> way.

I actually quoted it earlier (see the definition of what "implementation
defined" and unspecified means early in the document), but people don't
think my quotes are good enough. Go look at the other thread, that might
convince you more than any quotes I can come up with does, just by virtue
of it being somebody else.

Now, to make you happy, the same standards-body person in question - James
Kuyper (and go read the post) actually is of the opinion that the result
on dereferencing ends up being undefined for a totally _different_ reason,
namely the fact that the standard doesn't even mention what such a new
pointer means. (ie it's not undefined by the standard, it's just not
covered, and can thus be undefined). Which I cannot argue against ;/

			Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]