[Swan-dev] *cmp is a little harder to read
Andrew Cagney
andrew.cagney at gmail.com
Thu Nov 2 02:59:21 UTC 2017
On 1 November 2017 at 21:04, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> I'm concerned about eb8a4265ffd98aa2f41a5b98c83876fcbfd19671
> timers: add more generic deltatime_cmp()
>
> expect use to follow the convention: deltatime_cmp(a, b) OP 0
> for instance deltatime_cmp(a, b) <= 0; like strcmp() et.al.
>
>
for anyone puzzled by this, the convention is very old. For instance:
if (a <= b) ...
becomes:
if (...cmp(a, b) <= 0) ...
Operators like .eq. and .neq. are similar:
if (a != b) ...
if (a == b) ...
become:
if (...cmp(a, b) != 0)
if (...cmp(a, b) == 0)
notably neither of the confusing forms (!...cmp(a, b)) and (...cmp(a, b))
are used. With this it becomes easy to transform an expression like:
deltasecs(c->dpd_delay) >= MIN_LIVENESS ? ...
into equivalent function calls:
deltatime_cmp(c->dpd_delay, min_liveness) >= 0 ? ...
using dataless, I suspect the equivalent is:
!dataless(c->dpd_delay, min_liveness) ? ...
but that involves actually thinking; or we go down the path of adding
deltatime_ge() et.al.
It is true that *cmp is a more general primative. But it is also
> harder to read code using it.
>
> So: it is fine to add deltatime_cmp but I disagree with this comment:
> +bool deltaless(deltatime_t a, deltatime_t b); /* obsolete; use
> deltatime_cmp() */
>
> Uses of deltaless seem clearer to me than their replacement.
>
which I keep reading as 'data-less' :-(
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171101/d5cf9d28/attachment-0001.html>
More information about the Swan-dev
mailing list