From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,345a8b767542016e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-18 09:54:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hub1.nntpserver.com!feed.cgocable.net!feed.tor.primus.ca!feed.nntp.primus.ca!tor-nx1.netcom.ca!news1.tor.metronet.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3C9629E3.8030109@home.com> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: memory leakages with Ada? References: <3c90af1e@news.starhub.net.sg> <3c91bfa3.1987537@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 Mar 2002 17:54:45 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Mon, 18 Mar 2002 10:54:45 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:21417 Date: 2002-03-18T17:54:45+00:00 List-Id: 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