«

(Walter Roberson) writes:
[snip]
> 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.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Gordon Burditt wrote:
>
.... snip ...
>>
>> Gordon, *please* don't snip attribution lines. In following a
>> discussion, it's important to know who said what.
>
> It is more important not to misattribute someone's words to
> someone else.
>
>> Your headers indicate that you're using the "trn" newsreader;
>> I'm reasonably sure it does attributions correctly.
>
> 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

In article <>,
Keith Thompson <kst-> wrote:

> 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).

On 2006-01-31, Flash Gordon <> wrote:
>> But at runtime, you'd have to have all null pointer values compare
>> equal to all other null pointer values, right? So if on a particular
>> implementation, a segment number of 0 indicates a null pointer,
>> regardless of the offset, protection ring, or assorted other bits
>> making up a pointer, the code that compares pointers would have to
>> deal with this?
>
> 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

Christian Bau <> writes:
> In article <>,
> Keith Thompson <kst-> wrote:
>> 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.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.