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