On Thu, 4 Jan 2007, Miller Puckette wrote:
Both are there for future possible optimizations. The "size" parameter would allow for much more space-optimized memory allocation than malloc() can offer
I can think of ways to make space-optimised allocators without any such size parameter. Actually I have no idea what kind of worthwhile space-optimisation you'd be able to do with that, because every technique I can think of, is replaceable by a technique that doesn't need that info.
(and I've also used it to trace memory corruption bugs once or twice).
How can you do it better with a simple homebrew system than with a professional quality tool like Valgrind? (or the non-free Purify)
I ask because I've made my own allocation verifiers several times and they hardly caught any significant amount of bugs. 99% of the memory corruption bugs I've had, have been dangling pointer bugs. Valgrind is able to find much more than all of the bugs that my homebrew systems has been able to find.
The "t_symbol" field could be used to pre-determine data type conversions, in case the type system gets richer...
What's the likelihood of that ever happening? Then what happens to code that currently makes misleading declarations?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada