Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Question on MMAP(2)
Message-ID: <4e4cbbb5.1bc5b@pisa.ifs.umich.edu>
Date: 29 Nov 90 17:19:12 GMT
References: <1990Nov28.172733.7570@swift.cs.tcd.ie>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 19

In article <1990Nov28.172733.7570@swift.cs.tcd.ie>, mbrennan@swift.cs.tcd.ie writes:
  Can anyone explain to me how the mmap(2) system call actually works.
  I know that it maps an area from a file into virtual memory, but I
  am not sure of some of the finer details of the relationship between 
  the size of the file as it appears in the file system and the size of 
  the mmap'ed area?

It's really very simple.  Files are allocated, stored, and mapped in pages,
which are either 1k or 4k bytes.  But since most Unix programs expect to
read and write bytes, not pages, the length of the file is also stored
somewhere (in the inode, actually).  If you map a file, you can read and
write all of the bytes in the pages you mapped, even past the "end" of the
file.  But the "size" of the file (as returned by stat()) determines how
many bytes you can actually read (from read()).

It wouldn't be a good idea to depend on this "feature."  Reading and writing
in portions of a mapped file past the "end" may work today, but it's
technically undefined behavior, and certainly depends at least on the page
size.