[Asterisk-code-review] time: add support for time64 libcs (asterisk[master])

[Philip Prindeville]

Attention is currently required from: Joshua Colp, George Joseph, Sebastian Kemper.
Philip Prindeville has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/16621 )

Change subject: time: add support for time64 libcs
......................................................................


Patch Set 4:

(7 comments)

Patchset:

PS4: 
I don't want to see this fixed, but I think the unnecessary promotion does more harm than good.


File include/asterisk/time.h:

https://gerrit.asterisk.org/c/asterisk/+/16621/comment/1a9903ad_9104ee3f 
PS4, Line 33: #define TIME_T_CAST(x) ((long long)(x))
I don't like this unnecessary promotion, and indeed on low-end 32-bit embedded CPU's, 64-bit division (such as is required to do base 10 conversion) is expensive.

It's trivial to test the sizeof(time_t) and detect whether we need to use PRId64 or PRId32.


File res/res_calendar_caldav.c:

https://gerrit.asterisk.org/c/asterisk/+/16621/comment/0ad2d926_f1df23d6 
PS4, Line 408: 			snprintf(tmp, sizeof(tmp), "%" TIME_T_FMT, TIME_T_CAST(event->start));
Since TIME_T_FMT can be something conditionally defined, we shouldn't need to cast unconditionally.


File res/res_calendar_icalendar.c:

https://gerrit.asterisk.org/c/asterisk/+/16621/comment/44dab671_62369ee0 
PS4, Line 248: 			char tmp[100];
Maybe I'm missing something, but ULLONG_MAX is 20 digits long, and then one more char for the NUL would be 21.


File res/res_http_media_cache.c:

https://gerrit.asterisk.org/c/asterisk/+/16621/comment/474ac306_6910535a 
PS4, Line 304: 	long long llv;
This isn't necessary.


https://gerrit.asterisk.org/c/asterisk/+/16621/comment/2a6779cc_b673a7be 
PS4, Line 310: 	if (sscanf(metadata->value, "%" TIME_T_FMT, &llv) != 1) {
If we set TIME_T_FMT conditionally to the appropriate format (either PRId32 or PRId64) then we can deposit directly into a time_t.


https://gerrit.asterisk.org/c/asterisk/+/16621/comment/56c21599_e8336faf 
PS4, Line 314: 	expires.tv_sec = llv;
And here we're just creating a potential loss-of-precision error when a int64_t gets saved into a int32_t.



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/16621
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: Ic8d61b26033f5c486b917e738c9608b0923a844e
Gerrit-Change-Number: 16621
Gerrit-PatchSet: 4
Gerrit-Owner: Sebastian Kemper <sebastian_ml at gmx.net>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua Colp <jcolp at sangoma.com>
Gerrit-Reviewer: Sean Bright <sean at seanbright.com>
Gerrit-CC: George Joseph <gjoseph at digium.com>
Gerrit-CC: Philip Prindeville <philipp at redfish-solutions.com>
Gerrit-Attention: Joshua Colp <jcolp at sangoma.com>
Gerrit-Attention: George Joseph <gjoseph at digium.com>
Gerrit-Attention: Sebastian Kemper <sebastian_ml at gmx.net>
Gerrit-Comment-Date: Mon, 07 Feb 2022 19:14:09 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20220207/70bebb82/attachment.html>