Two standards problems

[Doug Gwyn]

In article <183 at ixi.UUCP> clive at ixi.uucp (Clive Feather) writes:
>    i = XtOffset (funny_p, x.y);

Presumably that was c.y, not x.y.

>(Q1) Is the present definition legal and portable ANSI-C ?

No -- you cannot dereference through a null pointer nor perform arithmetic
with it.

>(Q2) Is it possible to define XtOffset portably using offsetof ?

Not as it's currently defined, because there's no way (that I can think of)
to convert a struct pointer type name into the type of the struct.

>(Q3) If the answer to both the above is no, then is it possible to define XtOffset
>     portably ?

Not that I can see.

>(Q4) It is my understanding that c1, c2, and c3 must have the same position in
>     the two versions, so that assigning to u.m1.all.c1 and then reading from
>     u.m2.upper.c1 will yield the same value. Is this correct ?

No, although it will usually be the case.  The Standard imposes some
weird constraints on addresses of first members of structs that pretty
much guarantee this working on any sane implementation.

>(Q5) Can the compiler insert padding between t2.upper and t2.lower so that
>     u.m1.all.c4 and u.m2.lower.c4 occupy different locations ?

The compiler can generate padding anywhere in a struct (except before
the first member), and it doesn't have to follow reasonable rules in
doing so, just so long as it keeps it all straight internally.

>(Q6) Will writing to pt1->all.c1   write into var2.upper.c1, and
>          writing to pt2->upper.c1 write into var1.all.c1        ?

Assuming the compiler let you get away with the pointer casts in the
first place, which I think could be deduced from various constraints
of the Standard (with a lot of effort!), this is likely to work, as
indicated previously.

>(Q7) Will writing to pt1->all.c4   write into var2.lower.c4, and
>          writing to pt2->lower.c4 write into var1.all.c4        ?
>[These are equivalent to Q4 and Q5, but with casts instead of unions].

These are marginally less likely to work than in Q6.

There are of course alternative ways to do these things portably,
although as you seem to realize, the interfaces would have to be
changed.  One wonders why this is being thought about now instead
of when the interfaces were first "designed".