Should formulas be allowed to contain the assignment (=) operator?

@slspencer reported in bug#906 that weird things happen if you introduce the assignment operator (=) in the formula for a user variable. Say you have #v10 with some formula (e.g. #v9*#v8) and the value 15. Then you introduce a variable #v11, and in the formula editor you type β€œ#v10=5”. This is allowed by the program. The result is that #v11 assumes the value 5, but also #v10 is set to the same value 5, despite its formula that also remains intact in the dialog. What the program executes is the formula #v11=#v10=5, and logically both variables are set to 5. This can be prevented (I have tried it) by removing the symbol β€˜=’ from every formula that is parsed in the routine Calculator::EvalFormula. You will then get an Error as soon as you type β€˜=’ in a formula. The big question is: is this a viable solution? Are there, anywhere else in the program, formulas that can contain assignments? This would be the case if a formula could evaluate to a boolean, but as far as I can see this does not happen in EvalFormula. However, I have no idea what else could go wrong after this change.

1 Like

Removing the = sign from the formulas is not the answer. Formulas allow for conditional statements, so you can do stuff like (bust_circ<100?(((bust_circ/10)*2)+2):(bust_circ/10)+10+2) = 23.2 (bust_circ = 112)

Is this a viable solution?.. No.

Are there, anywhere else in the program, formulas that can contain assignments? Yes… anywhere a formula is used.

What could go wrong? You could break existing patterns.

Besides… the issue is not with the formulas, but rather the variables table.

1 Like

I’ve found a fix. Need to test a bit more and clean up the commits.

vtable

2 Likes