Lucian Adrian Grijincu wrote:
On 10/12/07, Joe Orton <[EMAIL PROTECTED]> 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
