On 10/12/07, Lucian Adrian Grijincu <[EMAIL PROTECTED]> wrote: > On 10/12/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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.
