Re: [PATCH] C undefined behavior fix

[dewar at gnat dot com]

<<Sure. Except is must say _something_. It must be defined behaviour. That's
what "implementation defined" means.
>>

Defined does NOT mean it works as you want. For instance a C compiler would
be free to say.

If you cast an integer to a pointer, the system disk will be deleted. This
is an undesirable implementation, but not a non-conforming one.

<<It's not the gcc documentation that implies this, it is the C standard
that requires that a conforming compiler document what this does.
>>

I disagree, and I don't see that you have provided any argument to support
this very peculiar position. Yes, a conforming compiler must document
what it does, but it can do anything it likes. If you don't like what
gcc does, then the only standard-centric support for such a dislike would
be that the compiler is not doing what it documents that it does. But note
that this can be perfectly well fixed by simply documenting what it does.
In fact it would be standard conforming to simply present the entire gcc
sources as the documentation. Not very useful, but not non-conforming (that's
why documentation requirements are so dubious in standards).

<<And it has to work (now, what _dereferencing_ the pointer does, that's
obviously a separate matter)
>>

But what do you mean by work? 


Note in all this discussion. 

I find it perfectly reasonable to have directives, compiler options, 
attributes, or whatever, to modify the behavior of the compiler so that
peculiar code of the kind we are discussing does what is expected. The
requirement is that we carefully define the meaning of "does what is
expected". But it just does not work to appeal to the standard here.