[Bug manual/6886] some imperfections in description of mmap()

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=6886

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
         Resolution|---                         |INVALID

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
" mmap description does not say what value of parameter length should be :
   it gives impression that it can be
   anything that is not larger than multiple of pagesize that is next higher
than size of file ;
   is this correct ?"

   POSIX states that it can be anything and also states the returned segment
shuld adressable for range [pa,pa+len).  It is an implementation details if
underlaying granularity would be in page sizes.

" mmap() description does not mention what happens if writing beyond end of
file,
   though i seem to remember reading somewhere that it causes a segfault ?"

  man mmap:

  SIGBUS Attempted  access  to  a portion of the buffer that does not
correspond
  to the file (for example, beyond the end of the file, including the case
where 
  another process has truncated the file).


" mmap() description does not mention what happens if write to address that is
   beyond end of filecontent but inside mapped size ; will it segfault ?"

  Same as before.

" if a file is mmapped PROT_SHARED, and another process makes file smaller,
   will my process segfault when writing beyond new end of file ?
   is it possible to guard against this by locking file ?"

  man mmap:

  "MAP_SHARED      Share  this mapping.  Updates to the mapping are visible to 
   other processes that map this file, and are carried through to the
underlying
   file.  (To precisely control when updates are carried through to the
underlying
   file requires the use of msync(2).)"

"munmap description gives impression that if you do munmap it is not necessary
to use msync, but does not explicitly say so. is this indeed so ?"

  Yes and manual now states when you should call msync.

As for BZ#6887 I will close this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.