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. Re: Supporting statvfs64 on 32-bit architectures, and long
long? (Russ Allbery)
2. Re: Supporting statvfs64 on 32-bit architectures, and long
long? (Richard Kettlewell)
3. Re: Supporting statvfs64 on 32-bit architectures, and long
long? (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Jan 2024 09:01:02 -0800
From: Russ Allbery <[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
Richard Kettlewell <[email protected]> writes:
> 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.
We made it default to off for backward compatibility because it
invalidates most of the existing data files when you change it. We
probably should make it default to on at some point, but it's a major
version sort of thing.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Mon, 22 Jan 2024 17:04:51 +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 22/01/2024 17:01, Russ Allbery wrote:
> Richard Kettlewell <[email protected]> writes:
>> 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.
>
> We made it default to off for backward compatibility because it
> invalidates most of the existing data files when you change it. We
> probably should make it default to on at some point, but it's a major
> version sort of thing.
Makes sense!
ttfn/rjk
------------------------------
Message: 3
Date: Mon, 22 Jan 2024 21:02:37 +0100
From: Julien ?LIE <[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
Hi Richard,
>> 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.
Oh, you're totally right. I thought it was enabled by default, and did not
check that. The Debian package made it the default years ago (there once was
an inn2-lfs package, now inn2) and I was somehow persuaded that it was the same
in the stock upstream package.
And indeed, configuring the package with --enable-largefiles fixed the
computation of free disk space.
... but not the computation of free inodes!
Incidentally, there was a comment in the code saying that "the free space in
bytes would overflow an unsigned long. This should be safe until file systems
larger than 4TB (which may not be much longer -- we should use long long
instead if we have it)." :-)
So I switched the code to use long long when HAVE_LONG_LONG_INT is set by
Autoconf, and inndf now works fine!
>> 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!
Fair enough.
Thanks for your comment. Let's put our energy in other work than that
(except maybe for the time_t migration).
--
Julien ?LIE
??Petite annonce?: Artificier cherche femme canon.??
------------------------------
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 16
********************************************
