MMAP issue on cygwin

[Florian Weimer]

Zack Weinberg <zack@codesourcery.com> writes:

> On Fri, Dec 28, 2001 at 11:13:29AM +0100, Florian Weimer wrote:
>> Neil Booth <neil@daikokuya.demon.co.uk> writes:
>> 
>> > It would appear we've mmap-ed longlong.h, and that the bytes beyond
>> > the end of the file are not NULs.
>> 
>> This shouldn't matter.  It is a bug to access data beyond the end of
>> the file because the results are indeterministic.
>
> You're mistaken.  SUSv4 says
>
> 	The system always zero-fills any partial page at the end of an
> 	object. Further, the system never writes out any modified
> 	portions of the last page of an object that are beyond its
> 	end. References within the address range starting at pa and
> 	continuing for len bytes to whole pages following the end of
> 	an object result in delivery of a SIGBUS signal.

AFAIK, on GNU/Linux on x86, SIGSEGV is delivered (if a signal is
delivered at all).

Anyway, what can you gain, in terms of implementation maintainability
and efficiency, if you rely on a certain behavior of mmap() in these
border cases?  

(Just an example of what can go wrong: IIRC, the INN optimization for
the active file breaks if the file size is a multiple of the page size
(and the above semantics are implemented.)

> I haven't got a copy of the Austin revisions to look at, but I doubt
> this would have changed.

It hasn't.

> If you think about it, it is a security hole to do anything else.

I agree, but at least one file system author told me that he is not
willing to zero partial pages because of performance concerns, but I
suppose the problem is fixed now.