logical and arithmetic ops and operator precedence.

Hi, Can we please change in zdump.c: 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) { to: 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) { for clarity? Both lotm_ok and tm_ok are booleans... Thanks, christos

On 10/27/19 2:53 PM, Christos Zoulas wrote:
if (lotm_ok & tm_ok
...
if ((lotm_ok && tm_ok)
for clarity? Both lotm_ok and tm_ok are booleans...
Plain AND is simple and goes pretty much all the way back to Boole, if not further. In contrast, short-circuit AND has dicey semantics and is a relative newcomer. Although it's awkward that C uses "&" for both plain and integer-bitwise AND, for booleans I mildly prefer "&" to "&&" when either will do, if only to remind readers of "&&"'s problems.

That is fine and your preference usually produces shorter code (although I prefer "logical and" in a logical context and only use "bitwise and" in an arithmetic context), but can we put parentheses around the operation for clarity? Thanks, christos
On Oct 27, 2019, at 7:06 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/27/19 2:53 PM, Christos Zoulas wrote:
if (lotm_ok & tm_ok
...
if ((lotm_ok && tm_ok)
for clarity? Both lotm_ok and tm_ok are booleans...
Plain AND is simple and goes pretty much all the way back to Boole, if not further. In contrast, short-circuit AND has dicey semantics and is a relative newcomer. Although it's awkward that C uses "&" for both plain and integer-bitwise AND, for booleans I mildly prefer "&" to "&&" when either will do, if only to remind readers of "&&"'s problems.

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.

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.
participants (4)
-
Brian Inglis
-
Christos Zoulas
-
christos@zoulas.com
-
Paul Eggert