«

On 11/5/2010 10:34 PM, Jon wrote:
> [...]
> If the structs *were* declared the same though, there certainly would be
> no issue whatsoever, right? As in:
>
> struct X {
> int x;
> char y;
> double z;
> };
>
> struct Y{
> int x;
> char y;
> double z;
> };
>
> void X_func(struct X *x);
>
> struct Y y;
> X_func((struct X*)&y);

The fact that you need a cast to avoid a diagnostic should be
a tip-off that something's wrong. The two structs *probably* have
identical layout, that is,

offsetof(struct X, x) == offsetof(struct Y, x) // both 0
offsetof(struct X, y) == offsetof(struct Y, y)
offsetof(struct X, z) == offsetof(struct Y, z)

.... will probably all be true. The Standard doesn't guarantee it,
but any sane compiler will behave this way. Nonetheless, the two
struct types are not "compatible," as the Standard defines the word.

As various people have pointed out, identical representation is
*not* enough to make everything hunky-dory. Suppose your X_func()
uses a `struct Y*' internally, one it gets from a global variable,
perhaps. Since it "knows" that its `struct X*' parameter cannot point
at a `struct Y', it "knows" that accesses via the parameter and via
the internal pointer cannot interfere: Storing through one of them
cannot alter what's pointed at by the other. Of course, all this
"knowledge" rests upon a falsehood, because you've used a cast to
point the parameter at a `struct Y' after all. And if that `struct Y'
happens to be the one the internal pointer also points at ... You've
lied to the compiler, and must expect it to get its revenge.

Why are you so interested in contriving ways to shoot yourself in
the foot? Is there an actual problem you're trying to solve, or are
you just indulging a morbid curiosity?

--
Eric Sosman
lid

Eric Sosman wrote:
> On 11/5/2010 10:34 PM, Jon wrote:
>> [...]
>> If the structs *were* declared the same though, there certainly
>> would be no issue whatsoever, right? As in:
>>
>> struct X {
>> int x;
>> char y;
>> double z;
>> };
>>
>> struct Y{
>> int x;
>> char y;
>> double z;
>> };
>>
>> void X_func(struct X *x);
>>
>> struct Y y;
>> X_func((struct X*)&y);
>
> The fact that you need a cast to avoid a diagnostic should be
> a tip-off that something's wrong.

Indeed: the language is not expressive enough so one has to force it
"jump through the hoops".

> The two structs *probably* have
> identical layout, that is,
>
> offsetof(struct X, x) == offsetof(struct Y, x) // both 0
> offsetof(struct X, y) == offsetof(struct Y, y)
> offsetof(struct X, z) == offsetof(struct Y, z)
>
> ... will probably all be true. The Standard doesn't guarantee it,
> but any sane compiler will behave this way. Nonetheless, the two
> struct types are not "compatible," as the Standard defines the word.

Because they have different names and C's type system is one of "name
equivalence" rather than one of "structural equivalence", which the above
example is "chomping at the bit" for. I get it, I just need to get a
handle on how severe the limitation of "name equivalence" is and what the
possibilities are in the broader (language design) scope.

>
> As various people have pointed out, identical representation is
> *not* enough to make everything hunky-dory.

Where is the paper, "Name Equivalence in C and Implications"? (!)

> Suppose your X_func()
> uses a `struct Y*' internally, one it gets from a global variable,
> perhaps. Since it "knows" that its `struct X*' parameter cannot point
> at a `struct Y',

What does it care? It's just a memory address. When it is said that C is
"close to the machine", first and foremost, I think *memory* and being
able to do as I please with it.

> it "knows" that accesses via the parameter and via
> the internal pointer cannot interfere: Storing through one of them
> cannot alter what's pointed at by the other. Of course, all this
> "knowledge" rests upon a falsehood, because you've used a cast to
> point the parameter at a `struct Y' after all. And if that `struct Y'
> happens to be the one the internal pointer also points at ... You've
> lied to the compiler, and must expect it to get its revenge.
>
> Why are you so interested in contriving ways to shoot yourself in
> the foot? Is there an actual problem you're trying to solve, or are
> you just indulging a morbid curiosity?

Until I get *my* language implemented, I want to know how much I can bend
C to fit the mold so I can program more in a "my language" way with C in
this interim rather than in the decidely
archaic/limiting/inefficient/error-prone... C way.

"christian.bau" <> writes:

> On Nov 2, 12:37*pm, "BartC" <b...@freeuk.com> wrote:
>
>> Why should the union make a difference?
>
> Because the C Standard says so.
>
> If you have two structs s1 and s2, and there is a union u containing
> both struct s1 and struct s2, then the compiler must assume that any
> pointer to a struct s1 is actually a pointer to an element of a union
> u, and any pointer to a struct s2 might also be a pointer to an
> element of the same union, and it must produce code that is correct in
> that case. And the reason why the compiler has to assume this is
> because the C Standard says so.

Well that a bit miss leading because the structures s1 and s2 also must
share a common initial sequence.

--
Francis