--PEfPc/DjvCj+JzNg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 14, 2007 at 05:34:04PM -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 14, 2007 at 02:21:45PM -0800, Bill Stouder-Studenmund wrote:
> > On Wed, Nov 14, 2007 at 04:57:16PM -0500, Thor Lancelot Simon wrote:
> > > Lots of operating systems, over the years, have had bugs in mmap() su=
ch
> > > that, for example, writing a byte into a page notionally backed by a
> > > file that has a hole in it causes a segfault or bus error.
> > >=20
> > > We appear to have such a bug for _reading_ files consisting only of h=
oles;
> > > see the program below.  Modifying the program to write one byte to the
> > > file before the lseek() that extends it causes the segfault to go awa=
y.
> >=20
> > Where do you explicitly grow the file? lseek() alone won't change the f=
ile=20
> > length. It is legal to lseek() past EOF.
>=20
> Hm.  Yeah, and if I throw a read() in back to the lseek to 0, it does
> indeed return 0 bytes: EOF.
>=20
> > I think what you want to throw in is an ftruncate().
>=20
> 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?

It's how I'd expect it to work (fail when accessing), but I'm not sure=20
what standards say. Among other things, you could map, grow then file,=20
then the pages should work. :-)

Take care,

Bill

--PEfPc/DjvCj+JzNg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHO3vDWz+3JHUci9cRAoNKAJ9D2AZL29xCbUMu9j1WfqnJNuWBwwCcDYvy
t2x9iuk5eUoKJFTCh7bwsUE=
=Y4I9
-----END PGP SIGNATURE-----

--PEfPc/DjvCj+JzNg--