apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: ABI change when _FILE_OFFSET_BITS=64 due to use of ino_t
Date Fri, 12 Oct 2007 18:12:55 GMT
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!

> 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?

Mime
View raw message