#2583 Expr Parser Permits Syntax Error

obsolete: 8.4.5
Donal K. Fellows

Shouldn't the following be a syntax error:
expr {false eqfalse}
and also this:
expr {1eqint(2)}It looks to me like the 'eq' (and
'ne' too) operator doesn't check that it is not
immediately followed by another character that could
form part of a continuous literal or function name.


  • Reinhard Max
    Reinhard Max

    Logged In: YES

    Another question is how 1eq1 should be handled. Currently it
    is allowed, and exercised by the test suite. Although the
    respective tests (expr-7.14, and expr-8.14 .. expr-8.17)
    don't explicitely state that they are meant to test eq and
    ne without white space around the operator.

    • assigned_to: msofer --> hobbs
  • Logged In: YES

    I think it is best for the expression parser to at least
    check that the letters 'eq' and 'ne' are not followed by an
    alphabetic character.

    Note for Tcl9: supporting '2eq2' as an expression is a
    really bad idea since it may interfere with
    application-defined functions. We should fix the lexer to be
    more conventional (which is probably what Jeff's original
    intention was, after all. I suspect '2eq2' was really an
    unintended side effect).

    Assigning to Jeff for his input, as he was the creator of
    the 'eq' and 'ne' operators in the first place.

  • Jeffrey Hobbs
    Jeffrey Hobbs

    • assigned_to: hobbs --> dkf
  • Jeffrey Hobbs
    Jeffrey Hobbs

    Logged In: YES

    The support for things like 2eq2 was actually intentional
    and something I had to make work solely because 2==2 is
    supported, but prior to the changes for recognized unquoted
    booleans, there were no other possibilities of conflicts.
    0eqfalse used to be a syntax error because it had to be at
    least 0eq"false", which is more clearly separated. Now that
    that is blurred with bare booleans, I suspect a check for
    !alpha is correct, although I don't agree that 2eq2 should
    become an error right now.

  • Logged In: YES

    We always should have done that in parsing because we allow
    user-defined function names (though thankfully very few
    people actually do this!) and have (officially) no reserved
    letter sequences there.

  • Logged In: YES

    Fixed in HEAD. Can't be bothered to backport; most people
    won't be hit by this fault.

    • status: open --> closed-fixed