Subject: Re: Bug in mmap() for files with holes
To: None <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
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
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 firstname.lastname@example.org
"The inconsistency is startling, though admittedly, if consistency is to
be abandoned or transcended, there is no problem." - Noam Chomsky