Re: memory leakages with Ada?

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

Marin David Condic wrote:

...

> But being an active C programmer at the moment (and sadly shaking my head
> and telling my associates "It doesn't have to be this way..." as we spend
> months debugging and chasing among other typical C problems - memory leaks)
> I find myself having to deal with dynamically allocated data in the most
> mundane of circumstances - often because that's just what many of the
> library calls return to you. (The libraries we are using - not necessarily
> the standard C libraries.) You just find yourself doing mallocs (Bumper
> sticker: "Free The Mallocs!") all over the place and referencing things with
> pointers all the time just because that's the way C wants you to do it. Ada
> doesn't make it necessary to use dynamic allocation or pointers to do
> mundane tasks.
> 
> MDC

This was actually one of my first observations when I started learning Ada95.
A C function does not have a simple way to return a string (a few basic
choices exist, though one can vary the theme somewhat). C++ gets around this
with objects, but they end up resorting to malloc() inside of the object to
carry this off. (excuse the lack of const keywords in these C examples) :

/* The malloc approach */
char *uppercase(char *s) {
     char *buf = strdup(s);   /* Clone the string for modification */

     ...do uppercasing on buf...
     return buf;
}

The caller gets a dynamically allocated string back, and must free it when
he is finished with it. Ug.

/* The dirty old static buffer approach */
char *uppercase(char *s) {
     static char my_big_buf[4096];

     strcpy(my_big_buf,s);
     ...do uppercasing on my_big_buf...
     return my_big_buf;
}

This is very bad, because it won't work for all sized strings. It is also
very unsafe in threaded programs. Ug!

/* The user supplied buffer approach */
char *uppercase(char *s, char *user_buf) {
     strcpy(user_buf,s);
     ...do uppercasing in user_buf...
     return user_buf;
}

This is ugly because the user must supply a receiving buffer. However, this
is also the safest and thread safe way to do it, provided the caller has not
made a size error on the supplied buffer. Another variation is to supply a
buffer size, and then somehow decide how to deal with strings that are too
long (truncate, abort, or whatever).

In Ada95, this mundane issue is mundane and easy :

function Uppercase(S : String) return String is
    UC : String(1..S'Length) := S;
begin
    ...uppercase UC...
    return UC;
end Uppercase;

The caller has equal convenience :

declare
    UC : String := Uppercase("Take that!");
begin
    ...

This is so much easier, and most important *reliable*.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg