Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cbosgd.UUCP
Path: utzoo!linus!decvax!harpo!eagle!hou5h!hou5a!hou5d!hogpc!houxm!ihnp4!cbosgd!mark
From: mark@cbosgd.UUCP
Newsgroups: net.lang
Subject: Re: I/O operations in programming langua - (nf)
Message-ID: <253@cbosgd.UUCP>
Date: Mon, 29-Aug-83 23:58:15 EDT
Article-I.D.: cbosgd.253
Posted: Mon Aug 29 23:58:15 1983
Date-Received: Thu, 1-Sep-83 04:44:42 EDT
References: <382@ima.UUCP>, <109@csd1.UUCP>
Organization: Bell Labs, Columbus
Lines: 34

Micheal Condict:

Do you propose adding funny character arrays to the C language and
calling them "files"?  If so, are you willing to assume that all
machines that run C will have virtual memory?  If so, you can have
a nice pmapped implementation of files, given proper operating system
support.  4.2BSD does not have such support, although it is on the list
of things for 4.1d, which will presumably wind up in 4.3.  However, I
think this assumption kills portability.

If you don't assume virtual memory, then the compiler will have to
make a distinction between character arrays that are files and character
arrays that are not files, generating different code for each.  (Certainly
just dumping things into/out of memory at a given byte offset won't work
if the file won't fit in memory; yet for regular character string operations
you want tight efficient code.)  Now, suppose you want to use a function
you have written that does character string manipulation.  (Say, sprintf,
or strcmp, or something you write yourself.)  The parameter to this function
ought to be allowed to be either a real character array or a file.
(After all, isn't the whole point to be able to use string operations on files?
And all our string operations are functions in the C library.)  Now, what
will the generated code for this function look like?  How will it tell whether
it's a file or a regular old pointer?  The absolute best you can do is to
include a descriptor, either in the array (where is the beginning?) or in
the pointer.  Now, all the code in the function has to do a runtime check
on the descriptor for every string operation it does.  There goes your
efficiency of C code.

Or perhaps you have some other implementation in mind?  Let's see now, you
could keep a window into the file in core, and set up segmentation
registers to trap to a user routine when you run off the end or beginning
of the window.  There goes 8K of PDP-11 addressing space.  And what
happens if you do a very random access and happen to point into a valid
spot in your data area?