Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#2583 Expr Parser Permits Syntax Error

obsolete: 8.4.5
closed-fixed
5
2004-10-04
2004-01-26
Donal K. Fellows
No

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.

Discussion

  • Reinhard Max
    Reinhard Max
    2004-01-26

    Logged In: YES
    user_id=124643

    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
    user_id=79902

    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
    2004-02-13

    • assigned_to: hobbs --> dkf
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-13

    Logged In: YES
    user_id=72656

    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
    user_id=79902

    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
    user_id=79902

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

     
    • status: open --> closed-fixed