1Tcl_Interp(3) Tcl Library Procedures Tcl_Interp(3)
2______________________________________________________________________________
6
8 Tcl_Interp - client-visible fields of interpreter structures
9
11 #include <tcl.h>
12 typedef struct {
14 char *result;
15 Tcl_FreeProc *freeProc;
16 int errorLine;
17 } Tcl_Interp;
18 typedef void Tcl_FreeProc(char *blockPtr);
20_________________________________________________________________
21
24 The Tcl_CreateInterp procedure returns a pointer to a Tcl_Interp struc‐
25 ture. This pointer is then passed into other Tcl procedures to process
26 commands in the interpreter and perform other operations on the inter‐
27 preter. Interpreter structures contain many fields that are used by
28 Tcl, but only three that may be accessed by clients: result, freeProc,
29 and errorLine.
30 Note that access to all three fields, result, freeProc and errorLine is │
32 deprecated. Use Tcl_SetResult, Tcl_GetResult, and Tcl_GetReturnOptions │
33 instead.
34 The result and freeProc fields are used to return results or error mes‐
36 sages from commands. This information is returned by command proce‐
37 dures back to Tcl_Eval, and by Tcl_Eval back to its callers. The
38 result field points to the string that represents the result or error
39 message, and the freeProc field tells how to dispose of the storage for
40 the string when it is not needed anymore. The easiest way for command
41 procedures to manipulate these fields is to call procedures like
42 Tcl_SetResult or Tcl_AppendResult; they will hide all the details of
43 managing the fields. The description below is for those procedures
44 that manipulate the fields directly.
45 Whenever a command procedure returns, it must ensure that the result
47 field of its interpreter points to the string being returned by the
48 command. The result field must always point to a valid string. If a
49 command wishes to return no result then interp->result should point to
50 an empty string. Normally, results are assumed to be statically allo‐
51 cated, which means that the contents will not change before the next
52 time Tcl_Eval is called or some other command procedure is invoked. In
53 this case, the freeProc field must be zero. Alternatively, a command
54 procedure may dynamically allocate its return value (e.g. using
55 Tcl_Alloc) and store a pointer to it in interp->result. In this case,
56 the command procedure must also set interp->freeProc to the address of
57 a procedure that can free the value, or TCL_DYNAMIC if the storage was
58 allocated directly by Tcl or by a call to Tcl_Alloc. If interp->freeP‐
59 roc is non-zero, then Tcl will call freeProc to free the space pointed
60 to by interp->result before it invokes the next command. If a client
61 procedure overwrites interp->result when interp->freeProc is non-zero,
62 then it is responsible for calling freeProc to free the old
63 interp->result (the Tcl_FreeResult macro should be used for this pur‐
64 pose).
65 FreeProc should have arguments and result that match the Tcl_FreeProc
67 declaration above: it receives a single argument which is a pointer to
68 the result value to free. In most applications TCL_DYNAMIC is the only
69 non-zero value ever used for freeProc. However, an application may
70 store a different procedure address in freeProc in order to use an
71 alternate memory allocator or in order to do other cleanup when the
72 result memory is freed.
73 As part of processing each command, Tcl_Eval initializes interp->result
75 and interp->freeProc just before calling the command procedure for the
76 command. The freeProc field will be initialized to zero, and
77 interp->result will point to an empty string. Commands that do not
78 return any value can simply leave the fields alone. Furthermore, the
79 empty string pointed to by result is actually part of an array of
80 TCL_RESULT_SIZE characters (approximately 200). If a command wishes to
81 return a short string, it can simply copy it to the area pointed to by
82 interp->result. Or, it can use the sprintf procedure to generate a
83 short result string at the location pointed to by interp->result.
84 It is a general convention in Tcl-based applications that the result of
86 an interpreter is normally in the initialized state described in the
87 previous paragraph. Procedures that manipulate an interpreter's result
88 (e.g. by returning an error) will generally assume that the result has
89 been initialized when the procedure is called. If such a procedure is
90 to be called after the result has been changed, then Tcl_ResetResult
91 should be called first to reset the result to its initialized state.
92 The direct use of interp->result is strongly deprecated (see Tcl_SetRe‐
93 sult).
94 The errorLine field is valid only after Tcl_Eval returns a TCL_ERROR
96 return code. In this situation the errorLine field identifies the line
97 number of the command being executed when the error occurred. The line
98 numbers are relative to the command being executed: 1 means the first
99 line of the command passed to Tcl_Eval, 2 means the second line, and so
100 on. The errorLine field is typically used in conjunction with
101 Tcl_AddErrorInfo to report information about where an error occurred.
102 ErrorLine should not normally be modified except by Tcl_Eval.
103
106 free, initialized, interpreter, malloc, result
107Tcl 7.5 Tcl_Interp(3)