Home | History | Annotate | Line # | Download | only in lint1
msg_160.c revision 1.7 
      1 /*	$NetBSD: msg_160.c,v 1.7 2022/05/18 19:25:12 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 
     60 void
     61 assignment_in_comma_expression(int len)
     62 {
     63 
     64 	/*
     65 	 * No extra parentheses, just a comma operator.
     66 	 *
     67 	 * The usual interpretation is that the left-hand operand of the
     68 	 * comma is a preparation, most often an assignment, and the
     69 	 * right-hand operand of the comma is the actual condition.
     70 	 */
     71 	/* FIXME: The following code is totally fine. */
     72 	/* expect+1: warning: operator '==' found where '=' was expected [160] */
     73 	if (len = 3 * len + 1, len == 0)
     74 		return;
     75 
     76 	/* Seen in bin/csh/dir.c 1.35 from 2020-08-09, line 223. */
     77 	/*
     78 	 * The extra parentheses are typically used to inform the compiler
     79 	 * that an assignment using '=' is intentional, in particular it is
     80 	 * not a typo of the comparison operator '=='.
     81 	 *
     82 	 * The comma operator in a condition is seldom used, which makes it
     83 	 * reasonable to assume that the code author selected the operators
     84 	 * on purpose.
     85 	 *
     86 	 * In this case the parentheses are redundant, it's quite possible
     87 	 * that they come from a macro expansion though.
     88 	 */
     89 	/* FIXME: The following code is totally fine. */
     90 	/* expect+1: warning: operator '==' found where '=' was expected [160] */
     91 	if ((len = 3 * len + 1, len == 0))
     92 		return;
     93 
     94 	/*
     95 	 * If the comma expression is part of a larger expression, the
     96 	 * parentheses are required to mark the operator precedence.  The
     97 	 * parentheses must therefore not be interpreted as changing the
     98 	 * intention from a condition to an assignment.
     99 	 */
    100 	/* FIXME: The following code is totally fine. */
    101 	/* expect+1: warning: operator '==' found where '=' was expected [160] */
    102 	if ((len = 3 * len + 1, len == 0) && len < 2)
    103 		return;
    104 }
    105