Re: How to get nice with GNAT?

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 11/23/2014 08:05 PM, brbarkstrom@gmail.com wrote:
> 
> I don't think you'll get a sensible response when you try to set
> Test(OK => True); or Test(OK => False) when the specification of
> the procedure Test has OK as an "out" variable.  It doesn't make 
> sense try to set this value as input to a variable that emerges from the procedure (Test).

I think it's clear you have no idea what you're talking about. I set OK to True
before calling Test so that I could demonstrate that Test did not modify that value.

> The GNAT GPL GPS tool on my Ubuntu 14.04 LTS system returns the
> two warnings:
> 7.10     warning: assignment to pass-by-copy formal may have no effect
> 7.10     warning: "raise" statement may result in abnormal return
>            (RM 6.4.1(17))
> 
> In other words, a programmer shouldn't expect a variable input to
> an "out" variable in the interface specification to have any relation
> to whatever is generated in the procedure that is called.  Secondly,
> an exception raised in the procedure test may result in an abnormal
> return.  This is hardly a clean piece of code. 

This warning is saying that the assignment to the formal parameter OK in Test
(the "pass-by-copy formal") won't do anything because the formal is not copied
back to the actual when the procedure propagates an exception. It has nothing to
do with setting the variable OK to True.

> When I run it, the output from the code does something that seems
> to me to be an abnormal return.  It returns the output "TRUE".

Test does not return True. OK had the value True before the call, and it still
has the value True after the call because the assignment to the formal parameter
OK in True has no effect. This is what I was trying to demonstrate.

>    procedure Test (I       : in     Natural;
>                    OK      :    out Boolean;
>                    Err_Msg :    out Vstring.Bounded_String) is
>       Max_I          : Natural := 10;
>       I_Out_Of_Range : exception;      
>    begin -- Test
>       OK := False;
>       Err_Msg := Vstring.To_Bounded_String("procedure Test was not initialized when this message was created.");
>       if I <= Max_I then
>          OK := True;
>          Err_Msg := Vstring.To_Bounded_String("In procedure Test, I as input : ");
>          Err_Msg := Vstring.Append(Err_Msg, Natural'image(I));
>          Err_Msg := Vstring.Append(Err_Msg, " was less than or equal to ");
>          Err_Msg := Vstring.Append(Err_Msg, Natural'image(Max_I));
>       else
>          raise I_Out_Of_Range;
>       end if;
>    exception
>       when I_Out_Of_Range =>
>          Err_Msg := Vstring.To_Bounded_String("In procedure Test, I as input : ");
>          Err_Msg := Vstring.Append(Err_Msg, Natural'image(I));
>          Err_Msg := Vstring.Append(Err_Msg, " was greater than ");
>          Err_Msg := Vstring.Append(Err_Msg, Natural'image(Max_I));
>          Err_Msg := Vstring.Append(Err_Msg, " which raises the constraint 'I_Out_Of_Range'.");
>       when others =>
>          Err_Msg := Vstring.To_Bounded_String("In procedure Test, something unexpected happened.");
>    end Test;

This procedure never propagates an exception. It returns normally in all cases.
As I said, you are not talking about exceptions in the calling code. You're
talking about returning error codes and checking them after the call. This has
all of the problems with returning error codes known from over 4 decades of
using C. These problems led to the inclusion of exceptions in more modern
languages; writing "C in Ada" is a step backwards.

-- 
Jeff Carter
"I'm particularly glad that these lovely children were
here today to hear that speech. Not only was it authentic
frontier gibberish, it expressed a courage little seen
in this day and age."
Blazing Saddles
88