Re: [PATCH] C undefined behavior fix

[dewar at gnat dot com]

>>Show me.  I maintain that the standard does not proscribe this.

Absolutely the standard allows implementation defined behavior to include
undefined behavior in some cases. It could not be otherwise, since in some
cases (including some of these pointer manipulation cases you are talking
about), it is completely impossible to give a clear semantics of the
operation. Yes, you like to think in terms of generated code, but the
definition of the language has nothing to do with considerations at
this level. Implementation defined behavior is often precisely reserved
for those cases in which it is impossible to define the behavior in a clear
semantic manner.

It seems to me that the GCC rules are quite clear

a. When a pointer is converted to an integer, it is a bit-wise copy, and
the resulting integer may be used in any context where an integer value
is appropriate, and the effect is determined by the bit pattern.

b. When an integer is converted to a pointer, it is a bit-wise copy. The
effect of using this pointer depends not only on the bit-wise value of
the pointer, but also the manner in which this value was derived, since
the compiler makes a set of assumptions about possible pointer values,
and if the conversion violates these assumptions, then the resulting
pointer may not be compared, dereferenced or otherwise used as a pointer.

(of course I did not include the full set of rules in b. above).

This seems a perfectly coherent set of definitions of implementation 
defined behavior and indeed I would contend that it is exactly the sort
of definition that is anticipated in making the effect of these conversions
implementation defined.

After all the standard could have specified that the semantics was simply
a bit-wise copy period, but it does NOT do that, PRECISELY because it
anticipates that there may be implementation dependent elaborations on
these simple semantics.