Fixed bug #120819 by prohibiting images from starting with a period;

I'm still not quite sure what exactly was going wrong in the bug, but
I suspect the problem might have actually been due to the deletion of
all images while in the midst of creating an image.  The restriction
is pretty light when it comes to existing code, since it previously
caused a core dump due to an image typePtr field being set to random
garbage, an indication of over-eager use of free()...

1 files changed, 7 insertions, 4 deletions

diff --git a/doc/image.n b/doc/image.n
index 4277ef4..dcd5034 100644
--- a/doc/image.n
+++ b/doc/image.n
@@ -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: image.n,v 1.3 2000/05/15 18:21:47 ericm Exp $
+'\" RCS: @(#) $Id: image.n,v 1.4 2000/11/23 13:50:10 dkf Exp $
 '\" 
 .so man.macros
 .TH image n 4.0 Tk "Tk Built-In Commands"
@@ -27,9 +27,12 @@ It can take several different forms, depending on the
 Creates a new image and returns its name.
 \fItype\fR specifies the type of the image, which must be one of
 the types currently defined (e.g., \fBbitmap\fR).
-\fIname\fR specifies the name for the image;  if it is omitted then
-Tk picks a name of the form \fBimage\fIx\fR, where \fIx\fR is
-an integer.
+\fIname\fR specifies the name for the image
+.VS 8.4
+(which may not start with a period "." character);
+.VE 8.4
+if it is omitted then Tk picks a name of the form \fBimage\fIx\fR,
+where \fIx\fR is an integer.
 There may be any number of \fIoption\fR\-\fIvalue\fR pairs,
 which provide configuration options for the new image.
 The legal set of options is defined separately for each image

path: root/doc

'\"
'\" Copyright (c) 1993-1994 The Regents of the University of California.
'\" Copyright (c) 1994-1996 Sun Microsystems, Inc.
'\"
'\" See the file "license.terms" for information on usage and redistribution
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'\" 
'\" RCS: @(#) $Id: catch.n,v 1.5 2000/09/07 14:27:46 poenitz Exp $
'\" 
.so man.macros
.TH catch n "8.0" Tcl "Tcl Built-In Commands"
.BS
'\" Note:  do not modify the .SH NAME line immediately below!
.SH NAME
catch \- Evaluate script and trap exceptional returns
.SH SYNOPSIS
\fBcatch\fI script \fR?\fIvarName\fR?
.BE

.SH DESCRIPTION
.PP
The \fBcatch\fR command may be used to prevent errors from aborting command
interpretation.  \fBCatch\fR calls the Tcl interpreter recursively to
execute \fIscript\fR, and always returns without raising an error,
regardless of any errors that might occur while executing \fIscript\fR.
.PP
If \fIscript\fR raises an error, \fBcatch\fR will return a non-zero integer
value corresponding to one of the exceptional return codes (see tcl.h
for the definitions of code values).  If the \fIvarName\fR argument is
given, then the variable it names is set to the error message from
interpreting \fIscript\fR.
.PP
If \fIscript\fR does not raise an error, \fBcatch\fR will return 0
(TCL_OK) and set the variable to the value returned from \fIscript\fR.
.PP
Note that \fBcatch\fR catches all exceptions, including those
generated by \fBbreak\fR and \fBcontinue\fR as well as errors.  The
only errors that are not caught are syntax errors found when the
script is compiled.  This is because the catch command only catches
errors during runtime.  When the catch statement is compiled, the
script is compiled as well and any syntax errors will generate a Tcl
error. 

.SH EXAMPLES

The \fBcatch\fR command may be used in an \fBif\fR to branch based on
the success of a script.

.CS
if { [catch {open $someFile w} fid] } {
    puts stderr "Could not open $someFile for writing\\n$fid"
    exit 1
}
.CE
The \fBcatch\fR command will not catch compiled syntax errors.  The
first time proc \fBfoo\fR is called, the body will be compiled and a
Tcl error will be generated. 

.CS
proc foo {} {
    catch {expr {1 +- }}
}
.CE

.SH "SEE ALSO" 
error(n), break(n), continue(n)

.SH KEYWORDS
catch, error