Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Supporting statvfs64 on 32-bit architectures, and long long?
(Julien ?LIE)
2. Re: Supporting statvfs64 on 32-bit architectures, and long
long? (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Jan 2024 23:47:16 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Supporting statvfs64 on 32-bit architectures, and long long?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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)
------------------------------
Message: 2
Date: Mon, 22 Jan 2024 08:42:34 +0000
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Supporting statvfs64 on 32-bit architectures, and long
long?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 21/01/2024 22:47, Julien ?LIE wrote:
> 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?
Did you use ./configure --enable-largefiles? It defaults to no for some
reason.
> 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)
32-bit x86 has increasingly poor support in Linux. Arm is still getting
attention (Debian is trying to do a time_t 32->64 migration on 32-bit
Arm platforms) but personally I think 32-bit server platforms are
starting to look like retrocomputing now.
Even the embedded platforms I use in my day job are 64-bit now!
ttfn/rjk
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 157, Issue 15
********************************************
