[tz] logical and arithmetic ops and operator precedence.

[Brian Inglis]

On 2019-10-27 22:44, Paul Eggert wrote:
> On 10/27/19 6:39 PM, Christos Zoulas wrote:
>> can we put parentheses around the operation for clarity?
> 
> I don't see how parentheses would help much in the expression here:
> 
>         if (lotm_ok & tm_ok
>             ? (delta(&tm, &lotm) == t - lot
>                && tm.tm_isdst == lotm.tm_isdst
>                && strcmp(abbr(&tm), ab) == 0)
>             : lotm_ok == tm_ok) {
> 
> It should be reasonably obvious even to a naive reader (who doesn't know that &
> has higher precedence than ?:) that the first line contains a subexpression.
> Although we could parenthesize it, just as we could parenthesize the
> subexpressions in each of the other lines for the benefit of naive readers, the
> result:
> 
>         if ((lotm_ok & tm_ok)
>             ? ((delta(&tm, &lotm) == t - lot)
>                && (tm.tm_isdst == lotm.tm_isdst)
>                && (strcmp(abbr(&tm), ab) == 0))
>             : (lotm_ok == tm_ok)) {
> 
> is arguably a bit harder to read than the original, at least for people who know
> C syntax - which is the intended audience here.

I can see a point here, in that if someone changed the type or value from bool
to some random bit(s) operator "&" could fail whereas operator "&&" would not,
just as some developers like to ensure "bool" values using !!lval.

To be absolutely sure, I can see robust commercial code using:

	if ((!!lotm_ok && !!tm_ok)

to defend against a brain dead production fix in the dead of night by a sleep
deprived rookie intern in some third world dev center on a slow ssh connection!

I still hold off on third quarter maintenance of some software to allow time for
autumn production patches to hit inadequately reviewed and tested summer patches.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.