NULL with representation other then all bits 0

[Keith Thompson]

Yes, for any given object type, two null pointers are guaranteed
to compare equal, even if they do not have the same internal
representation.

This is not -necessarily- as bad as the code that compares pointers
needing to iterate through all the different null pointer representations.
The compiler knows that pointer types at the time of the
comparison, so if some of the null pointer representations are not
possible for a given type, then the compiler would not need to
test that possibility. In particular, if there happens to be
exactly one null pointer representation per type (but that different
types might have different null pointer representations) then only
one test would need to be made.

This comparison process is potentially further simplified by the
fact that one cannot convert pointers directly between
incompatible types without going through void* [if I recall correctly].
The conversion into void* could produce a "canonical" null pointer
and the conversion of the "canonical" null pointer into a different
pointer type would choose one of the null pointer representations
valid for that type; in this way, one only has to deal with the
null pointer representations valid within the type. One thing to
watch out for here is that when a pointer is converted to void* and
converted back to the same type, the original pointer and the
double-converted one must compare equal -- but in the end this just
comes down to potentially needing to be able to compare multiple null
pointer representations for a single type.

[snip]

No, you recall incorrectly. C99 6.3.2.3p7:

A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type.

(followed by caveats about undefined behavior for incorrect
alignment).

But a compiler could certainly implement pointer-to-pointer conversion
by converting to void* and then to the other type.

 

[CBFalconer]

.... snip ...

It is more important not to misattribute someone's words to
someone else.


If I don't snip attributions, I get complaints of the form "I didn't
say that" from at least two people complaining that I attributed
the SAME text to each of them. On *EVERY* *SINGLE* *POST*. Even
if there was only one attribution left in. And some of them threaten
lawsuits. If attributions are supposed to indicate who said what,
it's not working, as clearly not everyone interprets them the same
way.

attribution -> misattribution

Note that it's completely irrelevant as to whether *I* can interpret
attributions correctly. I think I can, but I doubt anyone else
cares. And I think what was said is much more important than who
said it, at least most of the time.

Come on now. All it takes is the ability to count up to 3 or 4
'>'s at the head of each line you quote. Find the max, and remove
attribution lines which have that many or more '>'s. Also yell at
idiots who use non-standard quote markers. I am fairly sure you
are capable of that.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

 

[Christian Bau]

I admit that having (void*)0 and (void*)zero yield different values is
counterintuitive, but so is the whole idea of C's null pointer
constants IMHO. C's definition of a null pointer constant is so
narrow that I think it has to allow for this possibility.

Null pointer constants are not very counter-intuitive really. All that
the C Standard says is that in some cases, when you write 0 in a
program, you actually get for example (char *) 0. There are similar
situations: If a is an array, then in many situations where you write a,
you actually get &a[0]. Or if you declare a function parameter as an
array, like in int f (int a[10]); you actually get a pointer like int f
(int* a).

 

[Jordan Abel]

Yes, or ensure that valid C code only generates one form of null
pointer. So it is exactly the same as the situation where you can have
both +ve and -ve zeros, either only one type must be generated or they
must compare equal.

Another example is on some x86 implementations, where pointer comparison
in general is on the offset only, and offset bits of 0 make a null
pointer. Of course, this also provides a reason that casting a null
pointer to an integer type doesn't necessarily result in 0. 3000:0000
cast to long would become 0x30000000L, not 0L

 

[Keith Thompson]

I admit that having (void*)0 and (void*)zero yield different values is
counterintuitive, but so is the whole idea of C's null pointer
constants IMHO. C's definition of a null pointer constant is so
narrow that I think it has to allow for this possibility.

Null pointer constants are not very counter-intuitive really. All that
the C Standard says is that in some cases, when you write 0 in a
program, you actually get for example (char *) 0. There are similar
situations: If a is an array, then in many situations where you write a,
you actually get &a[0]. Or if you declare a function parameter as an
array, like in int f (int a[10]); you actually get a pointer like int f
(int* a).

Whether something is counterintuitive or not is bound to be a matter
of opinion. I won't say you're wrong, but I will say that my opinion
is unchanged. If it it were only the integer literal 0 that's
overloaded as a null pointer constant, it wouldn't be so bad, but the
standard requires 0, '\0', 0UL, ('/'/'/'-'/'/'/'), and (3/4) to be
treated as null pointer constants as well (probably so compilers can
perform constant-folding but don't have to remember they've done it),
but *doesn't* require a non-constant integer value of 0 to yield a
null pointer value when converted (at least, I don't *think* it does;
there's still some debate on that point). It leads too many people to
assume that a null pointer *value* is represented as all-bits-zero
(which isn't an entirely unreasonable assumption given that
integer-to-pointer conversion usually just reinterprets the bits), or
at least that pointers are really just integers.

Just look at the time we spend discussing it here, and how much room
it takes up in the FAQ. And think how much of this we could have
avoided if the original C had added a keyword "nil" and made it the
*only* valid null pointer constant.

If you find all that stuff intuitive, you have better (or more C-like)
intuition than I do.