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 Tue, 23 Oct 2007 22:35:54 GMT
On 10/24/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Lucian Adrian Grijincu wrote:
> >
> > Oh, yeah, you're right, there's no need to have it created at ./configure time.
> >
> > This should suffice:
> > #define APR_INO_T_FMT APR_UINT64_T_FMT
>

Damn versioning rules. I mixed up 1.3 and 2.0
I proposed (earlier in this thread) that for APR 2.0 apr_ino_t be
fixed as apr_uint64_t on all platforms so there would be less fuss
about handling it.

Yeah, for display purposes upcasting to APR_UINT64_T_FMT is sufficient.

"[XSI] [Option Start] fsblkcnt_t, fsfilcnt_t, [Option End]  and ino_t
shall be defined as unsigned integer types."
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html

If all platforms use unsigned interger types for ino_t (aka they
respect the standard) this is a correct approach.

Sorry for the mixup.

--
Lucian

> Nope - this would be bad where ino_t is 32 bits and the user doesn't explicitly
> cast it up.  Either a configure detected value, or suggest they use
>
>    "ino is " APR_UINT64_T_FMT ", so there", (apr_uint64_t)f->ino);
>
>

Mime
View raw message