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