<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 November 2017 at 11:50, D. Hugh Redelmeier <span dir="ltr"><<a href="mailto:hugh@mimosa.com" target="_blank">hugh@mimosa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">| From: Andrew Cagney <<a href="mailto:cagney@vault.libreswan.fi">cagney@vault.libreswan.fi</a>><br>
| New commits:<br>
| commit 9e5d7a6855f1e89c03537e0a7983fd<wbr>352190f693<br>
| Author: Andrew Cagney <<a href="mailto:cagney@gnu.org">cagney@gnu.org</a>><br>
| Date:   Thu Nov 2 13:21:09 2017 -0400<br>
|<br>
|     timers: use intmax_t for deltamillisecs<br>
|<br>
|     The signed type is used since deltatime_t can be -ve.  On 32-bit<br>
|     systems, code using long was limited to +-12 days (lucky all timeouts<br>
|     are less than that).<br>
|<br>
|     Update some obvious printf statements (use %jd) and variables (replace<br>
|     unsigned long with intmax_t).<br>
<br>
I'm sorry I didn't mention this earlier.<br>
<br>
(I don't remember the details of whether this needs to be signed or<br>
not.  I'll ignore that for now.)<br>
<br></blockquote><div><br></div><div>Since a delay can never be -ve use an unsigned value.   Except when code breaks leading to huge +ve values.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
intmax_t is kind of horrible for correctness.  Portable code can have no idea<br>
what range of values that it represent (and no idea how expensive it is<br>
in object code).<br>
<br></blockquote><div><br></div>While I'm hoping for 128-bits; I'm pretty sure it is only 64-bits.</div><div class="gmail_quote"><br></div><div class="gmail_quote">What we do know is that it is so big that it can represent the #milliseconds since the epoch; and it won't make any measurable difference to pluto's overall performance.<br></div><div class="gmail_quote"><div>(if my back of envelope calculation is correct, we'll run into problems in 100 million years).<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course the same can be said of int and long.<br>
<br>
I recommend type int32_t since:<br>
<br>
- we know that it is good enough<br>
<br></blockquote><div><br></div><div>We know it isn't good enough.</div><div><br></div><div>Since the current time in seconds, converted to milliseconds, won't fit in int32_t we're setting ourselves up for truncation problems.<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- we can check that settings from config files don't violate this<br>
  constraint<br>
<br>
(But C now specifies that int is at least 32 bits wide, so it would be<br>
good enough.  long is allowed to be only 32 bits wide too so it<br>
doesn't really have an advantage over int.)<br>
<br>
If int32_t is too limiting, use int64_t.<br></blockquote><div><br></div><div>and then fight PRId64 <a href="http://et.al">et.al</a>; %jd is so much friendlier.<br></div></div></div></div>