From owner-freebsd-hackers Sat Aug 21 11:11:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.33.127]) by hub.freebsd.org (Postfix) with ESMTP id 710AC14CF3 for ; Sat, 21 Aug 1999 11:11:10 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id LAA13809; Sat, 21 Aug 1999 11:10:15 -0700 (PDT) Message-Id: <199908211810.LAA13809@lestat.nas.nasa.gov> To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: mmap mapped segment length Reply-To: Jason Thorpe From: Jason Thorpe Date: Sat, 21 Aug 1999 11:10:14 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 Aug 1999 02:10:47 -0600 Wes Peters wrote: > I discovered to my dismay today that the length field in the mmap call is > a size_t, not an off_t. I was attempting to process a large (~50 MByte) file > and found I was only processing the first 4 MBytes of it. ...first of all, I assume you mean GByte, not MByte. The type of the "len" argument is specified by multiple standards. You could change size_t to a 64-bit quantity, but then you have: (1) A serious ABI incompatibility issue with the rest of the x86 world. (2) You'd have to go to 64-bit arithmetic everywhere in the VM code which could seriously impact performance. > Is this intentional, or just an artifact of the implementation? Is there any > reason NOT to change this to an off_t? -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message