Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <470FAECA.5070103@rowe-clan.net>
Date: Fri, 12 Oct 2007 12:28:42 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
CC: dev@apr.apache.org, Joe Orton <jorton@redhat.com>
Subject: Re: Tagging 1.2.* Sat night or Sun a.m.
References: <470DD429.90908@rowe-clan.net>
	 <acf3f2e60710110335g1c9cc9c6g21f6e0dd9b0ab310@mail.gmail.com>
	 <470E3DD5.3060204@rowe-clan.net> <20071012150633.GA7324@redhat.com>
 <acf3f2e60710120844p4241a1d2l128d1447229fe620@mail.gmail.com>
In-Reply-To: <acf3f2e60710120844p4241a1d2l128d1447229fe620@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Lucian Adrian Grijincu wrote:
> On 10/12/07, Joe Orton <jorton@redhat.com> 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).

Gotcha, then we'll be able to fix to make this consistent.

>> 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.

Right - and this is all the worse because it's not opaque, and the user
is allocating the space for the structure that apr fills in.  Yuck.

>> 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.

Exactly, we need to use an existing apr_foo_t to accomplish the same thing
until 1.3.0

> 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

Nope - it's still in the public namespace if they include apr_file_info.h.

WORSE you just f***ed up the user who chose a different order for their
includes, which sucks to be them.  Please don't do such nonsense to them.

Bill