bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: recommending AC_SYS_YEAR2038_REQUIRED ?


From: Zack Weinberg
Subject: Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Date: Mon, 10 Apr 2023 15:09:10 -0400
User-agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6

On Mon, Apr 10, 2023, at 10:12 AM, Pádraig Brady wrote:
> On 10/04/2023 14:40, Bruno Haible wrote:
>> Hi Paul, In yesterday's changes, you added to the Gnulib
>> documentation, section "Avoiding the year 2038 problem", wording that
>>
>>    * explicitly recommends the ‘year2038-required’ module, which does
>>      AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]):
...
>> I strongly object to this recommendation and presentation.
...
>> It is simply the wrong person's decision if the package maintainer
>> uses the AC_SYS_YEAR2038_REQUIRED macro.
...
>> When AC_SYS_YEAR2038_REQUIRED is used, the package can no longer be
>> installed on the following 32-bit platforms/ABIs:
...
>> I would therefore propose that the module 'year2038-required' gets
>> removed from Gnulib, as I cannot see any positive uses of it.

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.

zw



reply via email to

[Prev in Thread] Current Thread [Next in Thread]