Subject: re: Bug in mmap() for files with holes
To: None <firstname.lastname@example.org>
From: matthew green <email@example.com>
Date: 11/15/2007 10:23:33
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.
what do you expect? this is what i would expect.