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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7348b9598602fc10,start
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.190.104 with SMTP id gp8mr3423383pbc.4.1340372365237;
        Fri, 22 Jun 2012 06:39:25 -0700 (PDT)
Path: 
 l9ni7005pbj.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Limited_Controlled and out parameters
Date: Fri, 22 Jun 2012 06:37:31 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <544352ec-9d9e-4f08-8629-50ef394ab846@googlegroups.com>
NNTP-Posting-Host: 195.182.34.201
Mime-Version: 1.0
X-Trace: posting.google.com 1340372365 21490 127.0.0.1 (22 Jun 2012 13:39:25
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 22 Jun 2012 13:39:25 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=195.182.34.201;
 posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 2012-06-22T06:37:31-07:00
List-Id: <comp.lang.ada>

I have found a conceptual problem with the rules for Limited_Controlled typ=
es when they are used as out parameters in subprograms.

Consider:

   type Int_Ptr is access Integer;
   type Int_Holder is new Limited_Controlled with record
      I : Int_Ptr;
   end record;

The intent is that the Int_Holder can optionally hold an integer value. Opt=
ionally means that it might as well be empty (null);

Then:

   procedure Set (H : out Holder; Value : in Integer) is
   begin
      H.I :=3D new Integer'(Value);
   end Set;

All is fine and the conveniently overriding procedure Finalize cleans the m=
ess at the end.
The problem is that the Set procedure can be called many times in a row:

   Set (H, 7);
   Set (H, 8);
   -- ...

Each time it is called on the same H (Holder) object, a new Integer is allo=
cated - this is a memory leak.
A possible solution is to check if the holder already contains some value a=
nd deallocate it before planting a new one. The problem is - this is an *ou=
t* parameter and notionally it is uninitialized. Well, controlled types are=
 passed by reference, so it *would* work fine, but that's just cheating (an=
d a more strict data flow would reject it as a clear violation).

What's the proper solution?

--=20
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com