This is the mail archive of the
mailing list for the GCC project.
Re: A sick idea - mmapped file output
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: email@example.com phone: +1 978-486-9304
Non-work: firstname.lastname@example.org fax: +1 978-692-4482