# HG changeset patch
# User William Astle <lost@l-w.ca>
# Date 1485237516 25200
# Node ID 052c5f335a9276ba33c3beb6a177f1f495c03e4b
# Parent  b1adf549d1810872541d282c03b5d17a0090b73a
Fix bug in like terms collection in expression simplification

Like term collection would lose the actual "variable" part of the term if
the second term collected happened to have no coefficient. This would cause
the expression to take the value of the calculated coefficient which is
obviously wrong.

Thanks to hider <stego@satx.rr.com> for reporting the bug and providing a
proper test case.

Observation: this bug has been present since the first pre-release of
lwtools 3.0 when the algebraic expression system was introduced. Apparently
people tend not to create expressions that trigger the like terms handler.
The specific conditions require the symbol to be undefined and the second
operand to the addition has to have no coefficient so it's likely a fairly
rare scenario. Still, it is somewhat surprising that nobody tripped on it
before now.

diff -r b1adf549d181 -r 052c5f335a92 lwlib/lw_expr.c
--- a/lwlib/lw_expr.c	Mon Jan 23 22:54:19 2017 -0700
+++ b/lwlib/lw_expr.c	Mon Jan 23 22:58:36 2017 -0700
@@ -621,6 +621,8 @@
 		lw_expr_t te;
 		
 		te = evaluate_var(E -> value2, priv);
+		if (!te)
+			return;
 		if (lw_expr_contains(te, E))
 			lw_expr_destroy(te);
 		else if (te)
@@ -946,11 +948,18 @@
 					}
 					lw_expr_destroy(o -> p);
 					o -> p = e1;
-					for (o = o2 -> p -> operands; o; o = o -> next)
+					if (o2 -> p -> type == lw_expr_type_oper)
 					{
-						if (o -> p -> type == lw_expr_type_int)
-							continue;
-						lw_expr_add_operand(e1, o -> p);
+						for (o = o2 -> p -> operands; o; o = o -> next)
+						{
+							if (o -> p -> type == lw_expr_type_int)
+								continue;
+							lw_expr_add_operand(e1, o -> p);
+						}
+					}
+					else
+					{
+						lw_expr_add_operand(e1, o2 -> p);
 					}
 					lw_expr_destroy(o2 -> p);
 					o2 -> p = lw_expr_build(lw_expr_type_int, 0);