Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!decwrl!sgi!shinobu!odin!dinkum!calvin
From: calvin@dinkum.wpd.sgi.com (Calvin H. Vu)
Newsgroups: comp.lang.fortran
Subject: Re: Bug with file I/O?
Message-ID: <1991Jan25.000843.21376@odin.corp.sgi.com>
Date: 25 Jan 91 00:08:43 GMT
References: <quan.664695995@sol>
Sender: news@odin.corp.sgi.com (Net News)
Distribution: comp
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 62

In <quan.664695995@sol> quan@sol.surv.utas.edu.au (Stephen Quan) writes:

| I ran the following on our SunOS machine, and guess what the output is?
| 
| ------>start of test.f<------
|       program test
|       integer     buff(1)
|       character*4 tmp
|       equivalence (tmp,buff)
| 
| 1     format (a4)
| 
|       open (10,file='test.dat',access='direct',recl=8,form='formatted')
|       buff(1) = 10
|       write (10,1,rec=1) tmp
|       buff(1) = 0
|       read  (10,1,rec=1) tmp
|       write (*,*) buff(1)
|       close (10)
| 
|       end
| ------>end of test.f<------
| --
	The problem is that you are trying to write binary data to a 
    formatted file.   UNIX I/O library assumes that all data written
    to a formatted file are "readable" characters and hence uses <CR>
    which happens to be the number you are using to determine record
    boundary.

    The scenario is:

    You write out 4 bytes: \0 \0 \0 <CR>
    and then read it back in. Since the I/O library interprets the <CR>
    as the record terminator it only reads in 3 bytes \0 \0 \0.  And
    since your READ statement requested for 4 bytes it substitute the
    missing data byte with 32 (i.e. blank character) which is appropriate
    for the A4 format.  So you have the number 32.

	You can probably do a similar tricks without having to equivalence
    'buff' to 'tmp'.  Writing 'buff' using A4 format gives a similar bad
    result.   Ditto for FORM='formatted' without ACCESS='direct'.

	On SGI system we have FORM='binary' to do exactly this type of
    unorthodox programming, i.e. writing binary "unreadable" data to a
    formatted file.

	If you are using direct access file, I don't see why you should not
    use unformatted file instead of formatted.  It probably makes the I/O
    faster and your record 1 byte shorter (i.e. no <CR> appended).

    On the other hand, MAYBE this can qualify as a bug since
    you may argue that the record boundary for a direct-access record should
    be determined by the record length (or the last <CR> in that record)
    and not the first <CR> the I/O library runs into.

| Stephen Quan,
| University of Tasmania.
--
-----------------------------------------------------------------------------
Calvin H. Vu			   | "We are each of us angels with only one
Silicon Graphics Computer Systems  | wing.  And we can only fly embracing
calvin@sgi.com   (415) 962-3679	   | each other."