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 22:31:13 GMT
On 10/12/07, Lucian Adrian Grijincu <lucian.grijincu@gmail.com> wrote:
> On 10/12/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> > William A. Rowe, Jr. wrote:
> > >
> > > 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.
> >
> > Belay that assessment, I see you snuck this in after the header protect
> > macro ;-)
> >
> > It's still not acceptable to add apr_ino_t until 1.3.0 no matter how it's
> > hidden.
> >
>
> It's not added. it's present in apr_file_info.h since 1.2.0
>

here's the proof:

http://svn.apache.org/viewvc/apr/apr/tags/1.2.0/include/apr_file_info.h?view=markup

(with some simplification) this is the code that introduces the
apr_ino_t type in 1.2.0:

#if (defined WIN32) || (defined NETWARE)
     typedef apr_uint64_t              apr_ino_t;
#else
    typedef ino_t                     apr_ino_t;
#endif

> > I had gone so far as to offer no outward facing explanation of the 1.3.0
> > solution to win32 handles, but they could pass a constant which would
> > achieve the effect.  That too was vetoed, so we simply won't add a new
> > interface no matter how cloaked it is :)
> >

(if I'm interpreting correctly the versioning rules) I agree that the veto:
If I code an application that uses APR I know that whichever patch
version in a minor release I use, I'll be able to build my application
(that is, if I only use the APR exposed API and don't mingle with
internal implementation specific stuff). That is, if I code, build and
test against 1.2.13 I know I will be able to build it if I use 1.2.0,
1.2.1, ... 1.2.12, or any version that is released after 1.2.13.
If 1.2.13 adds a new macro identifier and I use it in my code, I will
break source compatibility with earlier patch versions from the 1.2
minor release: I won't be able to compile.


We don't add a new type! apr_ino_t is present in apr_file_info.h since
1.2.0 (I haven't checked exactly which version introduces the type, if
you want me to, I'll look it up).

What I did is replace the
    typedef ino_t                     apr_ino_t;
with a _FILEOFFSET_BITS ignorant
    typedef sometype_t          apr_ino_t;

sometype_t needs to be determined at ./configure time. It depends on
the platform and the flags with which APR is built.

If the type is to be determined at ./configure time, it must be
defined in apr.h.

If we provide the type in apr.h we'll break the rules, because some
developer will forget to include apr_file_info.h somewhere in his
project and use apr_ino_t.
If because of whichever reason he must use an earlier patch version of
APR his app will break at compile time. BAD!

To prevent such a case I used a bit of preprocessor sorcery: only
define apr_ino_t if apr_file_info.h was already included.

In all prior versions of the 1.2 minor release, if a developer wants
to use apr_ino_t he'll have to #include "apr_file_info.h".

With my changes in place this rule is still enforced. The only way
apr_ino_t will be exposed in a manner incompatible with prior patch
versions is if a developer explicitly defines APR_FILE_INFO_H before
including apr.h.

But that developer can shoot himself in the head for all I care. He's
breaking an (albeit unwritten) rule that one should not mess with
internal library thingies.

So in conclusion:
There is no ABI change for 1.2.x.
There is no new type.
No priorly existing type is exposed in a new manner.
World peace :)


--
Lucian.

Mime
View raw message