Tcl Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to tclconference@googlegroups.com
or submit via the online form by Sep 9.
Ticket UUID: 522849
Title: TIP #87 reference implementation
Type: Patch Version: None
Submitter: trier Created on: 2002-02-26 07:21:21
Subsystem: 20. [interp] Assigned To: dgp
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2002-03-08 03:17:10
Resolution: Accepted Closed By: dgp
    Closed on: 2002-03-07 20:17:10
Description:
Reference implementation for TIP #87, "Allow Tcl
Access to the Recursion Limit".  Includes tests and
documentation.
User Comments: dgp added on 2002-03-08 03:17:10:
Logged In: YES 
user_id=80530

commited for 8.4a5/8.4b0

andreas_kupries added on 2002-03-08 02:55:59:
Logged In: YES 
user_id=75003

Patching:    Applies cleanly.
Configuring: Ok.
Compilation: Ok.
Testsuite:   Ok. (Passed extended testsuite).

Go.

dgp added on 2002-03-07 08:17:58:

File Added - 18931: tip87dgp.patch

Logged In: YES 
user_id=80530

Here is a revised patch implementing TIP 87, tip87dgp.patch.

Changes include:
 * Factored out common code in the two OPT_RECLIMIT
   sections into a static function, SlaveRecursionLimit.
 * Added tests for values of newlimit that are too large
   to fit in the C int that Tcl_SetRecursionLimit accepts
   as an argument.
 * Documented that upper limit.
 * Rephrased and reorganized some of the documentation
   changes.

hobbs added on 2002-03-03 05:53:43:
Logged In: YES 
user_id=72656

this looks OK to me.  Passing it onto dgp as sponsor.

trier added on 2002-02-28 00:40:24:

File Added - 18531: tip87.patch

Logged In: YES 
user_id=372112

OK, I switched to Tcl_IsSafe(). I wonder why I didn't do that in the first place.

I added an iPtr variable for the (Interp *) type. I'm a bit confused by that, since
in the rest of the generic/tclInterp.c code, the direct use of a typecast from (Tcl_Interp *)
to (Interp *) is more common than an intermediate variable, but it's there now.

Finally, I added tests for recursion limits <= 0 and modified other tests to check
the return value when the newlimit parameter is present.

dgp added on 2002-02-27 11:31:19:
Logged In: YES 
user_id=80530

Before we integrate this, I'd prefer making calls to
Tcl_IsSafe() rather than directly probing the interp
flags.  I guess that's up to the maintainer though.

It's also Tcl coding convention to have separate
variables for (Tcl_Interp *) and (Interp *) values.

Those are implementation details though.  TIP 87 looks to
be in good shape.  I'll make a last call for comments
tomorrow.

dgp added on 2002-02-27 02:04:53:
Logged In: YES 
user_id=80530

that's strange.  oh well, I can.

dgp added on 2002-02-27 02:04:18:

File Deleted - 18453:

trier added on 2002-02-27 01:58:18:
Logged In: YES 
user_id=372112

OK, I guess I can't delete it.

trier added on 2002-02-27 01:43:34:
Logged In: YES 
user_id=372112

Old patch deleted.

trier added on 2002-02-27 01:42:50:

File Added - 18472: tip87.patch

trier added on 2002-02-27 01:42:42:
Logged In: YES 
user_id=372112

Very diplomatically put, Don. :-)

Here is a new version of the patch that fixes both oversights.

dgp added on 2002-02-27 00:41:50:
Logged In: YES 
user_id=80530

I didn't look with great care, but I didn't see anything
to disable this subcommand in a safe interp.

dgp added on 2002-02-27 00:37:16:
Logged In: YES 
user_id=80530

Ah.  OK.  Let's spell out that situation in the TIP
as well, so it's clear what spec folks will be voting on.

trier added on 2002-02-27 00:35:12:
Logged In: YES 
user_id=372112

Whoops! My mistake. The fallback error should be issued only if the current interp is changing its
own recursion limit. Otherwise, the code should let Tcl_Eval() et al error out naturally.

I'll fix it right away.

dgp added on 2002-02-27 00:29:30:
Logged In: YES 
user_id=80530


Of course I meant to ask:

Why shouldn't the current interp go on to evaluate the next
command?

dgp added on 2002-02-27 00:21:00:
Logged In: YES 
user_id=80530

I see that this implementation "falls back" if the
new limit is less than the current run level in
the interp that's having its limit changed.  It's
not clear to me that's the right thing to do if that
interp is not the interp evaluating the [interp
recursionlimit].

# Assume an evaluation in slave is in the call stack
# somewhere
interp recursionlimit slave 1

Should I really see an error in the current interp?
The limit in the current interp has not been exceeded.
Why should the current interp go on to evaluate the next
command?

trier added on 2002-02-26 14:21:22:

File Added - 18453: tmptmp

Attachments: