Fwd: 64-bit time_t transition for 32-bit archs: a proposal
Russ Allbery
eagle at eyrie.org
Fri Aug 4 19:48:35 UTC 2023
Julien ÉLIE <julien at trigofacile.com> writes:
> 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);
Yes.
> * 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);
Yes.
> * 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.
Yes. Those all look great. Thank you for looking at this!
--
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.
More information about the inn-workers
mailing list