Re: Does memory leak?

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <evans-230395085432@evans.pgh.pa.us> evans@evans.pgh.pa.us (Arthur Evans Jr) writes:

  > There are several areas where compilers in the early days of Ada leaked.
  > One is for a function that returns an unconstrained type.  You can't
  > allocate stack space for the returned value on the call side because you
  > don't know how much space is needed.  It's possible though tricky for
  > the callee to put the returned value on its own stack space and for the
  > caller to reclaim that space later.  Early implementations often put the
  > result on the heap,  and then some failed to release that space.  Later,
  > pressures of the market place forced such unpleasantness to be fixed.

    Yes, very true.  In the "early days" of Ada--and I certainly won't
mention names, since current compilers bear no relation--there were
"partial" Ada compilers, quickly brought to market, that had storage
leaks all over the place.  I never had this experience with a
validated compiler, although I know there were some leaks in some
versions of validated compilers.  But these were usually bugs, not
deliberate design omissions.

  > I suspect that the command line package Robert refers to returns type
  > STRING, an unconstrained type.

    No, the problem was that it retrieved a structure from the OS
containing the (parsed) parameters.  There was no easy way to tell
when the user finished making calls to the package without adding a
"finished with engines" call, so the structure was never released.  At
the time losing one to two thousand bytes of heap (or stack) was
noticable, but not really serious.

  > Note that several functions defined by the standard return unconstrained
  > types:
  >     Text_IO.Name
  >     Text_IO.Form
  > Beginners have a hard time figuring out how to call these.

   No, calling is easy--it's what to do with the result that is
hard. ;-)  Somehow it seems very counterintuitive that you must
declare an object as a constant only if you can't know the actual
size.  Fortunately this problem is gone in Ada 95.  One of the many
fixes to "little nits" that make Ada 95 so much nicer to use.

--

					Robert I. Eachus

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