Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!diemen!sol!quan From: quan@sol.surv.utas.oz (Stephen Quan) Newsgroups: comp.lang.fortran Subject: Re: Bug with file I/O? Message-ID: Date: 25 Jan 91 00:20:32 GMT References: <1991Jan24.145718.28686@alchemy.chem.utoronto.ca> <2136@travis.csd.harris.com> <11495@helios.TAMU.EDU> <8483@hub.ucsb.edu> Sender: news@diemen.utas.edu.au Distribution: comp Lines: 45 3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) writes: >In article <11495@helios.TAMU.EDU> mkh6317@rigel.tamu.edu (HOWARD, MATTHEW KENDALL) writes: >>[...] >>You might want to look at the program again. There is nothing non- >>standard about it. >Yes there is. It equivalences character data to an integer. Should >still work, though. Stephen, check the fine print in your compiler >manual. You never know. > --Pierre Asselin, R&D, Applied Magnetics Corp. I speak for me. For those who wanted to know, I was running it on a Sparc 1, SunOS 4.0.3c, but I wouldn't have a clue what version our compiler is, all I can say is it is not the most recent version. In summary : 1. od of my file is : 0000000 000000 000012 000000 000000 0000010 so no problems about writing. 2. reading it back in the string produces 32 not 10. presumably formatted I/O interpreted 10 as a newline, and padded string with spaces. 3. works on some machines Apollo, IBM VS-Fortran and latest versions of Sun / Fortran combinations (from email responses). 4. 'unformatted' seems to be the general consensus for the solution, to which I am happily using :). 5. (Why?) The reason why I wanted this, was, I needed an economical way of storing integers and accessing them from a file. The program will be ultimately ported to a PC. Any other method of storage, apart the character storage will not be as ecomical, especially when I need about 150000 of them! Thanks to all who responded. Stephen Quan, University of Tasmania, Australia.