Re: [PATCH] C undefined behavior fix

[Linus Torvalds <torvalds at transmeta dot com>]

In article <15412.11822.811712.207946@argo.ozlabs.ibm.com> you write:
>Richard Henderson writes:
>> No.  You still have the problem of using pointer arithmetic past
>> one past the end of the object.
>> 
>> C99 6.5.6/8:
>> 
>>    If both the pointer operand and the result point to elements of the
>>    same array object, or one past the last element of the array object,
>>    the evaluation shall not produce an overflow; otherwise, the behavior
>>    is undefined.
>
>I don't have a copy of the C standard handy, but that sounds to me
>like the result of (unsigned long)(&x) - KERNELBASE is undefined.

It is not. It is implementation-defined, because the cast from the
pointer to the "unsigned long" is implementation defined (and the
subtraction is 100% well-defined, of course ;)

And note how implementation-defined does _not_ mean that the compiler
can do anything it wants.  It needs to do something documented, and the
gcc behaviour has always been to consider a pointer/integer conversion
to be a bitpattern conversion. 

The relevant quote is from 6.3.2.3:

 Any pointer 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 behaviour is undefined.

(and none of the exceptions are true in this case - the first one
concerns the special case of the constant 0 and the "null pointer"
issue, while the second one is simply not true on gcc/ppc).

			Linus