Re: C struct Ordering Rules (Michael Meissner)
Tue, 1 Nov 1994 15:32:27 GMT

          From comp.compilers

Related articles
CProf cache profiling system available (1994-10-13)
Re: C struct Ordering Rules (1994-10-31)
Re: C struct Ordering Rules (1994-10-31)
Re: C struct Ordering Rules (1994-11-01)
Re: C struct Ordering Rules (1994-11-01)
Re: C struct Ordering Rules (1994-11-01)
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: (Michael Meissner)
Keywords: C, design
Organization: Open Software Foundation
References: 94-10-108 94-10-206
Date: Tue, 1 Nov 1994 15:32:27 GMT (John Powell) writes:

| Most programs will work with struct reorganization if you do all of the
| following:
| 1. Recompile all the libraries that go into the program and all the objects
| using whatever flags are necessary.

And of course the operating system, and fix these rules for all time.
Basically, you get one shot to play with these (ie, the initial release and/or
the ABI, which ever comes first), and any change beyond that is extremely
painful. People who don't realize this haven't put much thought into support
and lifecycle issues. Real world systems all have historical baggage -- you
either have to live with that baggage, or throw it all out and start over. The
problem with throwing it all out, is that often times customers will decide
that as long as they have to change or even recompile their code, they might as
well do it on a competitors platform instead.

One thing that people immediately think of in these type of contexts (and more
so for machines that span 16/32 bit boundaries or 32/64 bit), is to just add
another set of libraries with the different compiler options thrown. I tend to
call such things as doublers, because each new set of switches, doubles the
number of libraries. This causes confusion (umm, which option did I compile
these objects for and which option did I compile these libraries for), and in
my experience, some customers are confused as it is without help from the
vendor. In addition to libraries, you might need new OS traps as well, and the
bloat tends to add up.
Michael Meissner email: phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.