Re: A sick idea - mmapped file output

[Michael Meissner <meissner at cygnus dot com>]

On Wed, Nov 08, 2000 at 09:28:07AM -0800, Zack Weinberg wrote:
> Being able to assume that the entire file is in memory makes for
> considerable simplifications in various parts of cpplib.  We don't
> ever have to worry about multiple-character tokens being split across
> a chunk boundary, for instance.  (Anyone remember read_and_prescan? It
> was hairy and slow, precisely because it did have to worry about
> that...)  mmap fits that model better than read.  Of course, I have to
> keep the read code around for systems that don't have mmap, and for
> reading from pipes.

I wonder if any of the legacy platforms (ie, mainframes, VMS, etc.) that have
strange I/O encodings also support a 'mmap' call?  Ie, there were systems out
there that stored a byte count at the beginning of the record (possibly omiting
the newline); systems out that that blocked text records into fixed sized
'card' imagages, padding with extra spaces at the end; systems whose
'read/fread' calls translated from externally from EBCDIC to ASCII (or from a
local varient of EBCDIC/ASCII to the standard one), systems without read at all
(you have to use stdio); and of course systems that consider an end of line to
be \r, \r\n, \n\r, or any other varient.  Furthermore, I wonder if GCC was
supported on such systems (VMS and MVS both come to mind as platforms GCC has
supported in the past that have non-bytestream I/O).

As I said previously, there were systems in the past whose mmap did not play
with read/write, and you would read the wrong bits if you used mmap to read a
file written by write (due to mmap not looking in the buffer cache).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482