Subject: Re: bin/10625: /usr/bin/cmp is unable to compare rather large files
To: NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
From: Greg A. Woods <>
List: netbsd-bugs
Date: 07/27/2000 15:35:48
[ On Thursday, July 27, 2000 at 09:15:04 (-0700), R. C. Dowdeswell wrote: ]
> Subject: Re: bin/10625: /usr/bin/cmp is unable to compare rather large files 
> 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.

Yeah, I know -- but it's at least closer to correct than the currently implemented test!

>  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.

Hmmm....   Sfio springs to mind again here....

> >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.

But does it actually *really* always fail when there's no more room in
your maximum allowed process size?  I've not tested it yet, and I am
very leary of mmap() given previous bugs it has suffered.

If it does fail then this failure case should be documented (more?)
clearly in mmap(2).

Is there a regression test to make sure it continues to fail when it
should?  It doesn't appear src/regress/sys/uvm/mmap/mmap.c has a test
for this case....

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>