[Python-bugs-list] [ python-Bugs-606495 ] malloc called directly

noreply@sourceforge.net noreply@sourceforge.net
Mon, 09 Sep 2002 05:46:05 -0700


Bugs item #606495, was opened at 2002-09-08 17:55
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606495&group_id=5470

Category: None
>Group: Not a Bug
>Status: Deleted
>Resolution: Wont Fix
Priority: 5
Submitted By: Steven Ellmore (stevenellmore)
Assigned to: Nobody/Anonymous (nobody)
Summary: malloc called directly

Initial Comment:
At least the following files use malloc directly instead of 
PyCore_MALLOC_FUNC (defined in pymem.h):

_sre.c
classobject.c
compile.c

There are many others too, but I'm working from a 
stripped down codebase.

The Mac version is the worst offender.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-09 01:23

Message:
Logged In: YES 
user_id=21627

That comment does not longer exist in pymem.h, for Python 2.3.

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

Comment By: Steven Ellmore (stevenellmore)
Date: 2002-09-08 20:44

Message:
Logged In: YES 
user_id=608086

Ok, that's fair enough....but I was basing the report on the
comment in pymem.h:
"To make sure the interpreter is user-malloc friendly, all
memory
APIs are implemented on top of this one."






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

Comment By: Tim Peters (tim_one)
Date: 2002-09-08 19:27

Message:
Logged In: YES 
user_id=31435

malloc is a standard C function.  If you want to use Python 
in some context that doesn't support standard uses of it, 
the burden falls on you to make that possible.  I suggest 
the easiest way out may be for you to

#define malloc my_allocation_function

etc at the top of Python.h.  I don't want to obfuscate the 
Python codebase for this non-standard unique requirement.

BTW, note that compile.c currently (CVS) calls 
PyObject_Malloc instead of malloc.  That was done for 
performance reasons.  OTOH, the various threading 
implementations must call malloc, as it's currently 
forbidden to them to include a non-system header file.

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

Comment By: Steven Ellmore (stevenellmore)
Date: 2002-09-08 19:00

Message:
Logged In: YES 
user_id=608086

It's a bug because it should be possible to embed Python in 
an application that does its own memory management and 
have Python play nice with it.

In this scenario, the ONLY thing that should be calling malloc 
directly is the memory manager.  Everything else should 
route through the memory manager so that application 
specific heap management can take place.

At the embedded system scale (think: no virtual memory), 
the typical operation of a custom memory manager is to 
malloc all of memory, which means that any subsequent 
rogue calls to malloc will fail.


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

Comment By: Tim Peters (tim_one)
Date: 2002-09-08 18:55

Message:
Logged In: YES 
user_id=31435

Why do you think this is a bug?  There's no rule against 
calling malloc(), other than if you do, you must call free() 
instead of one of the PyMem or PyObject free functions.

Note that PyCore_MALLOC_FUNC doesn't exist in the 
current CVS source -- we purged a lot of unused complexity 
in those macro layers for 2.3.

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

Comment By: Steven Ellmore (stevenellmore)
Date: 2002-09-08 18:27

Message:
Logged In: YES 
user_id=608086

Followup:
Oops...I think the correct solution is to have them use 
PyMem_MALLOC and NOT PyCore_MALLOC_FUNC.

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

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