[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: recommending AC_SYS_YEAR2038_REQUIRED ?
From: |
Bruno Haible |
Subject: |
Re: recommending AC_SYS_YEAR2038_REQUIRED ? |
Date: |
Mon, 10 Apr 2023 21:45:05 +0200 |
Zack Weinberg wrote:
> As the person who invented AC_SYS_YEAR2038_REQUIRED and
> AC_SYS_LARGEFILE_REQUIRED, let me say that it was my intention that they
> would only be used in rare circumstances, where the inability to install
> the software on older ABIs is outweighed by some other strong
> requirement for time_t and/or off_t to be at least 64 bits. I didn't
> have any specific use cases in mind but I was imagining something to do
> with library ABIs involving time_t, or network and/or storage formats
> explicitly specified to use 64-bit counts of seconds since the Unix
> epoch, or similar.
Thanks for the clarification.
Note that I'm perfectly fine with AC_SYS_LARGEFILE_REQUIRED being
documented, because
- it makes perfect sense for packages that regularly deal with files
larger than 2 GiB, such as video manipulation,
- hardly any platform nowadays lacks a way to enforce large files in
the API.
Bruno
- recommending AC_SYS_YEAR2038_REQUIRED ?, Bruno Haible, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Pádraig Brady, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Zack Weinberg, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Bruno Haible, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Paul Eggert, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Bruno Haible, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Paul Eggert, 2023/04/10
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Zack Weinberg, 2023/04/11
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Paul Eggert, 2023/04/19
- Re: recommending AC_SYS_YEAR2038_REQUIRED ?, Zack Weinberg, 2023/04/19