From dev-return-19123-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Oct 12 15:44:48 2007 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 14703 invoked from network); 12 Oct 2007 15:44:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Oct 2007 15:44:46 -0000 Received: (qmail 71178 invoked by uid 500); 12 Oct 2007 15:44:33 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 71127 invoked by uid 500); 12 Oct 2007 15:44:33 -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 71116 invoked by uid 99); 12 Oct 2007 15:44:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2007 08:44:33 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lucian.grijincu@gmail.com designates 66.249.82.233 as permitted sender) Received: from [66.249.82.233] (HELO wx-out-0506.google.com) (66.249.82.233) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2007 15:44:36 +0000 Received: by wx-out-0506.google.com with SMTP id h26so765668wxd for ; Fri, 12 Oct 2007 08:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ugAnujNPFnUL2BGsWi36UGz46IHtPCIZuQ54L/mVs5Y=; b=VvCNi9CWkn2eXC1Yazoj03GMUAcEFao3O/ZcfPsLtGQurG4/y5pJNOPsmxlslQRVzrscfOz5kHAIy+rysLN7QPMJt3d6CgLBrg0H4ZwtHL5BfLrcYD7VtYexVEnaC/ZP5IHzTr/klHJyDGrBmbXnGL753YBPSOtdzqJ96kMaja8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mgIuBFGcBHFPYT1uQXyUljDaFzx2DKLjr/S5aTgy/m1lxUm2aGPghrZ1urOY0MS17Dz6X9/YwvEi57dyjDIfZwTNdABvGj141PrxuoVKVCqEXBPT9a8e89SAe+4JQTL023zew4SfWTqpnVG6X9AAVAuHhUu7rs/y6C100tKJQDo= Received: by 10.90.51.17 with SMTP id y17mr5012168agy.1192203855065; Fri, 12 Oct 2007 08:44:15 -0700 (PDT) Received: by 10.90.63.7 with HTTP; Fri, 12 Oct 2007 08:44:15 -0700 (PDT) Message-ID: Date: Fri, 12 Oct 2007 18:44:15 +0300 From: "Lucian Adrian Grijincu" To: dev@apr.apache.org Subject: Re: Tagging 1.2.* Sat night or Sun a.m. Cc: "Joe Orton" In-Reply-To: <20071012150633.GA7324@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <470DD429.90908@rowe-clan.net> <470E3DD5.3060204@rowe-clan.net> <20071012150633.GA7324@redhat.com> X-Virus-Checked: Checked by ClamAV on apache.org On 10/12/07, Joe Orton wrote: > On Thu, Oct 11, 2007 at 10:14:29AM -0500, William Rowe wrote: > > Lucian Adrian Grijincu wrote: > > > > > >Do my patches against configure.in, apr.hnw and apr.hw fixing the > > >apr_ino_t ( http://issues.apache.org/bugzilla/show_bug.cgi?id=43417 ) > > >issue have a chance of getting accepted (aka should I try to test them > > >on other configurations to see whether they break something on some > > >systems)? > > > > Not according to folks interpretation of our versioning policy, it seems > > this patch must wait for 2.0.0. You would be breaking ABI for anyone > > building against a 32 bit APR build. > > Lucian's patches do not change the ABI of the library which is built (at > least by design, unless you are talking about some problem with the > implementation which I'm missing). > > In the case where APR is built *without* _FILE_OFFSET_BITS=64, and an > external application includes APR headers *with* _FILE_OFFSET_BITS=64 > defined, an APR library ABI would be used by the application which does > not match the real ABI, and all bets were off. Lucian's patch fixes > that. > > Exposing apr_ino_t from apr.h rather than only from apr_file_info.h is > certainly an API extension and so cannot be done in 1.2.x. > Would something like this work? after the last line in apr.h which is the end of the header-protection macros: #endif /* APR_H */ we insert the next lines: #ifdef APR_FILE_INFO_H //aka we are included from apr_file_info.h #ifndef APR_FILE_INFO_H__APR_H_or_whatever_name_you_find_suitable #define APR_FILE_INFO_H__APR_H_or_whatever_name_you_find_suitable typedef apr_sometype_t apr_ino_t; #endif //APR_FILE_INFO_H__APR_H_or_whatever_name_you_find_suitable #endif //APR_FILE_INFO_H This would prevent apr_ino_t from being exposed from apr.h. It's exposed only when apr_file_info.h was included beforehand. It doesn't matter if apr.h is included before apr_file_info.h. The file is reparsed and because this code is outside apr.h's protection macros the typedef makes it to the compilation stage. -- Lucian.