Line 103 shows a use of a bare malloc() instead of the
proper memory-related macro.

Logged In: YES 
user_id=31435

Well, it's not really a bug.  If a module wants to use
malloc/free internally, that's fine.  I can't think of a
reason for _why_ this code wants to do that, but it doesn't
really hurt.

Somtimes there is a good reason.  For example, the code
providing a portable notion of thread-local storage in
thread.c uses malloc deliberately, because those functions
can be called when the GIL isn't held (i.e., multiple
threads can call them simultaneously).  The Python memory
families, like almost all parts of the Python C API, are
free to assume that the GIL is held; in particular, obmalloc
does assume that, so it would be disastrous if thread.c used
that memory family instead.

Logged In: YES 
user_id=357491

OK.  Well, considered it is free within the function and all
memory use is done through C API functions (memcpy() and
strtod() specifically, I don't see any reason not to move
over to PyMem_Malloc() since I can do that quickly.

Oh, and the file is Python/pystrtod.c and it's line 104 for
those who don't know where the function is.

Logged In: YES 
user_id=357491

Changed in rev. 46253 to use PyMem_MALLOC/PyMem_FREE .

Logged In: YES 
user_id=849994

Reopening as there is no check for the return value of
malloc, as Tim noticed on python-cvs.

Logged In: YES 
user_id=849994

Added a NULL handler in rev. 46524.