[TCLCORE] Re: Hintermayer's string allocation patch

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

> From: George Howlett [mailto:ga...@si...]
	...
>  :  However, that requires changing around the ckalloc routines,
>  :  because they panic by default when malloc returns NULL.
>
> In 8.3, "ckalloc" (TclpAlloc) panics at memory exhaustion only when
> you have compiled with -DTCL_DEBUG and -DUSE_TCLALLOC=1.  If it does
> otherwise, then TclpAlloc is broken.  The implication from the manual

Well, that's just the way it is.  Tcl_Alloc/ckalloc *will* panic in
Tcl (since 8.1) if you get a NULL from malloc.  This has been hashed
out in numerous newsgroup threads.  The basic reasoning that I've heard
(I wasn't around for this decision), is that if you are running out of
memory, you're screwed.  It's better to panic with the "Unable to alloc"
message than it is to follow on and fail because nowhere does the core
actually handle a NULL return from ckalloc.

BTW, the docs for Tcl_Alloc, et al don't say anywhere that they are
drop-in replacements for malloc, et al, just that they should instead
be used when fiddling with memory shared by the core routines.

>  : bytes = (char *) ckallocEx(howMuchIWant, howMuchINeed);
>
> I disagree with this.  We don't need another API function/macro to do
> the right thing.  Is there some unexplained reason why ckalloc should
> panic when out of memory?  Other than the fact the calling routine
> sometimes doesn't test the result...

"sometimes" is actually never for the core, and I suppose it was easier
to make the check in the alloc function.  Anyway, creating an alternative
ckalloc would solve these problems.

In any case for core "improvements", lets not argue about what is the
"right thing" (this goes with other running threads).  Accept what the
core does now, for whatever reason, and then lets question whether there
is a more intuitive/appropriate way to do things.

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.