On 10/12/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Lucian Adrian Grijincu wrote: > >> 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; > > > > that looks like unsigned 64 bit wide interger to me. > > My bad, you are obviously correct! Shame on me for not looking at the > code before opening my mouth :) > > >> 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. > > s/./ present at the client application's build time./ > > yup!
yep, sorry for not making myself more explicit. > > > 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. > > Got it :) > > > And yeah, it seems reasonable that in 2.0 apr_ino_t==apr_uint64_t. > > You mean 1.2? > Nope. I think that in 2.0, to avoid any hassle apr_ino_t should have a fixed size equal to the maximum used on all platforms. The two sizes that are used (to my knowledge) are 4 and 8 bytes, thus apr_ino_t==apr_uint64_t. But that's just the way I'd set things up, a vote should run to decide this things. -- Lucian
