Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal (Julien ?LIE)
2. Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Fri, 4 Aug 2023 21:19:40 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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.??
------------------------------
Message: 2
Date: Fri, 04 Aug 2023 12:48:35 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 152, Issue 1
*******************************************
