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: svn commit: r589583 - /apr/apr/trunk/configure.in
Date Mon, 29 Oct 2007 19:48:57 GMT
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!

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).


View raw message