Two standards problems

[david.f.prosser]

In article <183 at ixi.UUCP> clive at ixi.uucp (Clive Feather) writes:
>Firstly, the Xt Intrinsics define a macro called XtOffset. This is similar
>to offsetof, but:
>
>    (1) the type argument is a pointer to a structure
>    (2) the field designator can specify a field of a field
>
>In other words, suppose I have:
>
	[example deleted for inews sake...]

>The present definition of XtOffset is:
>
>    #define XtOffset(type,field) \
>    ((unsigned int) (((char *) (& (((type) NULL)->field))) - ((char *) NULL)))
>
>(Q1) Is the present definition legal and portable ANSI-C ?

The construction is not portable, even though it will work with many compilers.

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

Yes.  Try:
	#define XtOffset(p, m) offsetof(*(p), m)

>The second, unrelated, problem is to do with structure padding. Suppose I have the
>following two structures:
>
	[examples deleted for inews sake...]

>(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 ?

Yes.

>(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 ?

Also yes.
>
>Suppose I have the variables:
>
	[examples deleted for inews sake...]

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

Yes.

>(Q7) Will writing to pt1->all.c4   write into var2.lower.c4, and
>          writing to pt2->lower.c4 write into var1.all.c4        ?

Not necessarily since (as you noted above) there may be padding
between upper and lower.

>[These are equivalent to Q4 and Q5, but with casts instead of unions].
>
>In all six questions, I am looking for answers in terms of what is portable to
>*all* conforming systems.
>
>For those who say "why on earth are you doing this ?", the answer is basically
>"backwards compatibility"; incompatible changes must be avoided if at all possible.
>-- 
>Clive D.W. Feather
>IXI Limited
>clive at ixi.uucp
>...!uunet!ukc!ixi!clive (riskier)

[padding for inews sake...]
x
x
x
x
x
x
x
x
x
x
x
x

Dave Prosser	...not an official X3J11 answer...