«

"Vrtt" <> writes:

> I couldn't find this question in the FAQ, although it looks like a
> frequently asked one. Apologies if it's been answered here before.
>
> I've seen this idiom a lot in libraries:-
>
> struct base {
> int x;
> char y;
> };
>
> struct extended {
> int x;
> char y;
> double z;
> };
>
> void base_func(struct base *b);
>
> struct extended e;
> base_func((struct base*)&e);
>
> Is this actually guaranteed to work, or can struct alignment (or something
> else) mess it up?

It's not guaranteed to work, though it is one of those things that
almost certainly will. The reason is that it *is* guaranteed to work if
the two structs are members of a union, and the access is through that
union. For the compiler to arrange the layout of the common initial
members of the two structs differently it would have to be sure that no
such access is ever done and it is obviously simpler just to make the
layout of the common parts be the same "just in case".

--
Ben.

On 2010-11-02, Ben Bacarisse <> wrote:
> It's not guaranteed to work, though it is one of those things that
> almost certainly will. The reason is that it *is* guaranteed to work if
> the two structs are members of a union, and the access is through that
> union. For the compiler to arrange the layout of the common initial
> members of the two structs differently it would have to be sure that no
> such access is ever done and it is obviously simpler just to make the
> layout of the common parts be the same "just in case".

The problem isn't layout, it's aliasing.

gcc will, already, generate code which assumes that modifications
through a (struct base *) cannot possibly affect a (struct extended *).

You can easily arrange:
struct base *b = external_base();
struct extended *e = external_extended();
assert(b == e);
e->x = 1;
b->x = 2;
printf("%d\n", e->x);

to print "1". Because the compiler KNOWS that e and b are different objects,
as they're of incompatible types.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Ben Bacarisse <> writes:

> "Vrtt" <> writes:
>
>> I couldn't find this question in the FAQ, although it looks like a
>> frequently asked one. Apologies if it's been answered here before.
>>
>> I've seen this idiom a lot in libraries:-
>>
>> struct base {
>> int x;
>> char y;
>> };
>>
>> struct extended {
>> int x;
>> char y;
>> double z;
>> };
>>
>> void base_func(struct base *b);
>>
>> struct extended e;
>> base_func((struct base*)&e);
>>
>> Is this actually guaranteed to work, or can struct alignment (or something
>> else) mess it up?
>
> It's not guaranteed to work, though it is one of those things that
> almost certainly will. The reason is that it *is* guaranteed to work if
> the two structs are members of a union, and the access is through that
> union. [snip]

Access doesn't need to be done through the union type;
all that's required is that the "body" of the union
type be visible at the point where the accesses (ie,
to members in the common initial sequence) occur.