Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!alberta!mts.ucs.UAlberta.CA!Al_Dunbar From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Newsgroups: comp.lang.c Subject: Re: Binary data file compatibility across machines Message-ID: <1979@mts.ucs.UAlberta.CA> Date: 1 Dec 90 17:11:35 GMT References: <2172@tuvie> <1967@mts.ucs.UAlberta.CA> <2188@tuvie.UUCP> Organization: MTS Univ of Alberta Lines: 35 In article <2188@tuvie.UUCP>, hp@vmars.tuwien.ac.at (Peter Holzer) writes: >userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) writes: > >>In article <2172@tuvie>, hp@vmars.tuwien.ac.at (Peter Holzer) writes: >>>stiber@cs.ucla.edu (Michael D Stiber) writes: >>> >>> >>>>On different machines, the implementation of C data types is different. >><<>> >>> <<>> > >EBCDIC machines must convert character data (Both on read and write). >If they have 8bit-char, 16bit-short, 32bit-long they may read write >integers in their native format. If you are going to force EBCDIC machines to convert through ASCII on input and output, why not have all versions of your program produce identical output? Then you needn't have the short header, or the "overhead" of decoding it. I guess I misunderstood your original posting to be addressing a general case of binary file portability. One problem with your approach (though it appears to work well in your environment) seems to be that the code must be tailored for each machine it runs on in order to compensate for architectural differences. Thus, you may achieve data portability, but have lost program portability. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | "this mind left intentionally blank" CANADA | - Manuel Writer -------------------+------------------------------------------- Brought to you by Super Global Mega Corp .com