Fwd: 64-bit time_t transition for 32-bit archs: a proposal

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> Aren't there caveats with printf()-like calls or atol()-like calls?

> We often have casts of time_t variables to "%lu" or "%ld" in printf(). Do
> they work fine on both 32-bit and 64-bit architectures with a 64-bit
> time_t after 2038?
> Example in innd/site.c:
>   snprintf(pbuff, sizeof(pbuff), "%ld", (long) Data->Arrived);

> In expire/makehistory.c, we have:
>   arrived = (time_t) atol(p);
> Wouldn't atoll(p) be needed in some cases?

> (We're also reading the epoch times in active.times with an atol() call in
> nnrpd/commands.c.)

Yes, I think you're right; those need to become long long (although
unsigned long buys another decade or so).

It's not yet clear whether Debian will try to convert the i386
architecture to 64-bit time_t, drop it, or do something else with it.
There's a large debate right now in the Linux world over whether i386 is
more useful as a legacy build to run old software (which will never be
able to use 64-bit time_t), or as a platform for running current software.
It's fairly hard to find new 32-bit-only x86 processors these days, and
even the large numbers of legacy systems out there are getting pretty old.

But this will come up for other architectures even if i386 doesn't convert
(ARM, for instance, and there's probably at least one person out there
running INN on an ARM Linux system).

-- 
Russ Allbery (eagle at eyrie.org)             <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.