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 00:07:12 GMT
On 10/12/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> > Actually there's a 0.9.4 to 0.9.5 change that is documented as such
> > (see the CHANGES file):
> >
> >   *) Define apr_off_t as long rather than as off_t on platforms with a
> >      32-bit off_t to prevent incompatibility with packages such as
> >      Perl which redefine the size of off_t via _FILE_OFFSET_BITS on
> >      some platforms.  [Ben Reser <ben reser.org>]
> >
> > So either that change broke the rules (if these rules were applicable
> > back when the change was made) or my proposed changes are compatible
> > with the rules.
> The rules didn't apply to 0.9, and never have.
> 1.0.0 heralded our current versioning restrictions, which if you aren't
> already familiar, can be found here;
> http://apr.apache.org/versioning.html
> DOH - just struck me what's going on here... yes, the eariliest possible
> opportunity to adopt 64 bit ino values is apr 2.0.0

OK, I admit that having sizeof(apr_ino_t)==64 needs to go in 2.0.0
(because it would break any program that uses apr_ino_t which is 32
bit large on all 32 bit systems I've used). I was talking about
something else.

This is a problem I actually ran into and I know another developer did so too.

struct apr_finfo_t
    apr_ino_t 	inode
    const char * 	fname
    const char * 	name

I was wrongfully compiling my binary with _FILEOFFSET_BITS=64 (this
decision was imposed by some not-controlled-by-me factors, but this
could also happen if someone works with a library that depends on
_FILEOFFSET_BITS=64). I was also using the libapr that came with
Ubuntu x86, and that one was compiled with _FILEOFFSET_BITS=32.

The bug: what APR wrote in "name" I read in the "fname" member.
This is because apr thought inode was 4 bytes long and my binary
thought it was 8 bytes long. The 4 byte difference lead to the bug.

This was behaving normal on Windows: what APR wrote in "name" I read in "name".

So I had to do an ifdef to get a "portable" behavior:

#ifdef WINDOWS
   val = finfo.name;
   val = finfo.fname;

I'm suggesting having ino_t maintain it's current size*, but typedef
it to something that is immutable with respect to _FILEOFFSET_BITS'

* current size == the size of ino_t given all the flags and extraflags
used when compiling libapr. If someone built a custom libapr with
_FILEOFFSET_BITS=64, they won't loose ABI compatibility.

My patch only affects people that want to use a system provided libapr
compiled with _FILEOFFSET_BITS=32 while they build their program with

I'm only insisting because I had the idea that you misunderstood me.
If I'm wrong, I'll stop bugging you about this; I don't want to become
"the annoying guy that keeps insisting on stupid things".

Joe Orton agreed that this is a bug of the header files:


View raw message