Tcl Source Code

OriginalBugID: 2136 Bug
Version: 8.1
SubmitDate: '1999-06-03'
LastModified: '1999-08-14'
Severity: MED
Status: Assigned
Submitter: techsupp
ChangedBy: hobbs
OS: Other
Machine: NA
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name:
Don Porter

ReproducibleScript:
# FILE: test.tcl
    puts stderr [info patchlevel]
    break

ObservedBehavior:
$ tclsh8.0 test.tcl
    8.0.5
    invoked "break" outside of a loop
        while executing
    "# FILE: test.tcl
    puts stderr [info patchlevel]
    break
    "
        (file "test.tcl" line 1)
    
    $ tclsh8.1 test.tcl
    8.1.0

DesiredBehavior:
Ideally, consistent error messages between 8.0.x and 8.1.x Tcl releases.
    
    At a minimum, there should be some error message reported by Tcl 8.1.x.



Verified in 8.2.0.  Returns an empty line. 
-- 08/14/1999 hobbs

Logged In: YES 
user_id=80530

OK, there's no script that can demo the problem with
Tcl_EvalTokensStandard.  Only a direct call to it
can do that.  This only needs fixing if T_ETS remains
in the public interface.

Tcl_EvalTokens and Tcl_ParseVar both call T_ETS, but
they already have their own rules about masking away
non-TCL_OK codes.

I think the patch is ready for commit, and in the
interest of restoring Tk to usable status, I'm doing
that now.  Leaving the report open for Miguel to
review the T_ETS issue.

Logged In: YES 
user_id=80530

That was a [subst] bug.  See Tcl Bug 536879.

Logged In: YES 
user_id=80530

This might be related, or might be a different [subst] bug:

% list [catch {subst {a[break]b}} msg] $msg $errorInfo
0 a {}
% list [catch {subst {a$foo([break])b}} msg] $msg $errorInfo
1 {} {
    while executing
"subst {a$foo([break])b}"}

Logged In: YES 
user_id=80530

Yes, that patch fixes the console bug reported by JCW.

Test suite passes too, including your new tests.

I'm still concerned about possible problems with
Tcl_EvalTokensStandard making multiple calls to 
Tcl_EvalEx in its for loop and having that 2d and later
calls not respect the original ALLOW_EXCEPTIONS value.
I haven't cooked up a test case for that, though.

I'm pleased to see the call to Tcl_LogCommandInfo within
TclCompEvalObj almost completely removed.  That meshes
nicely with some of my TIP 90 work.  It's only still
there for sort of handling errors from Tcl_AsyncInvoke.
Is it doing anything close to the right thing in that
case?

Regarding documentation of TCL_RETURN coming back from
a Tcl_*Eval* routine, rather than document current
behavior, I'd rather change it so that it makes more
sense.  See the comments for Tcl Bug 219191 about the
inconsistent mess that's currently in place.

File Deleted - 20236: 



File Added - 20257: allowExcept.patch1

Logged In: YES 
user_id=148712

New patch, as discussed in the chat. Don, could you please
check if JCW's Tk issue is solved by this? 

Also, I'd rather let *you* describe what happens to
TCL_RETURN (in doc/AllowExc.3). Actually, it is not trivial
to explain: there is no library function similar to [return]
(or did I miss it?), and the field iPtr->returnCode is not
accessible to standard extensions (it is part of Interp but
not Tcl_Interp).

Logged In: YES 
user_id=80530

As discussed in the chat, that's not it either.

Be sure you also test the case:

    foo [set a 1] [break]

File Added - 20236: allowExcept.patch

Logged In: YES 
user_id=148712

:( Tcl_AllowExceptions was not enabled for the new path!

This new patch may solve the issue, without yet giving the
correct result
for Don's new test script.

Logged In: YES 
user_id=80530

Re-opening this one.  The fix is incomplete.  There's
real weirdness going on with Tcl_AllowExceptions().  It
can only be set, never cleared.  Evaluation of an alias
is one thing that sets it.

Use this demo script:
# FILE: demo.tcl
interp alias {} patch {} info patchlevel
puts stderr [patch]
break

$ tclsh8.0 demo.tcl
8.0.5
invoked "break" outside of a loop
    while executing
"interp alias {} patch {} info patchlevel
puts stderr [patch]
break
"
    (file "demo.tcl" line 1)
$ tclsh8.3 demo.tcl
8.3.4

$ tclsh8.4 demo.tcl
8.4a5

$

Logged In: YES 
user_id=148712

Yes, but ... In 8.3 the function Tcl_EvalEx is in
tclParse.c; in order to apply this fix I'd have to choose
among
  1. move all evaluation functions to tclBasic.c, as in 8.4
  2. promote "static void ProcessUnexpectedResult" to "void
TclProcessUnexpectedResult" in tclBasic.c
  3. duplicate ProcessUnexpectedResult in tclParse.c

For such a long-standing bug (since 8.1), I thought it
wasn't worth it. I'll reconsider 2 or 3 if poked ...

Logged In: YES 
user_id=80530

Can a corresponding patch work for
core-8-3-1-branch ?

Logged In: YES 
user_id=148712

Patch committed.

File Added - 20130: 219181.patch

Logged In: YES 
user_id=148712

The direct evaluation path (Tcl_EvalEx) was missing the
"ProcessUnexpectedResult at level 0" code. The enclosed
patch fixes this.

Logged In: YES 
user_id=80530

Miguel,
Sorry to assign this directly to you, but SF won't let me
assign it to "None" as I want.

Logged In: YES 
user_id=80530

Dropping ownership of this bug so a maintainer can pick
it up.

Logged In: YES 
user_id=80530

See also #219384

Logged In: YES 
user_id=79902

Hmm.  The problem is not that the [break] isn't having an
effect, but rather
that no error message is being generated.  See the following
session:

$ cat test.tcl 
# FILE: test.tcl 
puts stderr [info patchlevel] 
break 
puts stderr "FELL THROUGH"
$ tclsh8.3 test.tcl 
8.3.2

$ tclsh8.0 test.tcl 
8.0.4
invoked "break" outside of a loop
    while executing
"# FILE: test.tcl 
puts stderr [info patchlevel] 
break 
puts stderr "FELL THROUGH"
"
    (file "test.tcl" line 1)
$ tclsh8.3
% source test.tcl
8.3.2
invoked "break" outside of a loop

Note first that neither 8.0.4 or 8.3.2 fell through to the
rest of the script, so the break itself must have worked. 
Second, note that there is an extra blank line generated
after the printing of the patchlevel under 8.3.2, so
something is coming of the break.  It looks to me like this
is actually either a problem with Tcl_EvalFile or with the
default error handler in 8.3.2, and this problem is not
exercised when running interactively...

Re-opened.  Described bug is still present in both
8.3.2 and 8.4a2.

Not sure when this got fixed, but it works identically in 8.0.4 and 8.3.2, so I'm closing this one.