struct element orderin vs. alignment.

[Mark.Tucker at CMU-CS-GANDALF.ARPA]

>> There are many programs which believe that two structures with the same
>> initial set of elements have the same ordering for those elements.
>
>Fie!  For shame!  It was for this reason (among others) that unions
>and separate name spaces among structs were born.  Having two structs
>with the same initial set of elements -- and trusting them to stay
>that way, even through your novice programmer's "fixes" and the new
>A. E. Neumann C Compiler XXX -- isn't all that reliable.
>
>Joe Yao		(UUCP!seismo!hadron!jsdy / hadron!jsdy at seismo.ARPA)

Sigh,
	until you give me a subclass mechanism that ensures that the
representation of two data types share a common prefix, I'll rely on this
compiler hack.  Yes, you can declare a new type to represent the common
prefix part, but a proliferation of new little types can also confuse the
innocent.

	typedef struct{
		foo a,b;
		} prefix;

	typedef struct{
               prefix p;
	       < t1 specific>
	       bar c;
	       } t1;
	
	typedef struct{
	       prefix p;
	       < t2 specific >
	       baz d;
	       } t2;

   .... 	aT1.p.a   .... aT1.c

You could fix the lack of uniformity in using shared-vs-unique fields by
having more control over the naming environment.  For instance, you could
define
	typedef OPEN struct{...} prefix;
where the "OPEN" modifier allows unqualified access to fields defined in
the the type "prefix."
Thus, when fields of type prefix are defined, the namespaces of "prefix"
and those of the record being defined arenot disjoint.

	Then, once better control over names are in place, you can introduce
PUBLIC, PRIVATE, OPAQUE and get clusters....

-- Mark Tucker