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: ABI change when _FILE_OFFSET_BITS=64 due to use of ino_t
Date Fri, 12 Oct 2007 18:42:35 GMT
On 10/12/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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

Mime
View raw message