Re: Serious code generation/optimisation bug (I think)

[Andrew Haley <aph at redhat dot com>]

ZoltÃn KÃcsi wrote:
>> No, this is since C90; nothing has changed in this area.  NULL
>> doesn't mean "address 0", it means "nothing".  The C statement
>>
>>   if (ptr)
>>
>> doesn't mean "if ptr does not point to address zero", it means "if ptr
>> points to something".
> 
> A question then:
> 
> How can I make a pointer to point to the integer located at address
> 0x0?

Didn't we address this before?  You can't.

> It is a perfectly valid object, it exists, therefore I should be
> able to get its address? In fact, if I have a CPU that starts its data
> RAM at 0, then the first data object *will* reside at address 0 and
> thus taking its address will result in a pointer that has all its bits
> clear. Obviously that pointer then should not be equal to NULL, since
> it was obtained by taking the address of a valid object, that is, the
> pointer indeed points to something. Therefore,
> 
> int *a = &first_object;
> int *b = (int *) 0;
> 
> must result in different values in a and b. Will it?

Yes.

"6.3.2.3 Pointers

If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function."

This implies that a linker cannot place an object at address zero.

> my problem is not that the program was not
> correct. It wasn't and I have admitted it from the beginning. My problem
> was that the compiler removed a test on an assumption. It could not
> *prove* that the pointer was not NULL. It merely *assumed* it. It can
> argue that what I did was wrong, but then it should have told me so.

Now you're just starting to make things up!  Undefined behaviour does
not require the compiler to issue a diagnostic.  Anything can happen;
as the saying goes, demons might fly out of your nose.  (This phrase
is from the canonical comp.lang.c explanation of undefined behaviour;
no-one expects demons to fly out of anyone's nose, but the C standard
does not forbid it.)

>> In practice that's a lot harder than you might think.  If we were to
>> issue a warning for every transformation we made based on the
>> semantics of the C language I'm sure people would complain.  "You
>> can't dereference a NULL pointer" is a fundamental part of the
>> language.
> 
> I think I see where your semantics and mine are different:
> 
> You say: "You can't dereference a NULL pointer"
> 
> I say: "You shouldn't dereference a NULL pointer"

The important semantics are neither yours nor mine, but these:

3.4.3
undefined behavior:

behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements

NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation
or program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a
diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on integer
overïow.

Andrew.