Autoconf 2.72 Released With C23 Support, New Year 2038 Safety Option

[phoronix]

Phoronix: Autoconf 2.72 Released With C23 Support, New Year 2038 Safety Option

For those still relying on GNU Autoconf for generating configure scripts for building/installing/packaging software rather than more modern alternatives like CMake and Meson, Autoconf 2.72 is out today as a nice holiday treat...

https://www.phoronix.com/news/Autoconf-2.72-Released

[tildearrow]

a new "--enable-year2038" option

Why isn't this default on 32-bit systems? The C standard dictates that time_t is an undefined type.
I guess developers assume it's an int...

[cend]

No mentions of Fedora's modern C initiative. Wondering if the legacy C has been fixed.

Why isn't this default on 32-bit systems? The C standard dictates that time_t is an undefined type.
I guess developers assume it's an int...

time_t is a value type (i.e. not pointer), so switching from 32-bit time_t to 64-bit time_t breaks ABI: A 32-bit value takes one 32-bit register or one 4-byte stack block, depending on call convention, on a 32-bit arch, but a 64-bit value takes two registers or two 4-byte blocks on the same arch.

Before the 2038 problem become very urgent, 32-bit time_t looked at glance faster and thus more sensible for a 32-bit C ABI.

[nanonyme]

No mentions of Fedora's modern C initiative. Wondering if the legacy C has been fixed.



time_t is a value type (i.e. not pointer), so switching from 32-bit time_t to 64-bit time_t breaks ABI: A 32-bit value takes one 32-bit register or one 4-byte stack block, depending on call convention, on a 32-bit arch, but a 64-bit value takes two registers or two 4-byte blocks on the same arch.

Before the 2038 problem become very urgent, 32-bit time_t looked at glance faster and thus more sensible for a 32-bit C ABI.

Right. This isn't necessarily super-harmful for opensource software where you can simply rebuild everything to have 64-bit time_t but it's extremely dangerous for proprietary software.

[Chewi]

Yeah, the time_t thing is a big deal and needs to be carefully stage-managed by distributions. Gnulib unilaterally started enabling 64-bit time_t a while ago without realising the chaos that would ensue. I suddenly found that wget on my ARM board was failing every HTTPS connections because the certificate dates were all out of whack.

[Setif]

The question is: Will 32-bit systems make it to 2038?
I don't think so.

[mathletic]

From the change log:

We feel that support
for compilers that support only C 2024 is more useful, nowadays,
than support for compilers that don't implement a core feature of
C 1989.

I am happy the authors of Automake feel this way! Hopefully this drop of checks will save millions of CPU cycles on useless checks for ancient systems. Thanks for the release!

[Chewi]

The question is: Will 32-bit systems make it to 2038?
I don't think so.

I just had the capacitors in my Amiga 1200 replaced with long-lasting one. It'll live forever!

[stormcrow]

The question is: Will 32-bit systems make it to 2038?
I don't think so.

Yes they will, just like 8 & 16 bit microcontrollers and CPUs are still a thing. Size of the data/command word has little to do with whether a device is useful or not, but it can have a lot to do with cost and power budgets even if it's not a retro computing thing.

The reason 2038 is even an issue is because engineers figured we'd have something better than the UNIX epoch for time keeping by now (and Unix in general) without realizing in 1969 that de facto standards have a staying power all of their own. There's nothing inherently special about second 0 of the Unix epoch, after all. It could theoretically be mapped to any particular moment in time so long as it was the same for all machines in an organization (granted that could cause issues outside of that organization without a conversion function).

[reavertm]

Whoever designed entire autotools related ecosystem should burn in hell.
And whoever intentionally uses it in new project is retarded. There I said it