[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