Message134775
| Author |
pitrou |
| Recipients |
BreamoreBoy, flub, loewis, neologix, pitrou, sable, tim.peters |
| Date |
2011年04月29日.15:45:40 |
| SpamBayes Score |
1.0741644e-09 |
| Marked as misclassified |
No |
| Message-id |
<1304091918.3587.6.camel@localhost.localdomain> |
| In-reply-to |
<1304091014.49.0.613904654138.issue3526@psf.upfronthosting.co.za> |
| Content |
> Since I want PyMem_MALLOC to call dlmalloc, I would need to export the
> "malloc" symbol from libpython so that Python extensions could use it
> when calling PyMem_MALLOC, but that would impact all malloc calls in
> applications which embed Python for example.
Well, that would be a rather good thing. There are, IIRC, Python API
calls which require that the caller manually frees memory. If the API
call malloc()s memory with a certain allocator and the caller free()s it
with another allocator, the result won't be pretty :)
(a similar discrepancy occurs between function-based APIs and
macro-based APIs: functions get compiled inside the Python library while
macros get compiled within the embedding executable; if library and
application have an incompatible malloc()/free() pair, you will get
similarly funny results) |
|