Recommendation of safe subset of Ada to use?

Recommendation of safe subset of Ada to use?

[joakimds]

Jere gave the following example in the other thread about how to get Ada across the chasm:

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); 
    end Outer; 
    
    Ptr : Integer_Access := Outer;  -- !!! Dangling reference 
begin 
    Put_Line("Hello World"); 
end jdoodle; 
*********************************************** 
Hello World 

gcc -c jdoodle.adb 
gnatbind -x jdoodle.ali 
gnatlink jdoodle.ali -o jdoodle 

It's a 20 line application that demonstrates a dangling pointer in Ada. That's not supposed to be able to happen unless one goes outside of Ada's type system by using Unchecked_Deallocation, Unchecked_Conversion or System.Address_To_Access_Conversion. I've tried the example with the GNAT compiler and it does not detect the issue. I do not believe this is a GNAT bug. Aliased parameters were part of the solution to be able to safely reference elements in containers and thereby avoid unnecessary copying. By making this possible was a hole in Adas type system introduced? It means that one cannot safely use all the features of Ada and be sure of memory safety instead one should stick to a subset of Ada. One subset that comes to mind is SPARK. Another is for example sticking to Ada95 or Ada 2005. Or maybe one should just ban usage of aliased parameters but then what should one do with the standard containers that one probably uses throughout one's application. I am confused. Anybody that can shed light?

/Joakim

Re: Recommendation of safe subset of Ada to use?

[gorgelo]

G.B. wrote in the other thread the following on this topic:

> 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); 
>      end Outer; 
>       
>      Ptr : Integer_Access := Outer;  -- !!! Dangling reference 
> 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? 

So, do explicitly *aliased* parameters indeed break all accessiblity 
rules of Ada?  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; 

Re: Recommendation of safe subset of Ada to use?

[Jeffrey R. Carter]

On 05/05/2018 11:32 PM, gorgelo@hotmail.com wrote:
>> 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);
>>       end Outer;
>>        
>>       Ptr : Integer_Access := Outer;  -- !!! Dangling reference
>> begin
>>       Put_Line("Hello World");
>> end jdoodle;

This seems to violate ARM 3.10.2(29): the accessibility level of Value (the 
object passed by reference to Inner) is deeper than that of the access type 
Integer_Access. I cannot find an exception to this for aliased parameters.

-- 
Jeff Carter
"It is the German who is so uncourteous to his verbs."
A Scandal in Bohemia
122

Re: Recommendation of safe subset of Ada to use?

[Niklas Holsti]

On 18-05-06 10:43 , Jeffrey R. Carter wrote:
> On 05/05/2018 11:32 PM, gorgelo@hotmail.com wrote:
>>> 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);
>>>       end Outer;
>>>              Ptr : Integer_Access := Outer;  -- !!! Dangling reference
>>> begin
>>>       Put_Line("Hello World");
>>> end jdoodle;
>
> This seems to violate ARM 3.10.2(29): the accessibility level of Value
> (the object passed by reference to Inner) is deeper than that of the
> access type Integer_Access. I cannot find an exception to this for
> aliased parameters.

My GNAT complains:

    > gcc -c -g -gnat12 jdoodle.adb
    jdoodle.adb:8:16: non-local pointer cannot point to local object
    gnatmake: "jdoodle.adb" compilation error

However, this is GNAT GPL 2012 (don't ask me why I still use this...)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Recommendation of safe subset of Ada to use?

[gorgelo]

Thanks for the feedback. I have reported the issue to AdaCore.

Re: Recommendation of safe subset of Ada to use?

[Jere]

On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote:
> On 05/05/2018 11:32 PM, gorgelo wrote:
> >> 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);
> >>       end Outer;
> >>        
> >>       Ptr : Integer_Access := Outer;  -- !!! Dangling reference
> >> begin
> >>       Put_Line("Hello World");
> >> end jdoodle;
> 
> This seems to violate ARM 3.10.2(29): the accessibility level of Value (the 
> object passed by reference to Inner) is deeper than that of the access type 
> Integer_Access. I cannot find an exception to this for aliased parameters.
> 
> -- 
> Jeff Carter
> "It is the German who is so uncourteous to his verbs."
> A Scandal in Bohemia
> 122

How would you interpret 3.10.2 (7/4)?  It just says it doesn't have the same
accessibility level as the master.  I haven't found anything to suggest
what the accessibility level should be at that point.  I'll admit, I 
haven't grasped what the full meaning is.

