Re: [Python-checkins] python/dist/src/Objects listobject.c, 2.176, 2.177
On Sun, Jan 18, 2004 at 12:31:04PM -0800, tim_one@users.sourceforge.net wrote:
Update of /cvsroot/python/python/dist/src/Objects In directory sc8-pr-cvs1:/tmp/cvs-serv17990
Modified Files: listobject.c Log Message: Revert change accidentally checked in as part of a whitespace normalization patch.
Index: listobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/listobject.c,v [snip] *************** *** 1882,1887 **** saved_ob_item = self->ob_item; self->ob_size = 0; ! /* self->ob_item = empty_ob_item = PyMem_NEW(PyObject *, 0); */ ! self->ob_item = empty_ob_item = PyMem_NEW(PyObject *, roundupsize(0));
if (keyfunc != NULL) { --- 1879,1883 ---- saved_ob_item = self->ob_item; self->ob_size = 0; ! self->ob_item = empty_ob_item = PyMem_NEW(PyObject *, 0);
if (keyfunc != NULL) {
Is there a particular reason for allocating zero-sized memory for this? On my test, assigning NULL on self->ob_item instead is worked either. Hye-Shik
On Mon, Jan 19, 2004 at 05:48:38AM +0900, Hye-Shik Chang wrote:
Is there a particular reason for allocating zero-sized memory for this? On my test, assigning NULL on self->ob_item instead is worked either.
Yes. I think that the explanation goes something like this: Only values returned by malloc/calloc/realloc are suitable as an argument to realloc/free. So, if you want to start with 0 bytes but not special case the deallocation or reallocation case, you write f = malloc(0); instead of f = NULL; later, you can use f = realloc(f, newsize); /* Ignoring error checking */ and f = free(f) instead of if (f) f = realloc(f, newsize); else f = malloc(newsize); and if(f) free(f); now, some systems have malloc(0) return NULL, and accept free(NULL) as a no-op, and realloc(NULL, newsize) as malloc(newsize), but behavior other than that is allowed by the C standard. Jeff
On Sun, Jan 18, 2004 at 03:09:13PM -0600, Jeff Epler wrote:
On Mon, Jan 19, 2004 at 05:48:38AM +0900, Hye-Shik Chang wrote:
Is there a particular reason for allocating zero-sized memory for this? On my test, assigning NULL on self->ob_item instead is worked either.
Yes. I think that the explanation goes something like this:
Only values returned by malloc/calloc/realloc are suitable as an argument to realloc/free. So, if you want to start with 0 bytes but not special case the deallocation or reallocation case, you write f = malloc(0); instead of f = NULL; later, you can use f = realloc(f, newsize); /* Ignoring error checking */ and f = free(f) instead of if (f) f = realloc(f, newsize); else f = malloc(newsize); and if(f) free(f);
now, some systems have malloc(0) return NULL, and accept free(NULL) as a no-op, and realloc(NULL, newsize) as malloc(newsize), but behavior other than that is allowed by the C standard.
Thanks for the explanation. But listobject isn't using realloc and ob_item == NULL case is concerned in the code already. In PyList_New: 73 if (size <= 0) { 74 op->ob_item = NULL; 75 } Excuse me but am I missed something? Hye-Shik
[Hye-Shik Chang]
Thanks for the explanation. But listobject isn't using realloc
To the contrary, listobject uses realloc() a lot, but that doesn't matter here. empty_ob_item has to be a unique pointer value so that the later if (self->ob_item != empty_ob_item || self->ob_size) { /* The user mucked with the list during the sort. */ error check is robust. The C standard doesn't promise much about malloc(0), but it does promise that pointers returned by distinct malloc(0) calls are non-equal so long as none have been passed to free(). In contrast, all NULL pointers must compare equal. If empty_ob_item were NULL, and user code (e.g.) added something to the list during sorting, then managed to NULL it out again, the error check about couldn't catch that. In any case, the patch you're talking about was simply reverting a change I made by mistake, and the restored code has been there forever. Ain't broke, don't fix <wink>.
participants (3)
-
Hye-Shik Chang -
Jeff Epler -
Tim Peters