The issue is that we expect to be able to use timer values from @TIMER in calculations in @EVAL. That used to work when @EVAL ignored the fact that sometimes @TIMER returned strings after the value.
The current behavior of @EVAL makes sense; the behavior of @TIMER does not (and does not agree with the documentation).
A long-standing bug was fixed when v30 added octal numbers and new integer argument operators.
Still not sure exactly what you're driving at here - you want to know all the possible bad arguments you can pass that @EVAL won't complain about? Something like %@EVAL[666 1] isn't an invalid argument - a dumb and useless argument, but not invalid. (You're asking for an integer no-op.) When you start adding random text (which could be interpreted as variables, function names, or string operators) you are unlikely to be pleased with the results.
%@EVAL[666 ms] is interpreted as "Do a no-op with the nonexistent variable ms", which throws an error because you probably don't want to use non-existent variables. %@EVAL[666 1 ms] is interpreted as "Do a no-op with an integer, then ignore everything until the next operator". And relying on undocumented parser behavior will get you in trouble every time.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.