Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!mailrus!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!midway!tank!stephen From: stephen@estragon.uchicago.edu (Stephen P Spackman) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: Message-ID: Date: 9 Sep 90 18:04:17 GMT References: <1990Aug27.152540@bert.llnl.gov> <1990Aug28.211752.24905@zorch.SF-Bay.ORG> <1990Aug28.173553@bert.llnl.gov> <1990Sep1.131041.15411@zorch.SF-Bay.ORG> <1990Sep8.154622@objy.objy.com> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago CILS Lines: 58 In-Reply-To: peter@objy.objy.com's message of 8 Sep 90 22:46:22 GMT [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