Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Optimal structure field ordering Message-ID: <8225@brl-smoke.ARPA> Date: 8 Jul 88 16:40:16 GMT References: <5233@ihlpf.ATT.COM> <163@navtech.uucp> <806@garth.UUCP> <254@obie.UUCP> <3459@rpp386.UUCP> <4347@pasteur.Berkeley.Edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 18 In article <4347@pasteur.Berkeley.Edu> faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes: >(1) What if I write a binary data file (with structures), re-compile my >program (not having realized that somebody installed the new compiler >with structure optimization) and then try to read it back in? This sort of change does occasionally occur. Gould changed their calling sequence between two releases of UTX/32. At least one VAX C compiler packs struct members more tightly than the original UNIX 32V PCC. And so on. Mixing output from different compilers has always been hazardous. This and related issues fall into what X3J11 terms the "quality of implementation" bin. The only constraint on such behavior lies in its acceptability to customers. It really isn't proper for the language standard to try to nail down such implementation-specific details; in fact it's extremely hard to write such specifications in a way that applies reasonably to all implementations. Thus it is considered overspecification and is not done.