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

[Julien ÉLIE]

Hi all,

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

I've begun to audit the use of time_t variables and time().  I've 
already proof-read a quarter of these.


Do you agree that the changes to make look like the following ones:

* Using unsigned long in printf()-like calls:

[convdate]
     time_t date;
-   warn("can't format %ld", (long) date);
+   warn("can't format %lu", (unsigned long) date);



* Using atoll() instead of atol() when converting strings to time_t:

[makehistory parsing the timestamps in the history file]
     time_t arrived, expires;
-   arrived = (time_t) atol(p);
-   expires = (time_t) atol(q);
+   arrived = (time_t) atoll(p);
+   expires = (time_t) atoll(q);



* Using strtoul() instead of strtol() when converting strings to time_t:

[contrib/expirectl.c]
+++ b/contrib/expirectl.c
     time_t expireIncTime;
-   expireIncTime = strtol(buf + 4, NULL, 0);
+   expireIncTime = strtoul(buf + 4, NULL, 0);

unsigned long normally fits in time_t (in both 32 and 64-bit platforms), 
so adding an explicit cast to time_t does not look necessary to me.



I've still not seen any other kind of changes to do (apart from the 
timecaf and timehash parsing issue we already spoke about).

-- 
Julien ÉLIE

« Lupus est matrem suum. »