3.10.2 (7/4):
An entity or view defined by a declaration and created as part of its 
elaboration has the same accessibility level as the innermost master of the 
declaration except in the cases of renaming and derived access types described 
below. Other than for an explicitly aliased parameter of a function or generic 
function, a formal parameter of a callable entity has the same accessibility 
level as the master representing the invocation of the entity. 

The other question is what is the purpose of the aliased keyword for
function parameters?  My impression from reading emails here and some
of the rationale was that it was so they could more easily take
access values from containers.  3.10.2(29) would seem to go against that
since most access types are defined at library level and a lot of containers
are declared inside of some function whether that be main (they don't have
to be I know, they can be declared at library level as well).

Re: Recommendation of safe subset of Ada to use?

[Jere]

On Sunday, May 6, 2018 at 9:15:42 AM UTC-4, Jere wrote:
> On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote:
> > On 05/05/2018 11:32 PM, gorgelo wrote:
> > >> 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);
> > >>       end Outer;
> > >>        
> > >>       Ptr : Integer_Access := Outer;  -- !!! Dangling reference
> > >> begin
> > >>       Put_Line("Hello World");
> > >> end jdoodle;
> > 
> > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the 
> > object passed by reference to Inner) is deeper than that of the access type 
> > Integer_Access. I cannot find an exception to this for aliased parameters.
> > 
> > -- 
> > Jeff Carter
> > "It is the German who is so uncourteous to his verbs."
> > A Scandal in Bohemia
> > 122
> 
> How would you interpret 3.10.2 (7/4)?  It just says it doesn't have the same
> accessibility level as the master.  I haven't found anything to suggest
> what the accessibility level should be at that point.  I'll admit, I 
> haven't grasped what the full meaning is.

Trying to piece this together from the RM:

6.4.1 (6.4/3):
In a function call, the accessibility level of the actual object for each 
explicitly aliased parameter shall not be statically deeper than the 
accessibility level of the master of the call (see 3.10.2).

The only reference to how the accessibility level of the master was 
determined that I could fine was in 
6.10.2 (10.1/3):
10.1/3
The accessibility level of the result of a function call is that of the master 
of the function call, which is determined by the point of call as follows:
10.2/3
If the result is used (in its entirety) to directly initialize part of an object, 
the master is that of the object being initialized. In the case where the initialized 
object is a coextension (see below) that becomes a coextension of another object, 
the master is that of the eventual object to which the coextension will be transferred.
10.3/3
If the result is of an anonymous access type and is the operand of an explicit 
conversion, the master is that of the target type of the conversion;
10.4/3
If the result is of an anonymous access type and defines an access discriminant, 
the master is the same as that for an object created by an anonymous allocator 
that defines an access discriminant (even if the access result is of an 
access-to-subprogram type).
10.5/3
If the call itself defines the result of a function to which one of the above 
rules applies, these rules are applied recursively;
10.6/3
In other cases, the master of the call is that of the innermost master that 
evaluates the function call.

I know this is meant to define the level for the result, but it also is the
only part that I could find that defines the level of the master of the call.
Here it would seem that 10.6/3 would apply?

Reading the RM is rough! Any help out there?

Re: Recommendation of safe subset of Ada to use?

[Brad Moore]

