[TCLCORE] Re: Hintermayer's string allocation patch

[George H. <ga...@si...>]

In message <NDB...@aj...>, "Je
ffrey Hobbs" writes:

 :  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
page is that Tcl_Alloc and Tcl_Free are replacements for malloc and
free.  Therefore Tcl_Alloc should ape malloc's behavior.

     These procedures provide a platform and compiler independent
     interface  for  memory  allocation.   Programs  that need to
     transfer ownership of memory blocks between  Tcl  and  other
     modules  should  use  these  routines rather than the native
     malloc() and free() routines  provided  by  the  C  run-time
     library.

And from Sun's manual on malloc(3X)...

     If  there  is  no  available  memory,  malloc(),  realloc(),
     memalign(),  valloc(),  and  calloc() return a null pointer.
     When realloc() returns NULL, the block pointed to by ptr  is
     left  intact.   If  size,  nelem,  or  elsize is 0, a unique
     pointer to the arena is returned.

 : 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...

--gah

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