Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 7/17/84; site link.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!link!ekb From: ekb@link.UUCP (Eric K. Bustad) Newsgroups: net.lang.c Subject: Re: struct element orderin vs. alignment. Message-ID: <289@link.UUCP> Date: Fri, 11-Jan-85 17:15:33 EST Article-I.D.: link.289 Posted: Fri Jan 11 17:15:33 1985 Date-Received: Sat, 12-Jan-85 07:50:24 EST References: <7112@brl-tgr.ARPA> Organization: AT&T Bell Laboratories - Holmdel, NJ Lines: 55 > >> 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@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,}; .... 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