msg_160.c revision 1.4 1 1.4 rillig /* $NetBSD: msg_160.c,v 1.4 2021/01/31 11:59:56 rillig Exp $ */
2 1.1 rillig # 3 "msg_160.c"
3 1.1 rillig
4 1.1 rillig // Test for message: operator '==' found where '=' was expected [160]
5 1.1 rillig
6 1.2 rillig /* lint1-extra-flags: -h */
7 1.2 rillig
8 1.2 rillig _Bool
9 1.2 rillig both_equal_or_unequal(int a, int b, int c, int d)
10 1.2 rillig {
11 1.2 rillig /* XXX: Why shouldn't this be legitimate? */
12 1.4 rillig return (a == b) == (c == d); /* expect: 160, 160 */
13 1.4 rillig }
14 1.4 rillig
15 1.4 rillig void
16 1.4 rillig eval(_Bool);
17 1.4 rillig
18 1.4 rillig void
19 1.4 rillig unparenthesized(int a, int b, int c, _Bool z)
20 1.4 rillig {
21 1.4 rillig /*
22 1.4 rillig * This one might be legitimate since the second '==' has _Bool
23 1.4 rillig * on both sides. Parenthesizing its left-hand operand doesn't
24 1.4 rillig * hurt though.
25 1.4 rillig */
26 1.4 rillig eval(a == b == z); /* expect: 160 */
27 1.4 rillig
28 1.4 rillig eval((a == b) == z); /*FIXME*//* expect: 160 */
29 1.4 rillig
30 1.4 rillig /*
31 1.4 rillig * This one is definitely wrong. C, unlike Python, does not chain
32 1.4 rillig * comparison operators in the way mathematicians are used to.
33 1.4 rillig */
34 1.4 rillig eval(a == b == c); /* expect: 160 */
35 1.4 rillig
36 1.4 rillig /* Parenthesizing one of the operands makes it obvious enough. */
37 1.4 rillig eval((a == b) == c); /*FIXME*//* expect: 160 */
38 1.4 rillig eval(a == (b == c)); /*FIXME*//* expect: 160 */
39 1.2 rillig }
40