🚀 go-pugleaf

In article <jthill-2011951827090001@jthill.slip.netcom.com>,
jthill@netcom.com (Jim Hill) wrote:
>[summary:]
>
>(ANSI numbers) 3.2.2.3 says the result of converting the void pointer back to
>its original type shall compare equal to the original value.  3.3.9 says
>the relevant conversion is to a void pointer, not to the (putatively)
>original type.  As I read it, there's no guarantee that `p == (void*)p` -
>e.g. the old DEC10 could implement anythingbutchar*-to-void* as either
>MOVE or HRR.

Assuming p is a pointer to a non-char, non-void pointer to an object, 
    `p == (void*)p'  is evaluated as `(void*)p == (void*)p',
per 3.3.9, as you mention.

If the implementation converts from sometype* to void* by expanding
from one machine word to two machine words with, say, a few low-order
bits cleared and the additional high-order bits left undefined,
successive conversions to void* might not have the same binary
representation, although they would always convert back to the same
pointer.  Interesting.

>I can't find any language in the standard that forbids p != (void*)p. 
>What's more, given that comparing pointers that may be in different
>"object"s is unspecified at best, I can't find any hard reason to believe
>it *should* forbid that - in any situation where a void* cast was
>necessary, comparison is useless anyway.

The undefined results of comparing different objects applies to
relational comparisons, not equality comparisons.  If we were
comparing char* pointers that pointed to the same object, the
comparison would yield 1.  If the char* pointers pointed to two
different objects, the comparison would yield 0.  

Unfortunately, the semantics are not given for comparing void* and
thus the results seem to be undefined.  
    (char*)p == (char*)(void*)p
appears to be required for p either pointing to an object or NULL.

Thad