<p> Attention is currently required from: Joshua Colp, George Joseph, Sebastian Kemper. </p>
<p><a href="https://gerrit.asterisk.org/c/asterisk/+/16621">View Change</a></p><p>7 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="null">Patchset:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621?tab=comments">Patch Set #4:</a> </p><p style="white-space: pre-wrap; word-wrap: break-word;">I don't want to see this fixed, but I think the unnecessary promotion does more harm than good.</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="null">File include/asterisk/time.h:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621/comment/1a9903ad_9104ee3f">Patch Set #4, Line 33:</a> <code style="font-family:monospace,monospace">#define TIME_T_CAST(x) ((long long)(x))</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">It's trivial to test the sizeof(time_t) and detect whether we need to use PRId64 or PRId32.</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="null">File res/res_calendar_caldav.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621/comment/0ad2d926_f1df23d6">Patch Set #4, Line 408:</a> <code style="font-family:monospace,monospace">                    snprintf(tmp, sizeof(tmp), "%" TIME_T_FMT, TIME_T_CAST(event->start));</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">Since TIME_T_FMT can be something conditionally defined, we shouldn't need to cast unconditionally.</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="null">File res/res_calendar_icalendar.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621/comment/44dab671_62369ee0">Patch Set #4, Line 248:</a> <code style="font-family:monospace,monospace">                  char tmp[100];</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">Maybe I'm missing something, but ULLONG_MAX is 20 digits long, and then one more char for the NUL would be 21.</p></li></ul></li><li style="margin: 0; padding: 0;"><p><a href="null">File res/res_http_media_cache.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621/comment/474ac306_6910535a">Patch Set #4, Line 304:</a> <code style="font-family:monospace,monospace">      long long llv;</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">This isn't necessary.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621/comment/2a6779cc_b673a7be">Patch Set #4, Line 310:</a> <code style="font-family:monospace,monospace">      if (sscanf(metadata->value, "%" TIME_T_FMT, &llv) != 1) {</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">If we set TIME_T_FMT conditionally to the appropriate format (either PRId32 or PRId64) then we can deposit directly into a time_t.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/c/asterisk/+/16621/comment/56c21599_e8336faf">Patch Set #4, Line 314:</a> <code style="font-family:monospace,monospace"> expires.tv_sec = llv;</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">And here we're just creating a potential loss-of-precision error when a int64_t gets saved into a int32_t.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.asterisk.org/c/asterisk/+/16621">change 16621</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/c/asterisk/+/16621"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Ic8d61b26033f5c486b917e738c9608b0923a844e </div>
<div style="display:none"> Gerrit-Change-Number: 16621 </div>
<div style="display:none"> Gerrit-PatchSet: 4 </div>
<div style="display:none"> Gerrit-Owner: Sebastian Kemper <sebastian_ml@gmx.net> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@sangoma.com> </div>
<div style="display:none"> Gerrit-Reviewer: Sean Bright <sean@seanbright.com> </div>
<div style="display:none"> Gerrit-CC: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-CC: Philip Prindeville <philipp@redfish-solutions.com> </div>
<div style="display:none"> Gerrit-Attention: Joshua Colp <jcolp@sangoma.com> </div>
<div style="display:none"> Gerrit-Attention: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-Attention: Sebastian Kemper <sebastian_ml@gmx.net> </div>
<div style="display:none"> Gerrit-Comment-Date: Mon, 07 Feb 2022 19:14:09 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>