Re: memory leakages with Ada?

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Chad R. Meiners wrote:

> "Kevin Cline" <kcline@optelnow.net> wrote in message
> 
>>Dereferencing nil is just as fatal to program execution.  The only
>>
> advantage
> 
>>is that it is more easily debugged because the crash is immediate.
>>Any code that keeps invalid pointers around, whether null or not, is
>>poorly crafted.  Good programmers don't much care about the state
>>of a pointer variable after delallocation because the variable
>>is either going to be reassigned immediately or is going out of scope.
>>
> 
> While it is true that dereferencing a null pointer will raise a
> constraint_error exception, exceptions can be handled gracefully and null
> pointers can be guarded against.  Pointers off to nowhere are very difficult
> to detect in a general manner.


My own personal observation is that C/C++ programmers will err on the

side of efficiency, rather than safety.  After a free()/delete, they'll
usually not set the pointer to null. It also comes up in functions a lot,
like this:

void myfun() {
     char *cp;                  /* work pointer */

Rather than code :

void myfun() {
     char *cp = NULL;           /* work pointer */

The former is very often chosen instead to avoid the overhead
of setting the value to null (or to avoid having to type the
initial assignment, by lazy programmers).

The consequence very often is that later on, in larger functions,
someone will add some functionality or correct it, and get stung
by a bad pointer with garbage in it.  If you're lucky, it will
be such that a fault occurs. Otherwise, memory corruption galore
sets in (if used for storing values or for copying strings) that
will create all kinds of fun.

I have seen this sort of thing create "side effects" on rare
occasions in production C code for years, until it was finally
tracked down. The intermittant problem is the worst kind to
debug.

I like the Ada safety factor with their access types,
and the way Unchecked_Deallocation sets the pointer back to
null. With the speed of processors today, it is a small price
to pay for software correctness.


-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg