[Patches] PyMem [2/8] - Include/mymalloc.h

[Guido van Rossum]

> Okay, will do. A scenario might help:
> 
> 1) Scenario A
> 
> Suppose we want to use a debugging malloc library that collects info
> on where the malloc calls originate from. Assume the interface is:
> 
> d_malloc(size_t n, char* src_file, unsigned long src_line) c.s.
> 
> In this case, we would define (for example in config.h) :
> 
> #define PyCore_MALLOC_FUNC      d_malloc
> ...
> #define PyCore_MALLOC_PROTO	Py_PROTO((size_t, char *, unsigned long))
> ...
> #define NEED_TO_DECLARE_MALLOC_AND_FRIEND
> 
> #define PyCore_MALLOC(n)	PyCore_MALLOC_FUNC((n), __FILE__, __LINE__)
> ...
> 
> 2) Scenario B
> 
> For some reason, we want to use malloc hooks (defined & initialized in a 3rd
> party malloc library) instead of malloc functions.  In this case, we would
> define:
> 
> #define PyCore_MALLOC(n)	( (*malloc_hook)(n) )
> ...
> 
> and ignore the previous definitions about PyCore_MALLOC_FUNC, etc.

Shall I just paste these into the comments in mymalloc.h?

> > Questions:
> > 
> > Do we really need to have even b/w compat macro support for
> > Py_Malloc()?  I think it's cleaner to fail with an error during
> > compilation or linking than to silently mess up things when someone
> > calls it expecting that it will raise an exception where in fact it
> > won't.  I've deleted it.  And also PyMem_XDEL, for the same reason.
> 
> I leave this to your appreciation.
> It's about breaking/fixing 3rd party extensions...

OK, I'll disable them during alpha testing and re-enable them in the
final release.

> > Should the PyCore_* names be _PyCore_* to indicate they are for
> > internal use only?
> 
> Maybe.
> 
> > When *is* it okay to use them?
> 
> In a custom memory manager, not in user's code. They are supposed to be
> defined/overloaded in config.h whenever a custom allocator is used.
> They should never appear in the usual Python-related C code.
> In low-level memory management code, yes (or maybe, depends on the needs)

OK, I'll leave it as it is for now.

--Guido van Rossum (home page: http://www.python.org/~guido/)