apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Tagging 1.2.* Sat night or Sun a.m.
Date Fri, 12 Oct 2007 17:28:42 GMT
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.


View raw message