Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 18641 invoked from network); 29 Oct 2007 19:33:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Oct 2007 19:33:08 -0000 Received: (qmail 65925 invoked by uid 500); 29 Oct 2007 19:32:55 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 65879 invoked by uid 500); 29 Oct 2007 19:32:55 -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 65868 invoked by uid 99); 29 Oct 2007 19:32:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 12:32:55 -0700 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates 66.187.233.31 as permitted sender) Received: from [66.187.233.31] (HELO mx1.redhat.com) (66.187.233.31) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 19:33:09 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id l9TJWaaI026013 for ; Mon, 29 Oct 2007 15:32:36 -0400 Received: from turnip.manyfish.co.uk (IDENT:U2FsdGVkX19XzSJHwd4lZNsWsF2KdaRsuzjkUPFLFWo@vpn-15-168.rdu.redhat.com [10.11.15.168]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9TJWZSu015905 for ; Mon, 29 Oct 2007 15:32:35 -0400 Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.66) (envelope-from ) id 1ImaLi-0001NP-V3 for dev@apr.apache.org; Mon, 29 Oct 2007 19:32:34 +0000 Date: Mon, 29 Oct 2007 19:32:34 +0000 From: Joe Orton To: dev@apr.apache.org Subject: Re: svn commit: r589583 - /apr/apr/trunk/configure.in Message-ID: <20071029193234.GA5096@redhat.com> Mail-Followup-To: dev@apr.apache.org References: <20071029111903.9CD171A9832@eris.apache.org> <47262C60.9080007@rowe-clan.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <47262C60.9080007@rowe-clan.net> User-Agent: Mutt/1.5.14 (2007-02-12) Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Oct 29, 2007 at 01:54:24PM -0500, William Rowe wrote: > jorton@apache.org wrote: > >Author: jorton > >Date: Mon Oct 29 04:19:02 2007 > >New Revision: 589583 ... > >+# breaking ABI. > >+ino_t_value=ino_t > >+if test "$ac_cv_sizeof_long" = "4"; then > >+ APR_CHECK_TYPES_COMPATIBLE(ino_t, unsigned long, > >+ ino_t_value="unsigned long") > >+fi > >+AC_MSG_NOTICE([using $ino_t_value for ino_t]) > > This doesn't look right for 32 platforms built without 64 bit off's, and > consider they might initially build on one which doesn't support the newer > types, but then might compile add ins on an updated kernel, eh? I can't parse that. > Shouldn't we continue to lock this /down/ to unsigned int where we know this > is true? In fact, I'd add unsigned short to that list for safety. No, unless you know of a platform where ino_t is defined to be anything other than a 32-bit unsigned long *and* varies by _FILE_OFFSET_BITS? Otherwise configure is just testing for hypothetical platforms, which is a waste of cycles. joe