Mercurial > hg > index.cgi
changeset 434:052c5f335a92
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.
| author | William Astle <lost@l-w.ca> |
|---|---|
| date | Mon, 23 Jan 2017 22:58:36 -0700 |
| parents | b1adf549d181 |
| children | 5524649f4784 |
| files | lwlib/lw_expr.c |
| diffstat | 1 files changed, 13 insertions(+), 4 deletions(-) [+] |
line wrap: on
line diff
--- 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);