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

[Russ Allbery]

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

> Using long long seems to be more complicated as it is not available
> everywhere.

I'm not sure if this is really true any more, although Autoconf doesn't
provide much in the way of guidance.  But I would be surprised if one
encountered a system without long long these days.  I think one would have
to be compiling with a proprietary UNIX compiler from some old commercial
UNIX.

> Some people might also use "-m32" for their builds, and indeed on ARM
> Linux systems, long is 32-bit.  %lu will work until 2106 for them.
> atol(), strtol() and like should then also be changed to atoul() and
> strtoul().

> Would these changes be OK to do right now or should we wait a bit, for
> possible other wide-spread best practices to deal with the 2038 bug?

I think changing to use %lu for time_t is completely harmless and there's
no reason not to do it.  (We don't use negative times to represent times
before the start of epoch, and I can't imagine a situation where that
would be meaningful for a Usenet news server, given that Usenet didn't
exist until well after the start of epoch.)  The only possible problem I
can think of is if we have a -1 time_t somewhere, but that would probably
already be a bug and I'm not sure this would make it any worse.

-- 
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.