[PATCH] C undefined behavior fix

[dewar@gnat.com]

<<It is mathematically inconsistent with the sections that precede it.  If
you define I2P, and you define P2I, and you define PLUS, you have defined
I2P(PLUS(P2I(p),i)), because at no point is an illegal or undefined
expression created.
>>

You have only defined the resulting bits by this equation. The quoted
paragraph talks about the effect of using these bits in the future.

For example, here is a completely valid rule standarwise:

If you convert an integer to a pointer, then the conversion is done bitwise,
but from that point on, all addition operations will be interpreted as
subtraction.

Again, not useful, but a reminder that the requirement to document what you
do does not in anyway restrict you.

So what GCC is saying is

a) I will tell you exactly what bits you get from I2P(PLUS(P2I(p),i))

b) I will tell you what happens if you use these bits, namely the result
is undefined, which formally just means it is the union of all possible
outcomes. There is nothing in the standard that rules out non-determinacy.

Once again, it is you that are trying to be pedantic, by brinbging in 
bogus arguments about mathematical consistency.

You are bound to end up in a logically inconsistent mess if you try to
argue from the standard.

You really have a perfectly clear starting point which is that

a) you think that gcc should behave in a given way, fine ...

b) the standard allows gcc to behave in this way, fine ...

You should stop there, because so far you are on firm ground. Furthermore,
it is much more interesting to argue about what the gcc semantics should be
than what they are now, since as we all agree it is not very well defined
what they are now.

But you insist on going on to trying for step c

c) the standard requires gcc to behave in this way.

NO IT DOES NOT! On the contrary the standard is written to allow maximum
flexibility to compilers, by allowing them to do anything at all, so long
as they document what they do. The reason in many cases for the difference
between undefined and implementation defined is a recognition of history
and tradition. There are constructs in C that have been widely used, but
whose meaning is not well defined by the standard. It seems resaonable
where possible and practical to ask compilers to say what they do for
such code.

In fact I agree that gcc cannot take a completely "this is totally
undefined" viewpoint, because then that will force code to be written
outside the boundaries. However, it is not at all easy to see how to
precisely define what the semantics should be. The predicate

"do-what-Linux-and/or-Joe-want" is not sufficiently well defined for us
to include in the documentation, and would be even harder to implement without
a bit more detail :-)(