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 17:55:50 GMT
On 10/12/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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

Mime
View raw message