On 964668802 seconds since the Beginning of the UNIX epoch
Greg A. Woods wrote:
>
>>  One would have the same problem if
> one tried to compare these two files with only two read(2)s.  :-)
>
>nobody in their right mind would try to do that!  ;-)

Then one should not expect to compare two files with two mmap(2)s.
:-)  The problem here is in the usage of mmap(2), not in the mmap(2)
API which is relatively straightforward.

>However I'm not sure the bug is *really* fixed.  Shouldn't the test used
>to avoid mmap() be to see if the length is bigger than (SIZE_T_MAX / 2)?

Well the current code falls back to stdio in any case where the
mmap(2)s fail, so it should work.

SIZE_T_MAX / 2 is still too large, because it does not account for
the kernel address space and the memory that is used by cmp for
other purposes.  Probably the best approach would be to use mmap(2)
in a manner more consistent with how one would use read(2), i.e.:
mmap(2) relatively small chunks of the file in a loop.

>Does mmap() really fail if the file is bigger than the *remaining* size
>of the process's address space (the manual page makes no obvious claims
>along these lines)?

It really has to fail, since there is no way to give you back a
char * that can access data beyond the end of your address space.
And in fact it is more hairy than that because it must find a free
contiguous region in your address space to hand back to you.  This
may be the reason that 2.6GB of files couldn't be mapped.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==