Tcl Source Code

Reference implementation for TIP #87, "Allow Tcl
Access to the Recursion Limit".  Includes tests and
documentation.

Logged In: YES 
user_id=80530

commited for 8.4a5/8.4b0

Logged In: YES 
user_id=75003

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

Go.

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.

Logged In: YES 
user_id=72656

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

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.

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.

Logged In: YES 
user_id=80530

that's strange.  oh well, I can.

File Deleted - 18453:

Logged In: YES 
user_id=372112

OK, I guess I can't delete it.

Logged In: YES 
user_id=372112

Old patch deleted.

File Added - 18472: tip87.patch

Logged In: YES 
user_id=372112

Very diplomatically put, Don. :-)

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

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.

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.

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.

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?

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?

File Added - 18453: tmptmp