Re: libc6 bug? or C programming error?

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Oliver Elphick <olly@lfix.co.uk> writes:

> On Wed, 2003-12-03 at 00:52, viro@parcelfarce.linux.theplanet.co.uk
> wrote:
> > >   /* map the file and load an extra page in case the new line expands the
> > >      file across the page boundary; adding 2 allows for the truncating
> > >      effect of integer division.  Forcing an extra page ensures
> > >      that we can identify the end of the buffer by finding a NUL */
> 
> > No, it does not.  Access past the EOF will give you page fault, not zero-filled
> > page.
> 
> Do you think that is connected with this problem?  There is no error
> when the mmap() call was executed; the segfault occurs a little later,
> as the trace shows.

The segfault appears when you first access the invalid page.

       A file is mapped in multiples of the page size. For a file that
       is not a multiple of the page size, the remaining memory is
       zeroed when mapped, and writes to that region are not written
       out to the file.  The effect of changing the size of the
       underlying file of a mapping on the pages that correspond to
       added or removed regions of the file is unspecified.

Mapping more pages than the file has fall under "is unspecified" I
believe. Your hack should work unless the mapped file is a multiple of
page size, then no 0 bytes are added.

Is that the case?

> Does that mean you cannot use mmap() and related calls to extend the
> length of a file?

You can't. You have to increase the file size first, then mmap and
then use. If someone changes the file size under you (truncate the
file for example) you get a segfault if you access past the end of the
file.

Why not use memchr() instead?

MfG
        Goswin