[ python-Bugs-1494671 ] PyOS_ascii_strtod() uses malloc() directly

[SourceForge.net]

Bugs item #1494671, was opened at 2006-05-24 17:51
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_ascii_strtod() uses malloc() directly

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

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 13:45

Message:
Logged In: YES 
user_id=357491

Changed in rev. 46253 to use PyMem_MALLOC/PyMem_FREE .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-05-25 13:24

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-05-24 18:18

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494671&group_id=5470