Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.lang.fortran
Subject: Re: File handling in Fortran 77
Message-ID: <1990Aug30.132335.20164@ux1.cso.uiuc.edu>
Date: 30 Aug 90 13:23:35 GMT
References: <46016@masscomp.ccur.com> <1990Aug29.173235.9405@ux1.cso.uiuc.edu> <BURLEY.90Aug30024743@world.std.com>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Organization: School of Chemical Sciences, Univ. of Illinois at Urbana-Champaign
Lines: 75

In article <BURLEY.90Aug30024743@world.std.com> burley@world.std.com (James C Burley) writes:
>In article <1990Aug29.173235.9405@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>
>   This has always bothered me. A file is just a sequence of it, usually
                                                              ^^
                                                   my typo - I meant bits
>   organized as bytes - a text file must be in "bytes".
>
>   So how, in standard Fortran, do you dothe exact analog of the most primitive
>   file operations - those expressed in C as flavors of get, put, and seek.
>   It HAS to be possible to do this, as C requires it.
>
>   Doug MCDonald
>
>You don't.  Standard Fortran is built on older and more baroque/primitive
>file storage technology than C/UNIX.  Fortran allows systems to implement
>files as consisting of zero or more fixed-length records, in particular.
>So while, in C, you can (or could if ANSI C and its libraries ran on such
>a system) read and write to arbitrary bytes in the file, in Fortran you
>can't do it without using system calls, tricks, or nonstandard usage.
>
>In Fortran, you can "seek" to a given record (if you've specified this
>desire in the OPEN statement, I think), but not to a given byte.
>
>As far as "HAS to be possible...as C requires it", this statement suggest you
>think C is written in Fortran?  Or maybe I misunderstand what is meant by
>this. 

I meant that a computer that can't run C is a joke. If it can run C,
it must be physically possible, and possible by some sort of OS calls.


> Generally speaking, Fortran demands a lot less from the operating system
>it runs on in terms of file support than C, even if it demands more from the
>run-time library to implement all its "features".  For example, I remember
>that PRIMOS couldn't exactly implement C files, since PRIMOS bytes were 8 bits
>but its file system (like the internal memory organization) was based on
>16-bit chunks.  If you wrote 21 bytes to a new file, closed it, and later
>read it, you'd get 22 bytes.  Unless they did some trick like check for a zero
>in the final byte, in which case if you wrote 22 bytes to a new file, the last
>one being zero, and later read it, you'd get 21 bytes.  (If any circa-1982
>PRIMOS experts read this and know any different, please let me know how they
>got around this problem.)  To do C correctly, PRIMOS would have needed a
>change to its file system to add the ability to track file length down to
>byte granularity.  Fortran support, however, rarely requires any changes to
>any file system, no matter how primitive.
>
In other words, you are saying Primes are (were?) so deficient that
they could not even tell how long a file was? 


>In Fortran, you can "seek" to a given record (if you've specified this
>desire in the OPEN statement, I think), but not to a given byte.
>

I still don't understand why not. A file IS a sequence of bits.  Why can't the
OS simply move those bits (as needed, or all at once, if the address
space is big enough) into memory and present them to the program?  If 
you had written the file with some arcane internal organization, you
would then SEE that organization, and could deal with as you pleased.


Incidentally, how do the OS's with the arcane file types get all that
arcana installed in the files? Not even in the CISC-yist  architectures
is it done in hardware is it? What language IS it done in? Certainly not
Fortran --- C? assembly? The point is that any language is joke if it is
severly limited in how it can use files. The "byte" model (or, even 
moreso the bit model) is general. The "record model" is a hindrance -
if it is the ONLY model a language or OS supports. A "record" model
would be OK as a language specific overlay of a basic general model.

But to have it stuffed deep down inside the OS as in VMS and IBM mainframes
is a disaster. 

Doug MCDonald