Hi. This is the qmail-send program at mail.netbsd.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<netbsd-bugs@netbsd.org>:
This message is looping: it already has my Delivered-To line. (#5.4.6)

--- Below this line is a copy of the message.

  by mail.netbsd.org with SMTP; 3 Aug 2000 14:38:49 -0000
  by mail.iac.spb.ru with SMTP; 3 Aug 2000 13:23:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: netbsd-bugs@netbsd.org (NetBSD Bugs and PR posting List), gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups)
Subject: Re: bin/10625: /usr/bin/cmp is unable to compare rather large files 
In-Reply-To: <20000727161504.3BB53DE0@mabelode.imrryr.org>
References: <20000727033322.066B88D@proven.weird.com> <20000727161504.3BB53DE0@mabelode.imrryr.org>
Reply-To: netbsd-bugs@netbsd.org (NetBSD Bugs and PR posting List), gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups)
Organization: Planix, Inc.; Toronto, Ontario; Canada
Message-Id: <20000727193548.8E4588F@proven.weird.com>
Date: Thu, 27 Jul 2000 15:35:48 -0400 (EDT)
Sender: netbsd-bugs-owner@netbsd.org

[ 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      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>