[Michael Hudson] > ... > Presuambly it would be possible to do this wrapped around malloc() & > free() too? Provided they were spelled PyMem_Malloc etc, sure. The debug routines as sketched don't make any secret assumptions about the underlying allocators they call. > No real point, I guess. There may be an excellent point to it: one of the pad bytes could be used to record which "API family" a block of memory came from. Then a mismatching realloc/free could be caught directly at the time it happened. >> + The Debug free first uses the address to find the number of bytes >> originally asked for, then checks the 8 bytes on each end for >> sanity (in particular, that the PYMALLOC_FORBIDDENBYTEs are still >> intact). >> XXX Make this checking a distinct entry point. > Yes. Particularly if you can call it from gdb. Is something extraordinary required to make that possible? I had in mind nothing fancier than extern void _PyMalloc_DebugCheckAddress(void* p); > ... > Is it worth having an option where you *don't* call _Free? Not if I have to code it. > ... > What are you waiting for? <wink> For endless silly objections to fade away <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4