Re: Containers, dangling references

[Simon Wright <simon@pushface.org>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lya74pbhro.fsf@pushface.org...
> ...
>> with implementation
>>
>>   function Reference (C : aliased in out Container; Position : in Cursor)
>>                      return Reference_Type
>>   is
>>      pragma Unreferenced (C);
>>   begin
>>      return (Element => Position.The_Node.all.The_Element'Access, Dummy => 
>> 1);
>>   end Reference;
>
> The language rules are designed to allow returning part of an aliased
> parameter as the return from a function. But one could also return a
> part of the designated object of a library-level access type.

Is there any difference between an ordinary return & an extended return?
Looking at AARM 6.5(5.8/3), I think not?

> Thus, what matters here is the type declaration of "The_Node", which
> would need to be a library-level access type (or at least
> instance-level) in order of this to work.

There are all at library level.

   type Node_Type is limited record
      The_Element : aliased Element_Type;
   end record;
   type Node_Access is access Node_Type;

   type Container is tagged record
      A_Node : Node_Access;
   end record;
   type Container_Access is access all Container;

   type Cursor is record
      The_Container : Container_Access;
      The_Node : Node_Access;
   end record;

> I note this implementation is missing the check that the cursor is for
> an element in the provided container (and isn't null). Perhaps you
> simplified the implementation for this presentation.

A mixture of this and an incomplete original implementation.

> This sort of expression is a tough one to deal with for
> compilers. Janus/Ada used to (and maybe still does :-) have problems
> with the accessibility of expressions that have multiple access
> types. It would use the wrong type to determine the
> accessibility. Perhaps something similar is happening for GNAT. It's
> also suspicious that the explicit .all changes the result from the
> implicit .all. That suggests a bug more than an intended
> implementation.

That's what I thought.