[Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)
guido@CNRI.Reston.VA.US
guido@CNRI.Reston.VA.US
Fri, 24 Sep 1999 16:11:13 -0400 (EDT)
> The use of
>
> #define MALLOC_ZERO_RETURNS_NULL 1
>
> at the top of mymalloc.h worked fine...
> By curiousity.. I just tried compiling the following:
>
> /*testmalloc.c*/
> #include <stdio.h>
> main()
> {
> int *fp;
> int *sp;
>
> fp = (int*)malloc(0);
> sp = (int*)malloc(sizeof(int));
> printf("fp: %x\nsp: %x\n", fp, sp);
> }
> /**/
>
> First, I just compiled normally:
>
> > cc -o testmalloc testmalloc.c
> > ./testmalloc
> fp: 10015010
> sp: 10015020
>
> Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
> memory library - which seems to be the default used after running the
> configure script)
>
> > cc -o testmalloc testmalloc.c
> > ./testmalloc
> fp: 0
> sp: 10015048
>
> So... It looks like without libmalloc, we're actually getting memory when we
> "shouldn't" - but from reading your source code it seems like that's the way
> it is usually made to work (weird). When compiling with libmalloc, the
> returned 0 is triggering the MemError flag.
There are two schools of thought here -- one says that malloc(0)
should return a non-NULL pointer because it doesn't "fail": it
correctly allocates an array of 0 bytes; the other of course says that
malloc(0) is nonsensical and should return an error. ANSI C allows
both (as long as consistent) so Python supports either.
Could it be that the configure script was run without -lmalloc but
later for some reason you rebuilt with -lmalloc? (I think that
enabling threading might cause this.)
> At ceval.c:2467, should it even get to this point if the passed in kwargs ==
> {}? It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
> isn't NULL. It seems like at this point that it should be..
{} is an object so it is not NULL. Given a correct malloc, the code
will work with {} or NULL.
--Guido van Rossum (home page: http://www.python.org/~guido/)