TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Lundquist <[log in to unmask]>
Reply To:
Mark Lundquist <[log in to unmask]>
Date:
Mon, 1 Mar 1999 15:11:18 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
From:  Steven Deller <[log in to unmask]>

> Kevin,
> 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.

ATOM RSS1 RSS2