Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 3101 invoked from network); 23 Oct 2007 22:08:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Oct 2007 22:08:12 -0000 Received: (qmail 35468 invoked by uid 500); 23 Oct 2007 22:07:59 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 35422 invoked by uid 500); 23 Oct 2007 22:07:59 -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 35411 invoked by uid 99); 23 Oct 2007 22:07:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2007 15:07:59 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.95] (HELO smtpauth04.prod.mesa1.secureserver.net) (64.202.165.95) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 23 Oct 2007 22:08:02 +0000 Received: (qmail 5633 invoked from network); 23 Oct 2007 22:07:37 -0000 Received: from unknown (24.15.193.17) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 23 Oct 2007 22:07:35 -0000 Message-ID: <471E70A7.3060601@rowe-clan.net> Date: Tue, 23 Oct 2007 17:07:35 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Lucian Adrian Grijincu CC: APR Developer List Subject: Re: ABI change when _FILE_OFFSET_BITS=64 due to use of ino_t References: <4d45da050709181037y35b24802tc81cbc4def17d208@mail.gmail.com> <471E6D17.2040200@rowe-clan.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Lucian Adrian Grijincu wrote: > > Oh, yeah, you're right, there's no need to have it created at ./configure time. > > This should suffice: > #define APR_INO_T_FMT APR_UINT64_T_FMT Nope - this would be bad where ino_t is 32 bits and the user doesn't explicitly cast it up. Either a configure detected value, or suggest they use "ino is " APR_UINT64_T_FMT ", so there", (apr_uint64_t)f->ino);