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

Julien ÉLIE <[email protected]> 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 ([email protected])             <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.
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers