[Python-bugs-list] apply(): throws MemoryError when sending an {} as the keyword list (PR#85)

[Guido van Rossum]

> 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/)