From: Steven Deller <[log in to unmask]>
> Rational has a tool, Rational Purify Ada, that catches precisely the sort of
> errors you are worried about, even from non-Ada 3rd party libraries. This
> tool was used on our own software package that was "sabotaged" by a 3rd party
> library that had two errors -- one was a memory leak (continual growth
> slowing the process and eventually killing it) and the other was a case of
> using access memory after it was returned (causing those nasty
> once-in-a-long-while crashes). Both were diagnosed very quickly with
> Rational Purify.
> The biggest point of this is that unless you have a very limited application,
> the source you write is not the only place where errors can come from.
> Rather than limit yourself to the use of reference-counting objects which
> can make for awkward constructions in the code you write and only protects a
> portion of the application executable, I'd strongly recommend use of a tool
> that can test and verify your entire executable code for all sorts of memory
> referencing errors.
I would say: use both.
Manual management of dynamic objects can be quite tedious and
error-prone. It's better to design for as much robustness as you can,
*and* use verification tools to try to catch whatever errors are left.