[TCLCORE] Re: Hintermayer's string allocation patch

[Jeffrey H. <jef...@aj...>]

> From: George Howlett [mailto:gah@blueberry]
	...
> I agree with you on this last point.  In my own code do the same
> thing.  When allocating memory for structures, strings, etc., there's
> no practical way of recovering from memory exhaustion.  Panic-ing is a
> reasonable solution.
>
> But there's another class of allocations where I do want to know if I
> can't allocate the requested amount of memory.  When I allocate a
> large block of storage for for a vector, the contents of a file, etc.
> I want to tell the user that his/her request failed.

For that reason I think the need for a non-panic'ing alloc still exists.
Tcl_SafeAlloc perhaps?

	...
> I have no argument with panic-ing.  But after looking at TclpAlloc, I
> don't see where it will panic unless TCL_DEBUG is defined.  And this
> is only if you also turn on USE_TCL_ALLOC (-DUSE_TCLALLOC=1).  So for
> non-Windows users, they will get a segfault instead of an error
> message.

The default builds on both Unix and Windows (I don't know about the
Mac) will hit the panic code.  The twisty trail of following #defines
in tcl.h/tclCkalloc.c can be confusing, but it happens.  I assume the
same for the Mac.

BTW, just to make it clear for others, Tcl still does use the Tcl mem
allocator by default on Windows (-DUSE_TCLALLOC=1), but not on Unix.
We were considering changing this when moving to default compiling with
VC++6, as we've been told the default mem allocator finally has some
brains on Windows.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.