From 5dc0afab5ab64d3aa4e4c8f88cdd800d420dcd49 Mon Sep 17 00:00:00 2001
From: hobbs <hobbs>
Date: Thu, 13 Dec 2001 00:58:26 +0000
Subject: docd TCL_DYNAMIC use. [Patch #483989] (porter)

---
 doc/Preserve.3 | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/doc/Preserve.3 b/doc/Preserve.3
index 07c6476..b240022 100644
--- a/doc/Preserve.3
+++ b/doc/Preserve.3
@@ -5,7 +5,7 @@
 '\" See the file "license.terms" for information on usage and redistribution
 '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
 '\" 
-'\" RCS: @(#) $Id: Preserve.3,v 1.2 1998/09/14 18:39:49 stanton Exp $
+'\" RCS: @(#) $Id: Preserve.3,v 1.3 2001/12/13 00:58:26 hobbs Exp $
 '\" 
 .so man.macros
 .TH Tcl_Preserve 3 7.5 Tcl "Tcl Library Procedures"
@@ -89,6 +89,12 @@ The type of \fIblockPtr\fR (\fBchar *\fR) is different than the type of the
 \fIclientData\fR argument to \fBTcl_EventuallyFree\fR for historical
 reasons, but the value is the same.
 .PP
+When the \fIclientData\fR argument to \fBTcl_EventuallyFree\fR
+refers to storage allocated and returned by a prior call to
+\fBTcl_Alloc\fR or another function of the Tcl library, then the
+\fIfreeProc\fR argument should be given the special value of
+\fBTCL_DYNAMIC\fR.
+.PP
 This mechanism can be used to solve the problem described above
 by placing \fBTcl_Preserve\fR and \fBTcl_Release\fR calls around
 actions that may cause undesired storage re-allocation.  The
@@ -99,5 +105,8 @@ The implementation does not depend in any way on the internal
 structure of the objects being freed;  it keeps the reference
 counts in a separate structure.
 
+.SH "SEE ALSO"
+Tcl_Interp, Tcl_Alloc
+
 .SH KEYWORDS
 free, reference count, storage
-- 
cgit v0.12