🚀 go-pugleaf

In article <4jv6o8$coj@solutions.solon.com>, 
schwarz@mips.complang.tuwien.ac.at says...
> In article <4jr73o$h87@solutions.solon.com>, jcoffin@rmii.com (Jerry Coffin) 
writes:
> 
> |> While `char *' and `void *' are not the same, they are required to have
> |> the same representation.  (The general idea seems to be that if you pass
> |> one in place of the other, it probably shouldn't cause a problem, but
> |> they never quite state that explicitly.  I presume this was an attempt at
> |> enforcing compatibility with older libraries that expected a `char *'
> |> where a `void *' is now indicated.)
> 
> My understanding is that a conversion to a (void *) followed by a conversion
> to the original pointer type is the identity mapping; in other words, the
> mapping a C compilers uses between (void *) and any other pointer type is
> bijective.

Hmm...I'm not sure what "bijective" means (my dictionary doesn't include it) 
the basic idea here seems to be correct: "A pointer to any incomplete or 
object type may be converted to a pointer to void and back again; the result 
shall compare equal to the original pointer."  ($6.2.2.3)

However, that's more or less a separate issue.

> I don't know what you mean with representation; note however that
> 	T1 *p;
> 	*(T2 **) &p == (T2 *) p
> is not necessarily true, even, I think, if T1 or T2 is void.

I don't know exactly what's meant by representation either - however, the 
standard states that "A pointer to void shall have the same representation and 
alignment requirements as a pointer to a character type."  ($6.1.2.5).  As I 
implied in the first place, I'm not exactly certain what this implies about 
compatability between the two - I'm reasonably certain nobody else knows for 
sure either.

Depending on where p is declared, I believe your example code is either 
required to produce 1 (if p is static) or else undefined because you're using 
the value of p without initializing it.  If it's static, p must be initialized 
to be a null pointer, and "Two null pointers, converted through possibly 
different sequences of casts to pointer types shall compare equal." ($6.2.2.3)

OTOH, if p were initialized to point at an object, I believe you'd be 
correct.n
    Later,
    Jerry.