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 17:25:10 GMT
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.

Until 2.0 we obviously can't change the number of bits in apr_ino_t, period.


Mime
View raw message