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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,133de21eb82605b
X-Google-Attributes: gid103376,public
From: Mats Weber <Mats.Weber@elca-matrix.ch>
Subject: Re: How do functions return unbounded arrays?
Date: 1998/06/18
Message-ID: <35885BE1.B1CE0503@elca-matrix.ch>#1/1
X-Deja-AN: 363688449
Content-Transfer-Encoding: 7bit
References: <358444BA.757121D8@cl.cam.ac.uk>
 <1998061518584100.OAA28557@ladder01.news.aol.com>
 <35865075.9D7DCBD@cl.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii
Organization: ELCA Matrix SA
Mime-Version: 1.0
Reply-To: Mats.Weber@elca-matrix.ch
Newsgroups: comp.lang.ada
Date: 1998-06-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Markus Kuhn wrote:

> John Herro wrote:
> > The following program raises Storage_Error on my machine when
> > compiled with Open Ada (an Ada 83 compiler).
> 
> > with Text_IO;
> > procedure Test is
> >    S : String(1 .. 18);
> > begin
> >    for L in Long_Integer range
> >         10_000_000 .. 99_999_998 loop
> >       S := Long_Integer'Image(L) &
> >            Long_Integer'Image(L + 1);
> >    end loop;
> > end Test;

> Thanks for that example. That is exactly an implementation of
> of my bad gut feeling about the lack of a clear description in
> the RM that guarantees me when these secretly allocated heap
> blocks will be deallocated. Some guarantee that whatever a variable
> length function return secretly allocates does not survive the next
> semicolon would be very reassuring, otherwise programmers have
> little idea about what memory leaks their code might contain and
> this could be a safety risk.
> [...]

You seem to be considering this as expected behavior, but I think it's not.
It's a compiler bug. The compilers I have used do not leak storage on such
constructs. Leaking memory when allocators are called repeatedly without
deallocation is OK, but leaking storage on constructs that can be implemented
on the stack is not OK.

It is true that Ada 83 lacks specification in that respect (e.g.
Unchecked_Deallocation is not forced to do anything but set the pointer to
null). I do not know exactly what Ada 95 has to say on memory leaks for
stack-implementable constructs.