Re: Limited_Controlled and out parameters

[Adam Beneschan <adam@irvine.com>]

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 types 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. Optionally means that it might as well be empty (null);
>
> Then:
> 
>    procedure Set (H : out Holder; Value : in Integer) is
>    begin
>       H.I := new Integer'(Value);
>    end Set;
> 
> 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:
> 
>    Set (H, 7);
>    Set (H, 8);
>    -- ...
> 
> Each time it is called on the same H (Holder) object, a new Integer is allocated - 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 are 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 rather than two different types).

Off the top of my head, I'd say that since Int_Ptr can be modified and since it's causing the memory leak, then you should use a Controlled (not Limited_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 really 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 to (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 except for bounds and discriminants.  But Ada 95 introduced parameters that were required to be passed by reference; in those cases, I don't think they're "notionally uninitialized" any more.

                       -- Adam