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-Thread: 103376,7348b9598602fc10 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.227.67 with SMTP id ry3mr90613pbc.8.1340379922861; Fri, 22 Jun 2012 08:45:22 -0700 (PDT) Path: l9ni7332pbj.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Limited_Controlled and out parameters Date: Fri, 22 Jun 2012 08:43:51 -0700 (PDT) Organization: http://groups.google.com Message-ID: <08532996-7c1f-4521-b1fc-41a03e26fcce@googlegroups.com> References: <544352ec-9d9e-4f08-8629-50ef394ab846@googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1340379921 1362 127.0.0.1 (22 Jun 2012 15:45:21 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 22 Jun 2012 15:45:21 +0000 (UTC) In-Reply-To: <544352ec-9d9e-4f08-8629-50ef394ab846@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-06-22T08:43:51-07:00 List-Id: On Friday, June 22, 2012 6:37:31 AM UTC-7, Maciej Sobczak wrote: > I have found a conceptual problem with the rules for Limited_Controlled t= ypes when they are used as out parameters in subprograms. >=20 > Consider: >=20 > type Int_Ptr is access Integer; > type Int_Holder is new Limited_Controlled with record > I : Int_Ptr; > end record; >=20 > The intent is that the Int_Holder can optionally hold an integer value. O= ptionally means that it might as well be empty (null); > > Then: >=20 > procedure Set (H : out Holder; Value : in Integer) is > begin > H.I :=3D new Integer'(Value); > end Set; >=20 > All is fine and the conveniently overriding procedure Finalize cleans the= mess at the end. > The problem is that the Set procedure can be called many times in a row: >=20 > Set (H, 7); > Set (H, 8); > -- ... >=20 > Each time it is called on the same H (Holder) object, a new Integer is al= located - this is a memory leak. > A possible solution is to check if the holder already contains some value= and deallocate it before planting a new one. The problem is - this is an *= out* parameter and notionally it is uninitialized. Well, controlled types a= re passed by reference, so it *would* work fine, but that's just cheating (= and a more strict data flow would reject it as a clear violation). (I assume that Int_Holder and Holder were intended to be the same type rath= er than two different types). Off the top of my head, I'd say that since Int_Ptr can be modified and sinc= e it's causing the memory leak, then you should use a Controlled (not Limit= ed_Controlled) type instead of Int_Ptr. Then it will be finalized whenever= the I component is reassigned. I also wouldn't worry about "cheating". For by-reference parameters, I don= 't think there's that much difference between OUT and IN OUT, if any. It r= eally can't be, because if you have a procedure (or, now, a function) with = an OUT parameter of a controlled type, the procedure still has to be able t= o (implicitly) read the "input" value of the parameter in order to finalize= it before it's assigned. So the idea that a procedure should treat an OUT= parameter as if its value is garbage until the procedure assigns something= to it doesn't work any more. It was different in Ada 83, where there was = no such thing as a parameter that *had* to be passed by reference, and the = rules said that a procedure couldn't read the value of an OUT parameter exc= ept for bounds and discriminants. But Ada 95 introduced parameters that we= re required to be passed by reference; in those cases, I don't think they'r= e "notionally uninitialized" any more. -- Adam