@CrazyProg
Uh, if it's your program calling the functions why the heck would you want to patch exec?
Karlos already said it:
As it happens, I am wrapping the pool and I have a tiny header for each allocation (I never use it for trivial allocation of a few bytes anyway), so as far as I can see there's no reason I couldn't add basic prev / next node pointers in there.
And this is exactly what he should do.
But the original question, if there is a OS legal way to traverse the allocated memory in a pool. There isn't (for the obvious reason: Memory pool is a "black box", it's internal implementation can change at any time, and has in the past already. AmigaOS 3.9 BB2 introduced new binary tree memory pools).
Anyway, there is a fatal flaw in patching the system in a way you call the original function, and then examine the result: There is no way to be 100% sure the function has returned. In this case, even if you remove the patch the code could still be executing, and your function could be landed long after the executable has been unloaded by shell or workbench. Adding some call counter won't help either, as you could still get rescheduler after you subtract the counter and before executing the final 'return from subroutine'. As such, there is no safe way to remove patches like this.
