Tcl Source Code

I ran into a little problem where a bug in code to call
ckalloc ended up trying to allocate 0 bytes. That
crashed in the Win32 malloc when compiled with
Mingw. I can't see any reason to allow a zero byte
allocation, and it seems like adding a test like the
following could not hurt. Any objections?

--- generic/tclCkalloc.c        19 Jan 2003 07:21:18
-0000      1.19
+++ generic/tclCkalloc.c        15 Aug 2005 00:59:24 -0000
@@ -373,6 +373,10 @@
     if (validate_memory)
         Tcl_ValidateAllMemory (file, line);

+    if (size == 0) {
+        panic("attempt to ckalloc 0 bytes, %s line
%d", size, file, line);
+    }
+
     result = (struct mem_header *)
TclpAlloc((unsigned)size +
                               sizeof(struct
mem_header) + HIGH_GUARD_SIZE);
     if (result == NULL) {

Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

Logged In: YES 
user_id=72656

OK, this is the DB routines, and result == NULL panic is OK
because we add guard bytes.  IOW, if we don't get mem, we
don't have any to get ....

Logged In: YES 
user_id=72656

We certainly shouldn't panic on 0 alloc requests - that is
perfectly valid in the C standard.  I see where Mo is
requesting the patch we do seem to have a latent bug in that
we shouldn't panic on (result == NULL) unless (size != 0),
as AIX and some other systems do return NULL for 0-byte allocs.

If a crash occured in the mingw compile, than I would
backtrack to the sources making the alloc, as
ckalloc(0)/malloc(0) is valid C.  We did have to correct
code in tkImg*.c once regarding this (0 size image allocs)
because we simply weren't handling the case of such requests
- which was a bug in the image code, not in ckalloc(0) per se.

Logged In: YES 
user_id=79902

The core currently checks (in Tcl_Alloc()) to see whether a
NULL low-level alloc result is coming from asking for zero
bytes; if so, it *doesn't* panic. This indicates that
panic-ing on zero-alloc is probably wrong.

Logged In: YES 
user_id=113501

I don't think we should take this patch, it breaks
compatibility with malloc(), which is technically allowed to
allocate a "zero byte item" and return it.

The ANSI C standard states that this is "implementation
defined"; however, we should probably just treat it as a one
byte request.

File Added - 145666: ckalloc.patch