On 10/12/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Joe Orton wrote: > > Here's an updated patch: > > > > Index: configure.in > > =================================================================== > > --- configure.in (revision 583792) > > +++ configure.in (working copy) > > @@ -1456,6 +1456,21 @@ > > fi > > AC_MSG_RESULT($off_t_value) > > > > +# Regardless of whether _LARGEFILE64_SOURCE is used, on 32-bit > > +# platforms _FILE_OFFSET_BITS will affect the size of ino_t and hence > > +# the build-time ABI may be different from the apparent ABI when using > > +# APR with another package which *does* define _FILE_OFFSET_BITS. > > +# (Exactly as per the case above with off_t where LFS is *not* used) > > +# > > +# To be safe, hard-code apr_ino_t as 'unsigned long' iff that is > > +# exactly the size of ino_t here; otherwise use ino_t as existing > > +# releases did. To be correct, apr_ino_t should have been made an > > +# ino64_t as apr_off_t is off64_t, but this can't be done now without > > +# breaking ABI. > > +ino_t_value=ino_t > > +APR_CHECK_TYPES_COMPATIBLE(ino_t, unsigned long, ino_t_value="unsigned > > long") > > +AC_MSG_NOTICE([using $ino_t_value for ino_t]) > > is it too early to actually compare ino_t to apr_uint64_t at this phase? > In theory there will be embedded 32 bit int+long cases we should consider. > > > Index: include/apr.hw > > =================================================================== > > --- include/apr.hw (revision 583792) > > +++ include/apr.hw (working copy) > > @@ -346,6 +346,8 @@ > > #endif > > typedef int apr_socklen_t; > > > > +typedef apr_uint64_t apr_ino_t; > > + > > I'm 99% certain that on win32 ino_t was always 32 bits, but I'm off > to validate that assumption. >
quote from http://svn.apache.org/viewvc/apr/apr/branches/1.2.x/include/apr_file_info.h?view=markup #if (defined WIN32) || (defined NETWARE) /** * Structure for determining the inode of the file. */ typedef apr_uint64_t apr_ino_t; /** * Structure for determining the device the file is on. */ typedef apr_uint32_t apr_dev_t; #else /** The inode of the file. */ typedef ino_t apr_ino_t; /** * Structure for determining the device the file is on. */ typedef dev_t apr_dev_t; #endif that looks like unsigned 64 bit wide interger to me. > Until 2.0 we obviously can't change the number of bits in apr_ino_t, period. > > Of course, no one was asking for such a change. We're preserving the size that was present in APR until now, but we're making it not depend on other flags. The width apr_ino_t had when libapr was compiled should be the same width it has when it's being used in other projects. We're just trying to enforce this by typedefing apr_ino_t to a type that is immutable with respect to the value of _FILEOFFSET_BITS' value. And yeah, it seems reasonable that in 2.0 apr_ino_t==apr_uint64_t. -- Lucian
