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: svn commit: r589583 - /apr/apr/trunk/configure.in
Date Mon, 29 Oct 2007 20:43:47 GMT
On 10/29/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Joe Orton wrote:
> >
> > No, unless you know of a platform where ino_t is defined to be anything
> > other than a 32-bit unsigned long *and* varies by _FILE_OFFSET_BITS?
> > Otherwise configure is just testing for hypothetical platforms, which is
> > a waste of cycles.
>
> You missed my point.  Take RandomOS Version 6.0 - build APR, no variant for
> _FILE_OFFSET_BITS, it's equivilant to unsigned int.
>
> Now run an upgrade to RandomOS V7.0, voila, it picks up long off_t semantics
> and 32 more ino_t bits, whoopie!
>

this is the default, so if the next check fails, there can be no ABI
change if there is no variant for _FILE_OFFSET_BITS.
+ino_t_value=ino_t

> Compile an app against the previously installed apr and poof, bang, dead.
>
> Yes, it takes a few extra cycles, but can we /please/ continue to validate
> against unsigned int as well as unsigned long for the sanity of the poor
> users sitting on this edge case?  If you wanted to start excluding such
> things, there's a much longer list of tests that need serious surgery or
> outright purging (db detection tops that list).
>


If I understand this correctly:
ino_t can have only two sizes that depend on _FILE_OFFSET_BITS: 32 and 64.

ALL references I could find on LFS talk about an increase from 32 to 64 bits.

Other operating systems may have > 64 bit (I've never heard of one,
but who knows, "2 ^ 64 = 18446744073709551616 files should be enough
for everyone" - you can quote me on that one :) but these ones don't
need LFS, thus no need to replace ino_t with anything else, it won't
change with _FILE_OFFSET_BITS (of course, I base this on nothing
because I've never seen such a system).

I don't know if a 16 bit one exists (65536 files / dirs seems kind of
lowish), this case  might use a _FILE_OFFSET_BITS=XY. If such a
platform exists AND uses LFS, then YES, we should check for unsigned
short too and add it to Makefile.in.

The last two cases that remain are 32bit and 64bit:
a) 32 bit. ino_t might change with _FILE_OFFSET_BITS and should be
nailed to an unsigned 32 bit wide integer.


+if test "$ac_cv_sizeof_long" = "4"; then
+    APR_CHECK_TYPES_COMPATIBLE(ino_t, unsigned long,
+                               ino_t_value="unsigned long")
+fi
+AC_MSG_NOTICE([using $ino_t_value for ino_t])

This will fix ino_t to unsigned long if unsigned long is 4 bytes wide,
but will leave it as ino_t if long is more than that (and I see no
reason why long cannot be 8 bytes and while int would be 4 bytes).

I think this satisfies sufficiency:


if test "$ac_cv_sizeof_long" = "4"; then
    APR_CHECK_TYPES_COMPATIBLE(ino_t, unsigned long,
                               ino_t_value="unsigned long")
fi
if test "$ac_cv_sizeof_int" = "4"; then
    APR_CHECK_TYPES_COMPATIBLE(ino_t, unsigned int,
                               ino_t_value="unsigned long")
fi
AC_MSG_NOTICE([using $ino_t_value for ino_t])


Once again, the check for *int* is NECESSARY only on platforms that
are affected by LFS and on which sizeof(long)>sizeof(int). If no such
platform exists Joe's original patch is sufficient.

b) 64 bit wide ino_t. I don't know of a LFS which changes from 64 bit
ino_t to something more. So the default fallback "ino_t_value=ino_t"
is enough.



-- 
Lucian

Mime
View raw message