Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!snorkelwacker!bloom-beacon!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.fortran Subject: Re: File handling in Fortran 77 Message-ID: Date: 1 Sep 90 09:10:47 GMT References: <46016@masscomp.ccur.com> <1990Aug29.173235.9405@ux1.cso.uiuc.edu> <55875@iuvax.cs.indiana.edu> <56015@iuvax.cs.indiana.edu> Sender: burley@world.std.com (James C Burley) Organization: The World Lines: 79 In-Reply-To: bomgard@copper.ucs.indiana.edu's message of 31 Aug 90 18:42:32 GMT I think this discussion kind of fragmented from what I thought the original intention was. I perceived the original issue as whether systems that couldn't "natively" represent files in a manner perfectly suited to C's standard I/O library were a "joke" and/or "deficient". So a system (PRIMOS) that could only remember the # of 16-bit words, rather than 8-bit bytes, was deficient. Sure, the C implementation could throw in an extra 16-bit word at the end of every file containing an indicator of whether the preceding word contained one or two bytes. But even Fortran I/O COULD implement C's low-level approach by throwing each character in a separate record, thus incurring the huge overhead of transacting Fortran records just to deal with low-level bytes. So your suggestion about possible solutions is fine in some ways, especially on systems where it truly writes only one byte each time. But that won't work on all, or perhaps even many, systems; how would PRIMOS track the number of records written if it only wrote one byte per one-byte record, given that it had only a count of 16-bit words available? Thus EOF would be potentially inaccurate. Agreed that ultimately we're all talking about gathering bits into blocks into characters and back again, but to keep the discussion on track, I think it is worthwhile to focus on the issue of what is native, or natural, for a file system. PRIMOS could (and does) implement per-record or per-file information in the data portion of a file that helps it cope with Fortran I/O. Thus one cannot use Fortran I/O to read a file in its raw, byte-by-byte, form; a file written by a C program might thus be unreadable, unless that C program was specifically designed for the task (and hence is not portable). Obviously one is not accessing the disk file itself on a char-by-char basis; I was pointing out that using RECL=1 does not, according to the Fortran standard and many implementations as well, give you byte-by-byte access to the lowest level (normally permitted user programs) of access to a file's data. Using C's fputc, fgetc, and so on, also does not make such guarantees, but many more systems grant you that low-level access, and historically, I believe, a larger percentage of C programs have been written as general utilities (read/write files to be accessed by other programs written in other languages) than Fortran programs. When you say "The lowest level of (disk) file organization is the block, and that's usually NOT what C (or any other) programmers want. C's 'byte-level access' is itself a 'higher layer on the system's native layer.'", I feel the need to point out that the issue concerned systems whose OS's imposed a HIGHER layer on the disk file than desired by a particular LANGUAGE. So I agree there is a distinction between the language and the OS: the lowest layer of access provided by an OS is the lowest layer of access that can be provided by a particular language running on that OS while using "natural" (i.e. no extra coding) access. So operating/file systems written with lowest-layer access being sufficient for contemporary languages like Fortran, PL/I, and Pascal, should not be considered "jokes" and "deficient" just because some new language, C, comes around and asks for yet a lower layer, requiring changes to file system code, on-disk file format changes, and resulting upheavals at customer sites having to run some kind of conversion program on all their disks. And this scenario would apply if my made-up language "X" came along and became popular and required bit-layer access to files (so a file could contain, say, exactly 3 bits), and its zealots claimed any system that didn't support that in native mode was a "joke" and "deficient". In fact, this scenario would, to my knowledge, apply to ALL commonly used systems today. Somebody else correctly pointed out earlier in this discussion that even the view put forth, which I agreed with, that a file is simply a string of bits, is overly constraining. I defer to that more generally correct point of view: just because a Macintosh file has both a data fork and a resource fork does not mean it is NOT a file in any useful sense of the word. Yet one cannot view it in its natural form as a string of bits; perhaps two strings, but even then, one string really contains resources, not bits. The internal representations of the resources, and the way the resources themselves are hung together, are generally of no concern to the ordinary users of the file (including the applications that define the file and manage its resources). Obviously, C's view of files is inadequate in this case, and C programmers must resort (much like Fortran programmers naturally do) to calling on functions that impose a "higher" organization on a file than simply a stream of bytes (or bits). James Craig Burley, Software Craftsperson burley@world.std.com