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 <email@example.com>
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 <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>