comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Does memory leak?
Date: 23 Mar 1995 00:37:19 GMT
Date: 1995-03-23T00:37:19+00:00	[thread overview]
Message-ID: <EACHUS.95Mar22193719@spectre.mitre.org> (raw)
In-Reply-To: sands@clipper.ens.fr's message of 22 Mar 1995 09:06:31 GMT

In article <3kopao$ekg@nef.ens.fr> sands@clipper.ens.fr (Duncan Sands) writes:

  > Does Ada leak memory?  I would like to believe it doesn't, but
  > how does it manage not to (without having to use unchecked
  > deallocation)?

    Ada does not leak memory.  Ada is a language standard, and both
Ada 83 and Ada 95 do a good job of always permitting a compiler to do
it right, and of noting where it may be difficult.

    Let me take this a little further (and add another candidate for
the top 10 Ada 83 references list ;-)  13.10.1(5) says that "FREE(X),
when X is not equal to null, is an indication that the object
designated by X is no longer required, and that the storage it
occupies is to be reclaimed."

     Why the "mealy mouthed" wording?  Because it is possible that the
object designated by X is, in fact, still required, and reclaiming the
storage is likely to cause a system crash.  No one wanted the RM to
require the run-time to reclaim storage which might be locked by other
processes, etc.  AI-356 deals with these sorts of cases, and details
the possible behaviors.

     Now, back to the original issue, there are compilers that leak
storage.  Some of them are Ada compilers.  Much, much more common is
for programmers to write programs that leak storage and blame the
compilers.  This is an especially prevelent practice in C.  It is much
less common in Ada--in fact in Ada, when it comes to memory leaks,
compiler bugs are a close second to program logic bugs.

     There are a very few cases where programs are deliberately
designed to leak storage because it is too expensive to avoid it, but
these are very rare.  (One case that I had something to do with
involves a command line parameter package...it may be possible to
determine when the storage required goes away, but in most cases you
would be saving less in stack or heap space than you lose to added
code space.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...



  parent reply	other threads:[~1995-03-23  0:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-03-22  9:06 Does memory leak? Duncan Sands
1995-03-22 12:04 ` Fred J. McCall
1995-03-23  0:37 ` Robert I. Eachus [this message]
1995-03-23 13:54   ` Arthur Evans Jr
1995-03-23 16:23     ` Robert I. Eachus
1995-03-24 21:08   ` Norman H. Cohen
1995-03-28  0:00     ` Theodore Dennison
1995-03-31  0:00     ` Kent Mitchell
1995-03-23  2:08 ` T. Owen O'Malley
1995-03-24 11:44   ` Robert Dewar
1995-03-27 14:01     ` Theodore Dennison
1995-03-29  0:00       ` John DiCamillo
1995-03-30  0:00         ` Theodore Dennison
1995-03-30  0:00         ` Robb Nebbe
1995-03-30  0:00       ` Henry Baker
1995-04-04  0:00         ` John Baker
1995-04-05  0:00           ` Ray Toal
1995-04-05  0:00           ` Sverre Brubaek
1995-04-05  0:00           ` Pat Rogers
1995-04-05  0:00           ` Tucker Taft
1995-04-06  0:00             ` Norman H. Cohen
1995-04-07  0:00               ` Tucker Taft
1995-03-30  0:00   ` Robert I. Eachus
1995-03-23 22:38 ` Tucker Taft
1995-03-24  1:57 ` Henry Baker
1995-03-24 17:30   ` Larry Kilgallen, LJK Software
1995-03-26  0:00     ` Henry Baker
1995-03-27 15:19     ` Norman H. Cohen
1995-03-27 14:35   ` Kennel
1995-03-24 12:29 ` Mike Meier
1995-03-24 10:46   ` Fred J. McCall
1995-03-24 15:44   ` David Weller
1995-03-25  1:55   ` kkrieser
  -- strict thread matches above, loose matches on Subject: below --
1995-03-27  9:36 Duncan Sands
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox