Re: [TCLCORE] tcl/tk 8.6 schedule?

[Adam W. <awi...@ma...>]

On Sat, 2008-12-06 at 18:42 +0000, Donal K. Fellows wrote:
> Adam Williamson wrote:
> > Aren't TCL_DYNAMIC and TCL_VOLATILE options too, though? When would
> > those be used?
> 
> Originally (we're talking over 10 years ago now) TCL_STATIC meant that
> Tcl could just keep a reference to the string and never modify it,
> TCL_VOLATILE meant "copy immediately", and TCL_DYNAMIC meant "I give you
> this string, ckfree() it when you're done". But we've reorganized the
> way we manage the result since then; I think both TCL_STATIC and
> TCL_VOLATILE do the same thing now (copies), and TCL_DYNAMIC does the
> same except for freeing the argument too. I think. I don't feel like
> re-reading the source to find out! (If in doubt, use TCL_VOLATILE and
> then free the buffer yourself if it was allocated.)
> 
> Modern code uses Tcl_SetObjResult (which is actually more efficient than
> the old code could ever be) or Tcl_AppendResult (an old API that is just
> too convenient and which was redesigned inside).

Now you're getting slightly over my head (remember, no coder here!) but
I get the basics. The API documentation could probably stand to be
updated, in that case :). It still reads:

"If freeProc is TCL_STATIC it means that string refers to an area of
static storage that is guaranteed not to be modified until at least the
next call to Tcl_Eval. If freeProc is TCL_DYNAMIC it means that string
was allocated with a call to Tcl_Alloc and is now the property of the
Tcl system. Tcl_SetResult will arrange for the string's storage to be
released by calling Tcl_Free when it is no longer needed.If freeProc is
TCL_VOLATILE it means that string points to an area of memory that is
likely to be overwritten when Tcl_SetResult returns (e.g. it points to
something in a stack frame). In this case Tcl_SetResult will make a copy
of the string in dynamically allocated storage and arrange for the copy
to be the return string for the current Tcl command."

...unless, of course, that says the same as what you said in a way that
I completely didn't get :)
-- 
adamw