Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-681841 ] odd error message with missing character
|
From: SourceForge.net <no...@so...> - 2003-02-12 18:29:29
|
Bugs item #681841, was opened at 2003-02-06 13:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=681841&group_id=10894 Category: 43. Parsing and Eval Group: 8.4.1.1 Status: Open Resolution: None Priority: 8 Submitted By: Vince Darley (vincentdarley) Assigned to: miguel sofer (msofer) Summary: odd error message with missing character Initial Comment: This script, when evaluated (note the missing closing square bracket): catch { if {![catch [list foo]} { } } err puts $err puts $errorInfo gives me: invalid command name "fo" while executing "fo" invoked from within "catch [list foo" i.e. 'err' is empty, and errorInfo has somehow dropped the last 'o' from foo. Both of these seem incorrect. ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2003-02-12 13:36 Message: Logged In: YES user_id=80530 Here's an updated patch that takes care of updating tclCompile.c. More bugs fixed, and ::errorInfo trace should now be improved when parsing errors occur. Please review. Still more work to do on Tcl_EvalEx. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-07 20:10 Message: Logged In: YES user_id=80530 Here's another demo of the original bug: % if {1 && "" == [puts \]} {} \ Note that a backslash is printed, not a ] ! ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-07 19:18 Message: Logged In: YES user_id=80530 Here is an updated patch that also includes a fix for Tcl_EvalEx(). I suspect there are still errors involving the setting of iPtr->termOffset. Not ready to commit yet. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-07 18:29 Message: Logged In: YES user_id=80530 There is a similar error in Tcl_EvalEx() that can be demo'd by subst {a[set b [format cd]} no syntax error reported. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2003-02-07 15:57 Message: Logged In: YES user_id=148712 Patch looks good! Q: does it also solve the old bug you mentioned? (I never got around to understanding what it is ...) ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-07 15:30 Message: Logged In: YES user_id=80530 please review this patch. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-07 14:06 Message: Logged In: YES user_id=80530 patch coming soon. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-02-07 11:16 Message: Logged In: YES user_id=79902 I don't know which function has responsibility for stripping the close bracket. The open bracket is obviously consumed by ParseTokens(), but who gets the close? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-02-07 11:13 Message: Logged In: YES user_id=79902 Further investigation seems to indicate the problem as being that when parsing bracketed things, the trailing bracket is consumed by Tcl_ParseCommand, stopping us from telling whether it should have done so. Perhaps. Everything's so recursive it's hard to tell for sure... ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-02-07 10:32 Message: Logged In: YES user_id=79902 Obviously not (or we barf on init.tcl!) :^/ ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-02-07 10:30 Message: Logged In: YES user_id=79902 Yes, shouldn't the tests there come after the test to see if the end of the string has been reached? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2003-02-07 10:28 Message: Logged In: YES user_id=79902 I suspect a problem near tclParse.c:865 ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2003-02-07 06:59 Message: Logged In: YES user_id=148712 Debug notes RE the new error: something subtle going on, witness % set x {set a [format bc]} set a [format bc] % set y [string range $x 0 15] set a [format bc % testparser $x 16 - {set a [format bc} 3 simple set 1 text set 0 simple a 1 text a 0 word {[format bc} 1 command {[format bc} 0 \] % testparser $y 16 missing close-bracket ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-07 01:46 Message: Logged In: YES user_id=80530 Curious. There is a parsing error there, but there always has been. Before, Tcl would parse the expression wrong, allowing the error to go unnoticed, but then the compiler would raise an error when trying to compile the command substitutions in the expr. The *new* error is that Tcl_ParseCommand itself is buggy in handling strings that have a ] following the string to be parsed. See this with testparser {set a [format bc]} 16 in both 8.3 and 8.4. (length 16 does not include the closing ]. Thus a parse error in 8.3, but a mistaken acceptance in 8.4, apparently due to an effective read beyond numbytes when parsing.) Both errors should be fixed. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-06 17:28 Message: Logged In: YES user_id=80530 Error is in parsing nested command evaluations in an expression. Simpler test case: expr {[set a [format bc]} Miguel, error should be found in lines 1261-1313 of tclParseExpr.c ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-06 17:22 Message: Logged In: YES user_id=80530 Ouch! Note that the return from [catch] here is TCL_OK, not TCL_ERROR ! ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-02-06 16:58 Message: Logged In: YES user_id=80530 Therefore my parser rewrite is likely to blame. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2003-02-06 14:17 Message: Logged In: YES user_id=148712 AIEEEEE! Mem corruption in the parser? Introduced between 8.4b1 and 8.4b2 ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=681841&group_id=10894 |
