[Swan-dev] intmax_t

[Andrew Cagney]

On 3 November 2017 at 11:50, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> | From: Andrew Cagney <cagney at vault.libreswan.fi>
> | New commits:
> | commit 9e5d7a6855f1e89c03537e0a7983fd352190f693
> | Author: Andrew Cagney <cagney at gnu.org>
> | Date:   Thu Nov 2 13:21:09 2017 -0400
> |
> |     timers: use intmax_t for deltamillisecs
> |
> |     The signed type is used since deltatime_t can be -ve.  On 32-bit
> |     systems, code using long was limited to +-12 days (lucky all timeouts
> |     are less than that).
> |
> |     Update some obvious printf statements (use %jd) and variables
> (replace
> |     unsigned long with intmax_t).
>
> I'm sorry I didn't mention this earlier.
>
> (I don't remember the details of whether this needs to be signed or
> not.  I'll ignore that for now.)
>
>
Since a delay can never be -ve use an unsigned value.   Except when code
breaks leading to huge +ve values.

intmax_t is kind of horrible for correctness.  Portable code can have no
> idea
> what range of values that it represent (and no idea how expensive it is
> in object code).
>
>
While I'm hoping for 128-bits; I'm pretty sure it is only 64-bits.

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.
(if my back of envelope calculation is correct, we'll run into problems in
100 million years).

Of course the same can be said of int and long.
>
> I recommend type int32_t since:
>
> - we know that it is good enough
>
>
We know it isn't good enough.

Since the current time in seconds, converted to milliseconds, won't fit in
int32_t we're setting ourselves up for truncation problems.


- we can check that settings from config files don't violate this
>   constraint
>
> (But C now specifies that int is at least 32 bits wide, so it would be
> good enough.  long is allowed to be only 32 bits wide too so it
> doesn't really have an advantage over int.)
>
> If int32_t is too limiting, use int64_t.
>

and then fight PRId64 et.al; %jd is so much friendlier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171103/53db16af/attachment.html>