Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!rex!uflorida!travis!hcx2.ssd.csd.harris.com!bill From: bill@hcx2.ssd.csd.harris.com (Bill Leonard) Newsgroups: comp.lang.fortran Subject: Re: Bug with file I/O? Message-ID: <2136@travis.csd.harris.com> Date: 24 Jan 91 21:14:16 GMT References: <1991Jan24.145718.28686@alchemy.chem.utoronto.ca> Sender: news@travis.csd.harris.com Reply-To: bill@hcx2.ssd.csd.harris.com (Bill Leonard) Distribution: comp Organization: Harris Computer Systems Division, Fort Lauderdale, FL Lines: 28 In article <1991Jan24.145718.28686@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: > Our Apollo (SR10.2 / ftn 10.7) gives '10' for this program. > Looks like a broken compiler to me. Have you tried dumping the > 'test.dat' file (with 'od') to see if it is the write or the read that > is messing up? As an aside, why not use binary/unformatted direct I/O; > it is orders of magnitude faster than formatted I/O on all systems I > have ever used? Beware! Unformatted I/O is not guaranteed to work if you mix data types. Writing an INTEGER and reading a CHARACTER may give unpredictable results. In any case, you cannot say the original compiler is broken, because this program is non-standard. Using an A edit descriptor with non-character data is non-standard and non-portable. Unless the user's manual specifically says it is supposed to work and specifically says you can mix this with character data, you probably can't. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com --------------------------------------------------------------------------- I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated. -- Poul Anderson ---------------------------------------------------------------------------