On 10/12/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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. http://apr.apache.org/docs/apr/1.2/structapr__finfo__t.html 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; #else val = finfo.fname; #endif I'm suggesting having ino_t maintain it's current size*, but typedef it to something that is immutable with respect to _FILEOFFSET_BITS' value. * 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 _FILEOFFSET_BITS=64. 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: http://mail-archives.apache.org/mod_mbox/apr-dev/200709.mbox/[EMAIL PROTECTED] -- Lucian.
