Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.std.c
Subject: Re: Two standards problems
Message-ID: <806@cbnewsl.ATT.COM>
Date: 14 Jun 89 14:03:37 GMT
References: <178@ixi.UUCP <183@ixi.UUCP> <10397@smoke.BRL.MIL>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 69

In article <10397@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
}In article <183@ixi.UUCP> clive@ixi.uucp (Clive Feather) writes:
}>(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.

Doug is quite right.  I was mistaken in my previous reply.  The only other
idea that I have would rely on having a common prefix or suffix to a single
typedef structure pointer type name that would generate the structure type:

	typedef struct { /*...*/ } funny;
	typedef funny *funny_p;

	typedef funny funny_p_deref_type;

	#define XtOffset(p, m) offsetof(p##_deref_type, m)

This relies on having only single identifier first arguments to all XtOffset()
invocations, and that each such identifier has a _deref_type-suffixed version
available.  This is going a long way to get around this problem.  Is it really
impossible simply to change the XtOffset() invocations to their matching
offsetof() invocations, since the only change is to the first argument?

}
}>(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".

I disagree here, Doug.  The pANS does allow for virtually any padding
within structures, but when the initial portions of such type declarations
are identical, they are guaranteed to match.  See section 3.3.2.3.

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