apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: Tagging 1.2.* Sat night or Sun a.m.
Date Fri, 12 Oct 2007 15:44:15 GMT
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).
>
> 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.

Mime
View raw message