Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!lll-tis!oodis01!uplherc!sp7040!obie!wes From: wes@obie.UUCP (Barnacle Wes) Newsgroups: comp.lang.c Subject: Re: Optimal structure field ordering Summary: True, but... Message-ID: <76@obie.UUCP> Date: 5 Jul 88 05:35:55 GMT References: <163@navtech.uucp> <806@garth.UUCP> <254@obie.UUCP> <8192@brl-smoke.ARPA> Organization: the Well of Souls Lines: 32 In article <254@obie.UUCP> I wrote: % It would be very difficult to write a file system portable % across machines of varying architecture (i.e. Idris) if the compiler % on each machine can arbitrarily re-arrange structures to suit its own % whim. In article <8192@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) replied: > Although the original poster was mistaken about the order in which > struct members are assigned addresses, it is nonetheless impossible to > achieve binary file transportability simply by (acceptable) constraints > on C struct format. There is a LOT more to binary data transportability > than byte padding, alignment, and sequencing. True. I was just pointing out that if the compiler was able to re-order the structure, you could obtain this portability at the source level at all. You would have to write code to read in the structure from the mass storage and then assign it to the individual elements of the in- memory structure. I believe Idris assures that all disk reads and writes are done in a common format, and the structure elements fall into place as the bytes and/or words are swapped as they are read and written. Structure ordering does not result in portability, but lack of structure ordering (nearly) precludes portability. Perhaps the compiler could be signalled when not to `optimize' the structure ordering - a `volatile' structure?!?!?!? ;-O -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --