Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1853 bug in expr error handler

obsolete: 8.3.4
closed-invalid
miguel sofer
5
2004-03-28
2002-04-18
miguel sofer
No

There is an inconsistent behaviour in the [expr] error
handler: the moment when an invalid operand is detected
and an error is raised depends on the evaluation path
of the expression (compiled at compile-time vs at
run-time):

% set a 08
08
% expr $a - 1
"08" is an invalid octal number
% expr {$a - 1}
can't use invalid octal number as operand of "-"

The compiled-at-run-time version seems not to respect
the expr.n manual page, which states:
"If no numeric interpretation is possible, then an
operand is left as a string (and only a limited set of
operators may be applied to it)."

% set a 08
08
% expr $a == 1
"08" is an invalid octal number
% expr {$a == 1}
0

See also the (off-topic?) comments in [Bug #542588].

Discussion

  • Don Porter
    Don Porter
    2003-11-13

    • milestone: --> obsolete: 8.3.4
     
  • miguel sofer
    miguel sofer
    2004-03-28

    Logged In: YES
    user_id=148712

    Mmhh ... this is probably my misunderstanding of 'expr'; if
    nobody else complains, I'll close this as invalid.

     
  • miguel sofer
    miguel sofer
    2004-03-28

    • status: open --> closed-invalid
     
  • Don Porter
    Don Porter
    2004-03-29

    Logged In: YES
    user_id=80530

    Looks like a distinction
    between a parsing error
    and an evaluation error.