msg_160.c revision 1.5 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