Re: On absurdity of collections 7.6.1 (11.1/3)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2021-09-29 23:38, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 2021-09-29 13:05, Simon Wright wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>>         type Item_Ptr is access all Item;
>>>>         function New_Item
>>>>                  (  Pool : in out Root_Storage_Pool'Class;
>>>>                     Text : String
>>>>                  )  return Item_Ptr;
>>> What I don't see is how you can implement this, never mind any other
>>> problems.
>>
>> A naive, but wrong due to 7.6.1 (11.1/3) nonsense, implementation would be:
>>
>>       function New_Item
>>                (  Pool : in out Root_Storage_Pool'Class;
>>                   Text : String
>>                )  return Item_Ptr is
>>          type Ptr is access Item;
>>          for Ptr'Storage_Pool use Pool;
>>          Object : Ptr := new Item (Text'Length);
>>       begin
>>          Object.Text := Text;
>>          return Object.all'Unchecked_Access;
>>       end New_Item;
> 
> OK, that code compiles.
> 
> What you'd need to happen when the returned Item_Ptr is freed would be
> for the mechanism of the actual pool to be invoked. But Item_Ptr was
> declared without any pool specified, so uses the default, and when the
> returned Item_Ptr is freed it uses the default pool's mechanism.

That would be another language bug, if true, because 13.11.2 is silent 
about that. But the first bug is that New_Item is not implementable, 
well it actually is, but in a very clumsy way (see my answer to Randy).

> But of course what actually happens with this code is that the returned
> Item_Ptr is left dangling; my test
> 
>     with P;
>     with System.Pool_Local;   -- GNAT special
>     with Ada.Text_IO; use Ada.Text_IO;
>     procedure Test is
>        use P;
>        Pool : System.Pool_Local.Unbounded_Reclaim_Pool;
>        Ptr : Item_Ptr := New_Item (Pool, "hello");
>     begin
>        Put_Line (Ptr.Text);
>        Free (Ptr);
>     end Test;
> 
> manages flukily to print "hello" before crashing at the Free (Ptr).

It should print it twice, because Finalize must be called twice. Once 
inside New_Item, then in Free.

> I don't see how what you want can be achieved without every access type
> containing a reference to the pool the object was allocated from.

Yes, every general access type that permits instantiation of 
Unchecked_Dellocation must indicate the target object's pool, directly, 
e.g. per fat pointer, or indirectly by some other schema. I see nothing 
in RM that allows a different implementation. But it is could be a bug 
by omission and I am not a language lawyer anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de