[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On time64 and Large File Support
From: |
Sam James |
Subject: |
Re: On time64 and Large File Support |
Date: |
Fri, 11 Nov 2022 09:19:31 +0000 |
> On 11 Nov 2022, at 09:16, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 2022-11-11 00:38, Sam James wrote:
>> All that to say, I don't propose making these options unconditional,
>> because I think the boat has sailed as of glibc-2.34 [4], and I think
>> it's fair that autoconf keep the behaviour as described in git master
>> right now given the situation with glibc, but I don't think it's
>> a wise path for most distributions to follow.
> As a practical matter, I expect that each distro will have to do a big-bang
> move, assuming the distro want to support traditional 32-bit platforms at
> all. It makes little sense to try to have some programs and libraries with
> 32-bit time_t, while others have 64-bit time_t. Just switch to 64-bit time_t
> everywhere.
>
> This is not something distros can put off for long. We're only 15 years from
> when 32-bit time_t stops working. If distros plan to to support traditional
> 32-bit platforms, they really need to do the big-bang move soon. They can do
> it by predefining _TIME_BITS=64 and _FILE_OFFSET_BITS=64, or by using the new
> Autoconf macros, or whatever.
>
> One possible way forward would be for glibc to change its defaults for
> _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This
> would make it easier to do a big-bang switch, which is what people need to do
> anyway. The backward-compatibility argument for defaulting these to 32 is
> making less and less sense as time goes on.
+1.
I completely agree and I've reached the same conclusion. My suggestion for
configure args
was to be a bit more gentle and avoid controversy, but really, your suggestion
would work and would
force distros to handle it at the same time, which is best for users.
(And I really did try to make piecemeal work, but I've decided it can't.)
I think we're at risk of distros either putting this off or equivocating which
just harms our users. I should've spoken up at the time of 2.34.
FWIW, musl did this and it really was for the best:
https://musl.libc.org/time64.html.
signature.asc
Description: Message signed with OpenPGP
- On time64 and Large File Support, Sam James, 2022/11/11
- Re: On time64 and Large File Support, Paul Eggert, 2022/11/11
- Re: On time64 and Large File Support, Florian Weimer, 2022/11/11
- Re: On time64 and Large File Support, Sam James, 2022/11/11
- Re: On time64 and Large File Support, Zack Weinberg, 2022/11/11
- Re: On time64 and Large File Support, Sam James, 2022/11/11
- Re: On time64 and Large File Support, Zack Weinberg, 2022/11/12
- Re: On time64 and Large File Support, Paul Eggert, 2022/11/12
- Re: On time64 and Large File Support, Bruno Haible, 2022/11/12