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:38:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news.maxwell.syr.edu!tor-nx1.netcom.ca!news1.tor.metronet.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3C962624.5080008@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> <3C921A81.9060708@mail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 Mar 2002 17:38:46 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Mon, 18 Mar 2002 10:38:46 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:21414 Date: 2002-03-18T17:38:46+00:00 List-Id: Chad R. Meiners wrote: > "Kevin Cline" 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