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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: How to get Ada to "cross the chasm"?
Date: Mon, 7 May 2018 18:36:54 -0500
Organization: JSA Research & Innovation
Message-ID: <pcqnun$3sg$1@franka.jacob-sparre.dk>
References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com>
 <effa585e-7f43-44f9-9462-f92bab803119@googlegroups.com>
 <661b1ce8-f4e4-4a4b-9a07-ebe36d75f010@googlegroups.com>
 <pckn7r$too$1@dont-email.me>
Injection-Date: Mon, 7 May 2018 23:36:55 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="3984"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:52076
Date: 2018-05-07T18:36:54-05:00
List-Id: <comp.lang.ada>

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message 
news:pckn7r$too$1@dont-email.me...
> On 04.05.18 21:05, Jere wrote:
>
>> 1.  Dangling references:  Keeping a reference to an object past its 
>> lifetime
>>
>> Ada:
>> ***********************************************
>> with Ada.Text_IO; use Ada.Text_IO;
>>
>> procedure jdoodle is
>>      type Integer_Access is access all Integer;
>>      function Inner(Value : aliased in out Integer) return Integer_Access 
>> is
>>      begin
>>          return Value'Access;
>>      end Inner;
>>      function Outer return Integer_Access is
>>          Value : aliased Integer := 0;
>>      begin
>>          return Inner(Value);

This should be illegal, as it fails an accessibility check. The parameter to 
Inner has to have the same (or longer) accessibility level as the function 
call to Inner, but it doesn't. So this is illegal. You get the same error 
with an allocator:

        Ptr : Integer_Access := new Integer'(Value);

Now, whether your favorite Ada compiler implements this rather obscure check 
properly is another question (it should, there are examples in the ACATS), 
but it's not a language question.

>>      end Outer;
>>      Ptr : Integer_Access := Outer;  -- !!! Dangling reference

Only if Outer was legal, which it is not.

>> begin
>>      Put_Line("Hello World");
>> end jdoodle;
>
> Anything that can be done to prevent the above effect
> should be welcome, if it is representative of what the
> 2012 RM allows. Or is this new *aliased* parameter thing
> some I-know-what-I-am-doing Ada?

Not needed and no. :-)

> So, do explicitly *aliased* parameters indeed break all accessiblity
> rules of Ada?

Surely not. The check moves to the parameter of the call, but it doesn't 
disappear.

>  I noticed that it is mentioned in the RM alongside
> parameters that are passed by reference already because their
> type is a by-reference type. I'd expect then, that one
> would drop *aliased* for those kinds of type, thus
>
>     27. with Ada.Text_IO; use Ada.Text_IO;
>     28.
>     29. procedure jdoodle2 is
>     30.     type T is tagged
>     31.        record
>     32.            Data :  Integer;
>     33.        end record;
>     34.
>     35.     type T_Access is access all T;
>     36.
>     37.     function Inner(Value : in out T) return T_Access is
>     38.     begin
>     39.         return Value'Access;
>                        |
>         >>> non-local pointer cannot point to local object
>
>     40.     end Inner;
>     41.
>     42.     function Outer return T_Access is
>     43.         Value : aliased T := T'(Data => 0);
>     44.     begin
>     45.         return Inner(Value);
>     46.     end Outer;
>     47.
>     48.     Ptr : T_Access := Outer;
>     49. begin
>     50.     Put_Line("Hello World");
>     51. end jdoodle2;
>
>
> The same dangling pointer effect reappears, however, when I put
> *aliased* back, for no apparent reason:
>
>     function Inner(Value : aliased in out T) return T_Access is
>     begin
>         return Value'Access;
>     end Inner;

The accessibility of an explicitly aliased parameter is that of the function 
result. It's specifically intended to make this sort of thing legal (as in 
returning an element of a container). The check moves to the parameter, 
because only at the call site does one know if the accessibility works (see 
the allocator case above).

So Inner is legal, but the call to Inner in Outer is illegal; thus no 
dangling pointer.

                        Randy.