1 /* $NetBSD: msg_160.c,v 1.5 2021/01/31 12:20:00 rillig Exp $ */ 2 # 3 "msg_160.c" 3 4 // Test for message: operator '==' found where '=' was expected [160] 5 6 /* lint1-extra-flags: -h */ 7 8 _Bool 9 both_equal_or_unequal(int a, int b, int c, int d) 10 { 11 /* 12 * Before tree.c 1.201 from 2021-01-31, lint warned about each of 13 * the '==' subexpressions even though there is nothing surprising 14 * about them. 15 */ 16 return (a == b) == (c == d); 17 } 18 19 void 20 eval(_Bool); 21 22 void 23 unparenthesized(int a, int b, int c, _Bool z) 24 { 25 /* 26 * This one might be legitimate since the second '==' has _Bool 27 * on both sides. Parenthesizing its left-hand operand doesn't 28 * hurt though. 29 */ 30 eval(a == b == z); /* expect: 160 */ 31 32 /* 33 * Before tree.c 1.201 from 2021-01-31, lint warned about the 34 * parenthesized '==' subexpression even though there is nothing 35 * surprising about it. 36 */ 37 eval((a == b) == z); 38 39 /* 40 * This one is definitely wrong. C, unlike Python, does not chain 41 * comparison operators in the way mathematicians are used to. 42 */ 43 eval(a == b == c); /* expect: 160 */ 44 45 /* Parenthesizing one of the operands makes it obvious enough. */ 46 /* 47 * Before tree.c 1.201 from 2021-01-31, lint warned about the 48 * parenthesized '==' subexpression even though there is nothing 49 * surprising about it. 50 */ 51 eval((a == b) == c); 52 /* 53 * Before tree.c 1.201 from 2021-01-31, lint warned about the 54 * parenthesized '==' subexpression even though there is nothing 55 * surprising about it. 56 */ 57 eval(a == (b == c)); 58 } 59