On Sunday, May 6, 2018 at 7:48:02 AM UTC-6, Jere wrote:
> On Sunday, May 6, 2018 at 9:15:42 AM UTC-4, Jere wrote:
> > On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote:
> > > On 05/05/2018 11:32 PM, gorgelo wrote:
> > > >> 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);
> > > >>       end Outer;
> > > >>        
> > > >>       Ptr : Integer_Access := Outer;  -- !!! Dangling reference
> > > >> begin
> > > >>       Put_Line("Hello World");
> > > >> end jdoodle;
> > > 
> > > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the 
> > > object passed by reference to Inner) is deeper than that of the access type 
> > > Integer_Access. I cannot find an exception to this for aliased parameters.
> > > 
> > > -- 
> > > Jeff Carter
> > > "It is the German who is so uncourteous to his verbs."
> > > A Scandal in Bohemia
> > > 122
> > 
> > How would you interpret 3.10.2 (7/4)?  It just says it doesn't have the same
> > accessibility level as the master.  I haven't found anything to suggest
> > what the accessibility level should be at that point.  I'll admit, I 
> > haven't grasped what the full meaning is.
> 
> Trying to piece this together from the RM:
> 
> 6.4.1 (6.4/3):
> In a function call, the accessibility level of the actual object for each 
> explicitly aliased parameter shall not be statically deeper than the 
> accessibility level of the master of the call (see 3.10.2).
> 
> The only reference to how the accessibility level of the master was 
> determined that I could fine was in 
> 6.10.2 (10.1/3):
> 10.1/3
> The accessibility level of the result of a function call is that of the master 
> of the function call, which is determined by the point of call as follows:
> 10.2/3
> If the result is used (in its entirety) to directly initialize part of an object, 
> the master is that of the object being initialized. In the case where the initialized 
> object is a coextension (see below) that becomes a coextension of another object, 
> the master is that of the eventual object to which the coextension will be transferred.
> 10.3/3
> If the result is of an anonymous access type and is the operand of an explicit 
> conversion, the master is that of the target type of the conversion;
> 10.4/3
> If the result is of an anonymous access type and defines an access discriminant, 
> the master is the same as that for an object created by an anonymous allocator 
> that defines an access discriminant (even if the access result is of an 
> access-to-subprogram type).
> 10.5/3
> If the call itself defines the result of a function to which one of the above 
> rules applies, these rules are applied recursively;
> 10.6/3
> In other cases, the master of the call is that of the innermost master that 
> evaluates the function call.
> 
> I know this is meant to define the level for the result, but it also is the
> only part that I could find that defines the level of the master of the call.
> Here it would seem that 10.6/3 would apply?
> 
> Reading the RM is rough! Any help out there?

It's rough where you are looking. But I think you should be looking more at 3.10.2, as that is where the accessibility rules are defined, and its not going to get any less rough over there either. 

But before you do that, you might want to read this quote from the AARM. 

See 3.10.2 (3.b/3)

Subclause 3.10.2, home of the accessibility rules, is informally known as the “Heart of Darkness” amongst the maintainers of Ada. Woe unto all who enter here (well, at least unto anyone that needs to understand any of these rules)." 

This is because, probably only a very small handful of people on this planet actually truly understand the rules. I am not one of those, though I try my best, when I need to. And those that do, it is only for a fleeting moment. It typically requires a deep dive into the Heart of Darkness. If you reach enlightenment, consider yourself lucky. Randy would be one of the lucky people, but even he will avoid diving into the Heart of Darkness if he doesn't need to :-)  

I think one of the main advantages of the aliased keyword on subprogram parameters, is that it means there is much less need to use access types.

You can now, for the most part, keep access types hidden in the private part or body of a package, and not expose access types in the public part of the package specification. Users of a package do not have to deal with access types, when this design convention is in place. I think it is a good design principle to strive to not expose access types in the public part of a package.

With earlier versions of Ada, it was much harder to avoid doing this.

That is largely the case with the containers. The users of the container packages normally shouldn't need to mess with access types. 

Also, offhand, I think the problem originally posted above is a compiler bug, that should be fixed. 

Brad

Re: Recommendation of safe subset of Ada to use?

[onox]

On Saturday, May 5, 2018 at 11:23:04 PM UTC+2, joak...@kth.se wrote:
> Jere gave the following example in the other thread about how to get Ada across the chasm:
> 
> 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); 
>     end Outer; 
>     
>     Ptr : Integer_Access := Outer;  -- !!! Dangling reference 
> begin 
>     Put_Line("Hello World"); 
> end jdoodle; 
> *********************************************** 
> Hello World 
> 
> gcc -c jdoodle.adb 
> gnatbind -x jdoodle.ali 
> gnatlink jdoodle.ali -o jdoodle 
> 
> It's a 20 line application that demonstrates a dangling pointer in Ada. That's not supposed to be able to happen unless one goes outside of Ada's type system by using Unchecked_Deallocation, Unchecked_Conversion or System.Address_To_Access_Conversion. I've tried the example with the GNAT compiler and it does not detect the issue. I do not believe this is a GNAT bug. Aliased parameters were part of the solution to be able to safely reference elements in containers and thereby avoid unnecessary copying. By making this possible was a hole in Adas type system introduced? It means that one cannot safely use all the features of Ada and be sure of memory safety instead one should stick to a subset of Ada. One subset that comes to mind is SPARK. Another is for example sticking to Ada95 or Ada 2005. Or maybe one should just ban usage of aliased parameters but then what should one do with the standard containers that one probably uses throughout one's application. I am confused. Anybody that can shed light?
> 
> /Joakim

