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

[Sebastian Kemper]

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

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


Patch Set 4:

(2 comments)

Patchset:

PS4: 
> Just curious... […]
In patchsets 1 throgh 3 PRId64 was used. In patchset 4 it wouldn't make sense as the patch tries to avoid these platform details.


PS4: 
I don't know why apparently you didn't see my reply. I hope this time you do.

PRId64 is fine for print functions. But it doesn't help you when scanning. Then you have to make your own assumptions, checking if the platform you're (cross-)compiling for uses (long) or (long long). There may even portability issues with PRId64 itself, because maybe there are libcs (old ones?) that don't define it.

A lot of guesswork involved. Today that is, not just "some time in the future", when more libcs will make changes to address the year 2038 issue. For instance, support for target "Arc" was added to glibc a while ago. That's a 32 bit target, but glibc sets it up with a 64 bit time_t. I don't know why. But I'm venturing a guess that on Arc targets you'd run into problems right now with glibc because of it. Asterisk will loose the AOR as soon as a client registers it. Which is what I saw happening on a 32 bit mips target with musl 1.2.0.

So always using (long long) seems to be the way with the least amount of effort required, while providing maximum portability, in my opinion.

This isn't my idea, even. A while ago I asked on the musl mailing list and got good feedback there. The person was even nice enough to send a pull request to freeswitch: https://github.com/signalwire/freeswitch/pull/1409

I also sent a pull request to kamailio, which got accepted: https://github.com/kamailio/kamailio/pull/2894

I really hope you see my reply this time, because it took me at least 10 minutes to write it 😊

Kind regards,
Seb



-- 
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-Attention: George Joseph <gjoseph at digium.com>
Gerrit-Comment-Date: Tue, 16 Nov 2021 21:44:56 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: George Joseph <gjoseph at digium.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20211116/a08136f7/attachment.html>