Re: C struct Ordering Rules

bbpy969@server4.bell-atl.com (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: meissner@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
--

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