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

[Julien ÉLIE]

Hi Russ,

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

Using unsigned long allows to reach epoch 2^32 in 2106, so maybe we 
should just fix the %ld format to use %lu instead.

Using long long seems to be more complicated as it is not available 
everywhere.  Checking HAVE_UNSIGNED_LONG_LONG_INT and changing all 
printf() calls to use %lu or %llu looks tedious and decreases code 
readability.  Unless that's not the right approach?


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

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?

-- 
Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)