struct element orderin vs. alignment.

[Eric K. Bustad]

> >> 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.
>		. . .
>
> -- Mark Tucker

I suspect that Joe had something like this in mind:

	#define T1 0
	#define T2 1

	typedef struct {
		int subclass;	/* either T1 or T2 */
		foo a,b;
		union {
			struct {
				foo c
				bar d;
			} t1;
			struct {
				foz c;
				baz e;
			} t2;
		} noncom;
	} bigclass;
	
	bigclass aT1 = { T1, <initial values for other common fields> };

	....  aT1.a
	if (aT1.subclass == T1) {
		.... aT1.noncom.t1.c ....
	}

The referencing of non-common fields does get rather ugly,
but this will certainly ensure that T1 and T2 structures
have the same prefix.

= Eric Bustad (AT&T Bell Laboratories, Holmdel NJ)
  +1(201)949-6257
  ihnp4!eric.bustad or link!ekb