On Monday, March 19, "Chris 'Xenon' Hanson" wrote: > > Optimally, you could switch between allocators as a compile-time > define. U se a tougher allocator for debugging and stress testing. Use > a lighter, faster one in situ ations where you are confident that the > code is solid and needs speed more than bullet-res istance.
If that was usefull, people would do this all the time. You're making a number of assumptions. Amoung them is that the ligther allocator does not have any bugs that are exploitable. That there is no interaction between it and the rest of your code (say it allocated free'd memory in a certain pattern that is exploitable by external code), and a host of other things. Also, as most people that have done large-scale real-world deployment of services will tell you, you need real-world excersizing of your code in order to find your bugs. The rest (test data, etc) is a way to get some assurance, but in the end it does not substitute for the real thing. Compile time options are bad. --Toby.
