Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1693986 ] Buggy string handling in command traces?
|
From: SourceForge.net <no...@so...> - 2007-04-04 02:13:25
|
Bugs item #1693986, was opened at 2007-04-03 22:26 Message generated for change (Comment added) made by msofer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1693986&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 45. Traces Group: development: 8.5a6 Status: Open Resolution: None Priority: 8 Private: No Submitted By: miguel sofer (msofer) Assigned to: Don Porter (dgp) Summary: Buggy string handling in command traces? Initial Comment: Looking at TEOv and TEOvI, trying to follow the trace code, I think I found a few possible bugs related to the 'command' string (no demos yet). (1) TEOv only generates a 'command' string from objv when there are interp-wide traces, but fails to do so on traces on the specific command. This is needed later on, especially since traces use the string interface. Note that this hints at moving the string generation to TEOvI, after Tcl_GetCommandFromObj has happened. (2) TclCheckInterpTraces and TclCheckExecutionTraces accept a counted (not nul-terminated) string for the 'command', but pass on just the char* and not the count. The receiver has no way to avoid a buffer overflow in case the string was not nul-terminated. Both TEBC and Tcl_Eval call TEOvI with counted strings (from the bc source resp from a parse token), so that the problem is not just theoretic. I see one possible solution: (a) generate nul-terminated strings for the traces, with better detection of when it is needed. This should happen in TCIT/TCET. I am not so worried of the duplication of effort in case both interp-wide and command-specific traces are in place (b) modify the api so that the user generates a string itself from objc/objv if none is supplied. This could well happen in TCIT and TCET, instead of burdening the callers to do so. Candidate patch forthcoming. ---------------------------------------------------------------------- >Comment By: miguel sofer (msofer) Date: 2007-04-03 23:13 Message: Logged In: YES user_id=148712 Originator: YES Patch attached File Added: trace.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1693986&group_id=10894 |