Supporting statvfs64 on 32-bit architectures, and long long?

[Julien ÉLIE]

Hi all,

I've came across an issue with inndf returning 0 on an i686 
architecture.  After investigation, statvfs() fails with an EOVERFLOW 
error.  Switching to statvfs64() fixes the problem:

$ inndf .
2720461568


Digging a bit about statvfs64(), it seems that adding 
-D_FILE_OFFSET_BITS=64 at build time is enough to use it, and I confirm 
it does the trick without changing the code.

Yet, the Autoconf macro AC_SYS_LARGEFILE is used, and does not set that 
flag.  I would have expected it to.
Is someone aware of a particular trick to enable these 64-bit functions 
on 32-bit architectures?


I bet other functions like lseek(), fstat(), getrlimit(), mmap(), 
pread(), pwrite(), etc.  used by INN may suffer from a similar lack of 
support for their 64-bit equivalent...



Also, there's another deeper problem about "long" and "long long".  The 
result of "inndf -i" is wrong because it is stored in a variable of type 
long, and printed with "%lu".  If changed to "long long" and "%llu", it 
gives the expected result:

$ inndf -i .
5440922880


... but I cannot audit the entire code of INN to check where "long" 
should be changed to "long long"...


So I am a bit puzzled about how to support 32-bit architectures 
nowadays, as just adding -D_FILE_OFFSET_BITS=64 fixes some things, but 
not everything...  In lack of a complete audit of the source code for a 
proper fix, isn't INN to be considered broken or "use at your own risk" 
on current 32-bit architectures?  (but I do not know to what extent it 
does not work)

-- 
Julien ÉLIE

« La grandeur d'un métier, c'est peut-être avant tout d'unir les
   hommes. » (Saint-Exupéry)