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

[Julien ÉLIE]

Hi Russ,

> Forwarding this discussion from debian-devel about 64-bit time_t migration
> to inn-workers since this is a better place to discuss the details.

Thanks for the forward!

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, timecaf does have a problem, two actually.
[...]> 2. The CF files use file names like timecaf-nn/bb/aacc.CF where nn is
> the storage class and aabbccxx the time of arrival, changing the file
> name in 256-second intervals. The code using %02x format strings to
> determine the file name, and everything else checking them for
> validity, will have to be changed appropriately.

The storage tokens in history should also be changed accordingly.
They contain the same "aabbcc":
@04nn00aabbccyyyyxxxx0000000000000000@

Same thing for timehash:
@02nnaabbccddyyyy00000000000000000000@
"aabbccdd" is the arrival time in hexadecimal, and "yyyy" a sequence number.

Hopefully we have zeroes to re-use in the token for the larger arrival 
time size, and an history rebuild will do the job.

-- 
Julien ÉLIE

« Ce qu'on est arrivé à faire avec le téléphone sans fil, va-t-on le
   réussir un jour avec les haricots ? » (Philip Geluck)