From dev-return-18467-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Jun 06 06:00:17 2007 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 45781 invoked from network); 6 Jun 2007 06:00:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jun 2007 06:00:16 -0000 Received: (qmail 38187 invoked by uid 500); 6 Jun 2007 06:00:19 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 38127 invoked by uid 500); 6 Jun 2007 06:00:18 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 38116 invoked by uid 99); 6 Jun 2007 06:00:18 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jun 2007 23:00:18 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [64.202.165.99] (HELO smtpauth05.prod.mesa1.secureserver.net) (64.202.165.99) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 05 Jun 2007 23:00:13 -0700 Received: (qmail 23836 invoked from network); 6 Jun 2007 05:59:50 -0000 Received: from unknown (24.15.193.17) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 06 Jun 2007 05:59:50 -0000 Message-ID: <46664D55.80402@rowe-clan.net> Date: Wed, 06 Jun 2007 00:59:49 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Davi Arnaut CC: Bojan Smojver , dev@apr.apache.org Subject: Re: [Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0 References: <46649707.6010808@rowe-clan.net> <1181086713.13346.20.camel@shrek.rexursive.com> <1181087244.13346.22.camel@shrek.rexursive.com> <4666116F.8030601@haxent.com.br> In-Reply-To: <4666116F.8030601@haxent.com.br> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Davi Arnaut wrote: > Bojan Smojver wrote: >> On Wed, 2007-06-06 at 09:38 +1000, Bojan Smojver wrote: >> >>> testlfs : Line 265: Large Files not supported >> Or is this just a misleading message saying "these things are enabled by >> default on this platform"? >> > > Good question. LFS doesn't exist for 64 bit platforms, but because it > supports large files out of the box. This leads to another question, > should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems > reasonably safe to do so. I've always understood HAS_LARGE_FILES to mean that offsets don't fit into a size_t alignment, they are larger offsets than are otherwise represented in memory. The thought that apr_off_t > off_t might also fit that bill. But no, we should probably figure out how to report this case more intellegently in testlfs so people don't panic. LARGE_FILES, imho, should not be set where special handling of the file offsets didn't happen.