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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