A similar problem happens with anonymous access procedures (GNAT 7.2):

with Ada.Text_IO;

procedure A is
   type Proc_Access is access procedure (P1 : Integer);

   function Inner (Value : access procedure (P2 : Integer)) return Proc_Access is
   begin
      return Value;
   end Inner;

   function Outer (X : Integer) return Proc_Access is
      use Ada.Text_IO;

      procedure Value (Y : Integer) is
      begin
         Put_Line ("X: " & X'Image);  --  random
         Put_Line ("Y: " & Y'Image);  --  2
      end Value;
   begin
      return Inner (Value'Access);
   end Outer;

   Ptr : Proc_Access := Outer (1);
begin
   Ptr (2);
end A;

Re: Recommendation of safe subset of Ada to use?

[Randy Brukardt]

<joakimds@kth.se> wrote in message 
news:9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com...
> I do not believe this is a GNAT bug.

This is definitely a GNAT bug, if it really does allow this program. This is 
definitely not allowed by the accessibility rules. See my other messages on 
it.

                  Randy. 

Re: Recommendation of safe subset of Ada to use?

[Randy Brukardt]

"Brad Moore" <bmoore.ada@gmail.com> wrote in message 
news:6e66aa5f-9ce0-4f28-ae1b-9bdfeb500a79@googlegroups.com...
...
>See 3.10.2 (3.b/3)
>
>Subclause 3.10.2, home of the accessibility rules, is informally known as
>the "Heart of Darkness" amongst the maintainers of Ada. Woe unto all
>who enter here (well, at least unto anyone that needs to understand any
>of these rules)."
>
>This is because, probably only a very small handful of people on this 
>planet
>actually truly understand the rules. I am not one of those, though I try my
>best, when I need to. And those that do, it is only for a fleeting moment. 
>It
>typically requires a deep dive into the Heart of Darkness. If you reach
>enlightenment, consider yourself lucky.

...and you ought to immediately join the ARG to help the rest of us out... 
;-)

>Randy would be one of the lucky people, but even he will avoid diving into
>the Heart of Darkness if he doesn't need to :-)

Thanks, I think. ;-)

In this particular case, I know the intent because I ended up designing this 
feature. I was able to explain it to Tucker well enough that he agreed that 
the rules were right and sufficient. But whether the wording actually says 
what was meant is hardly known.

The intent for explicitly aliased function parameters is that the 
accessibility check moves to the call. (Note that that doesn't happen for 
procedures, because there's no return object and no return accessibility.) 
So that object has to live longer than the function result; the call to 
Inner in this example doesn't do that and thus it is illegal.

Note that examples of this case were included in ACATS test B641002, 
including one that looks nearly identical to the OP's example. That was 
issued in March 2014, so it's quite possible for older compilers to not make 
the check. If a new compiler doesn't make the check, definitely complain to 
your vendor and tell 'em I sent you. :-)

                        Randy.

Re: Recommendation of safe subset of Ada to use?

[Randy Brukardt]

"onox" <denkpadje@gmail.com> wrote in message 
news:3d48e916-7ec1-4e01-9a9d-1d8c3c81061f@googlegroups.com...
...
>   function Inner (Value : access procedure (P2 : Integer)) return 
> Proc_Access is
>   begin
>      return Value;
>   end Inner;

I believe this is outright illegal; the accessibility of an anonymous 
access-to-subprogram is "infinite", and the accessibility of Proc_Access is 
not, so it is not allowed. There's not supposed to be any legal conversion 
to "regular" access-to-subprogram types.

Again, if allowed, report it as a bug.

                 Randy.

Re: Recommendation of safe subset of Ada to use?

[Simon Wright]

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

> Note that examples of this case were included in ACATS test B641002,
> including one that looks nearly identical to the OP's example. That
> was issued in March 2014, so it's quite possible for older compilers
> to not make the check. If a new compiler doesn't make the check,
> definitely complain to your vendor and tell 'em I sent you. :-)

GNAT GPL >= 2015, FSF GCC >= 5 all refuse to compile that test: 23
errors each of which is marked in the source as expected.