Subject: Re: Bug in mmap() for files with holes
To: None <tech-kern@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 11/14/2007 17:40:28
On Wed, Nov 14, 2007 at 05:34:04PM -0500, Thor Lancelot Simon wrote:
> 
> > I think what you want to throw in is an ftruncate().
> 
> Probably so.  Our mmap() page is not sufficiently precise, and I don't
> have the posix realtime spec -- that's where it's specified, right? -- so
> I don't know if mmap() is supposed to succeed, but accesses then fault,
> when the mapping goes past the current EOF.  Is that how it is supposed
> to work?

Actually, there's a difference in behavior here that still really bothers
me.

If I write one byte of 0 *at offset 0* then lseek to 1024, then mmap the
file with a length of 1024, memory-reads from the entire mapping return 0.

If I just create the file and do the lseek, memory-reads from any part of
the mapping cause a SEGV.

This seems wrong.

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "The inconsistency is startling, though admittedly, if consistency is to
   be abandoned or transcended, there is no problem."	      - Noam Chomsky