🚀 go-pugleaf

[Apologies in advance for the temperature level - I think my
thermostat is broke]

In article <1990Sep8.154622@objy.objy.com> peter@objy.objy.com (Peter Moore) writes:
   In article <1990Sep1.131041.15411@zorch.SF-Bay.ORG>,
   xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:

   << I will paraphrase, since the >>'s were getting too deep:  
	  If the standard doesn't mandate structure layout, then compiler
	   writers will be free to change structure layout over time and
	   render all existing stored binary data obsolete
   >>

   Now hold on.  There may be arguments for enforcing structure layout,
   but this sure isn't one of them. If the different releases of the
   compiler change the internal representation of structures, then all old
   binaries and libraries will become incompatible.  This is immediately
   unacceptable to me, without any secondary worries about old binary
   data.  If a vendor tried to do that, I would simple change vendors, and
   never come back.  And no sane vendor would try such a change.  The
   vendor himself has linkers, debuggers, libraries, and compilers for
   other languages that all would change, not to mention thousands of
   irate customers burning the vendor in effigy.

Now you hold on. Since the binary layout of structures is NOT defined,
any code that relies on it is BROKEN. Your old binaries, if they are
properly written, are not "damaged" by a binary representation
upgrade, any more than installing a new machine with a different
architecture on your local net breaks existing applications: if the
applications WEREN'T broken, they still aren't, because they do not
rely on undefined behaviour.

As for the libraries, I'm sure the vendor will be glad to supply new
copies of the ones he provides with the upgrade (and I assure you that
his recompiling them will not be half such a chore as you imply), and
your own you can rebuild with make(1).

Furthermore, you notice that your "solution" is insane: changing
vendors regularly will make the "problem" happen more often and more
severely, unless you ultimately succeed in finding one who has a
strict bug-maintenance policy and effectively never upgrades his
product. A more sane solution would be never to install upgrades, and
just learn to work around the limitations you encounter (like not
being able to generate code for a new architecture, for example).

   The standard can never protect you from an incompetent or malicious
   vendor.  It can only act as a common ground for well intentioned
   vendors and customers to meet.

Or, in this case, competent and well-intentioned vendors who try to
keep up with the technology.

I don't know if I'll ever end up writing commercial compilers, but if
I do, Mr. Moore, please do us both a favour and don't buy them.
Because you can *bet* that more than just binary layouts are going to
change as the optimisation library is extended.

stephen p spackman  stephen@estragon.uchicago.edu  312.702.3982