help: gcc compilation difference

[Tim Rentsch]

I agree with what you've written but want to raise a detail so
forgive me for snipping so much of a helpful reply...


This is obviously the intent from the wording about unions but there
is a problem with the == operator. 6.5.9 p6 reads:

Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object (including a pointer to an
object and a subobject at its beginning) or function, both are
pointers to one past the last element of the same array object, or
one is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address
space.

So unless we stretch the meaning of the parenthetical remark, we would
have to conclude that (void *)&u.si == (void *)&u.ui must be false
since these two are not the same object.

Of course, both u.si and u.ui are subobjects at the same object's
beginning, but that case is not explicitly covered.

<snip>

This comment illustrates one of my complaints with how the
term "object" is used in the Standard. Sometimes (as in the
cited paragraph) it means just a region of storage and nothing
more than that. Other times it means a kind of association
between an identifier and a region of storage, almost but
not quite what "variable" means in most programming languages.

I absolutely agree with your comment about the cited paragraph,
but I attribute the problem more to sloppy use of language
for the term "object" than indicating any deeper problem
in the C language requirements. In other words the problem
is with how the specifications are written, not with what
I believe to be what the specifications are meant to express.

 

[lawrence.jones]

This is obviously the intent from the wording about unions but there
is a problem with the == operator. 6.5.9 p6 reads:

Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object (including a pointer to an
object and a subobject at its beginning) or function, both are
pointers to one past the last element of the same array object, or
one is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address
space.

So unless we stretch the meaning of the parenthetical remark, we would
have to conclude that (void *)&u.si == (void *)&u.ui must be false
since these two are not the same object.

I don't think that's stretching the parenthetical remark at all, I think
it's a natural consequence of it. If an object and a subobject at its
beginning are considered to be the same object, then two different
subobjects at the beginning of an object must be considered to be the
same object as well.

 

[Ben Bacarisse]

I don't think that's stretching the parenthetical remark at all, I think
it's a natural consequence of it. If an object and a subobject at its
beginning are considered to be the same object, then two different
subobjects at the beginning of an object must be considered to be the
same object as well.

6.2.5 p20 says they are different objects. This is the dichotomy I
was highlighting. I think the intent is that they are different
objects with the same address.

Obviously, in any sane implementation if A == B and A == C then B == C
but in the case of the two pointers in question, I can't quite argue
that from the text. The text I quoted clearly makes == reflexive and
symmetric (for the operands that it describes) but the parenthetical
remark seems to stop is being transitive in all cases.

 

[Phil Carmody]

This is obviously the intent from the wording about unions but there
is a problem with the == operator. 6.5.9 p6 reads:

Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object (including a pointer to an
object and a subobject at its beginning) or function, both are
pointers to one past the last element of the same array object, or
one is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address
space.

So unless we stretch the meaning of the parenthetical remark, we would
have to conclude that (void *)&u.si == (void *)&u.ui must be false
since these two are not the same object.

Of course, both u.si and u.ui are subobjects at the same object's
beginning, but that case is not explicitly covered.

It looks like 6.5.9 p6 has issues with void* too, surely?

Phil

 

[Tim Rentsch]

It looks like 6.5.9 p6 has issues with void* too, surely?

No real difference from the non- (void*) case. A (void*) pointer
(with a valid address presumably) points to an object, we just don't
know how big the object is. As long as one understands "object" in
6.5.9 p6 to mean just a region of storage, and not an association
with any identifier (which I believe is the interpretation expected
here), two (void*) pointers for the same beginning address point
either to the same region of storage or one region of storage that's
a subregion of the other (and starting at its beginning). Consider
analagous cases with pointers to arrays or incomplete structure
types:

int (*pa0)[], (*pa1)[];
struct foo *f0, *f1;

... initialize all the variables ...

return pa0 == pa1 && f0 == f1;

All sizes unknown but the pointers still point at objects,
as do pointers of type (void*).

 

[Phil Carmody]

a problem with the == operator. 6.5.9 p6 reads:

Two pointers compare equal if and only if both are null pointers,
both are pointers to the same object [...]

It looks like 6.5.9 p6 has issues with void* too, surely?

No real difference from the non- (void*) case. A (void*) pointer
(with a valid address presumably) points to an object, we just don't
know how big the object is.

Yes, I can see that now. I was reading the clause too literally with
the pointers each being a "pointer to an object", and thus of type
"pointer to object", and thus complete types. The intended
interpretation is indeed closer to "both are pointers, pointing
to the same object".

Phil