Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!harriett!hirchert
From: hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert)
Newsgroups: comp.lang.fortran
Subject: Re: record length for direct access files
Message-ID: <1990Oct1.171231.10402@ux1.cso.uiuc.edu>
Date: 1 Oct 90 17:12:31 GMT
References: <MCCALPIN.90Sep24090852@pereland.cms.udel.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert)
Organization: National Center for Supercomputing Applications
Lines: 62

In article <MCCALPIN.90Sep24090852@pereland.cms.udel.edu> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:
>Silicon Graphics revised the behavior of their Fortran compiler for
>direct access files in release 3.2 of their O/S to define the record
>length (RECL=NNN) in words rather than bytes.  In explanation, the
>release notes state:
>
>	"The ANSI standard states that the specified record lengths
>	 for unformatted direct access files must imply the number of
>	 words."
>
>Since I have observed a variety of behaviors for this particular
>issue, I decided to look it up in the new standard.  
>
>From the Fortran-90 draft S8, version 112, section 9.3.4.5, discussing
>the RECL= parameter to the OPEN statment:
>
>	"If the file is being connected for unformatted input/output,
>	 the length is measured in processor-dependent units."
>
>AAAAARRRRRRGGGGGGHHHHHH!
>
>Is this in the current draft?  I can't believe that after all the
>committee's mouthing about portability, they have let this one slip
>through.  No, on second thought, I believe it entirely....
>
>Not only do they give the vendors more license for incompatible
>processor-dependent variability, but they skip the obvious fix of
>giving us a SIZEOF() intrinsic function that would enable us to code
>around the problem....

As several other people have already pointed out, SGI is wrong!  FORTRAN 77
specifies the use of processor-dependent units.  In practice, this means
either bytes or words, but in theory it could mean bits or pages.

Fortran 90 also uses processor-dependent units for at least two reasons:
o  Forcing a particular unit (e.g., bytes) would "break" many existing programs
   (e.g., those written on systems that currently use words).
o  Choosing a particular unit might interfere with future extension.  (E.g.,
   choosing bytes as the i/o unit might be less than appropriate on a machine
   that could control record lengths in units of bits.)

Fortran 90 skipped the "obvious" fix of a SIZEOF() intrinsic function because
the "obvious" fix doesn't always work.  In particular, the size of a record is
_not_ always the sum of the sizes of its components.  Even worse, the sum of
the sizes of the components wasn't even a bound on the size of the record; we
were able to identify both cases of a record needing to be larger than the
sum of the sizes of its components (due to issues such as alignment) and cases
of a record being smaller than the sum of the sizes of its components (due to
partial unit reuse/overlap).

Instead, Fortran 90 offered the capability to use the INQUIRE statement to
determine the size of complete records.  If you are writing only one kind of
record, you can simply feed the result of the INQUIRE back into an OPEN.  If
you are writing more than one kind of record, you can inquire on each and
pass on the maximum.  Really ambitious programmers could attempt restructuring
records in order to produce sets of records that are the same size (or nearly
so) in order to optimize disk usage.  (You can also deduce SIZEOF() type
information on machines where that model holds, but remember that this may
limit your portability.)
--
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications