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 |