Re: How to get nice with GNAT?

[brbarkstrom@gmail.com]

On Monday, November 24, 2014 12:42:23 PM UTC-5, Dennis Lee Bieber wrote:
> On Sun, 23 Nov 2014 19:05:18 -0800 (PST), brbarkstrom declaimed
> the following:
> 
> 
> >
> >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. 
> >
> >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".
> >The output claims that "the process terminated successfully, ...".  
> >It certainly isn't the expected behavior in a reasonable reading of the 
> >procedure text.  Rather it suggests that the compiler completely ignored
> >whatever went on in the procedure.
> >
> 
> 	I would interpret it to mean that the raise statement aborted the
> function "test" before the copying of the "FALSE" value into the return
> structure on the stack, so the main procedure never sees the value change.
> 
> 	If scalar's are handled as locals that are copied from the passed
> parameters on input and then copied back upon (normal) exit -- this makes
> sense.
> 
> 	The last paragraph of the (2005) Reference Manual, section 6.4.1
> Parameter Associations reads:
> 
> After normal completion and leaving of a subprogram, for each IN OUT or OUT
> parameter that is passed by copy, the value of the formal parameter is
> converted to the subtype of the variable given as the actual parameter and
> assigned to it.
> 
> 	Note that: "after normal completion and leaving ... and assigned to
> it".
> 
> 	The raise is not "normal completion", and thereby may not perform the
> "assign".
> -- 
> 	Wulfraed                 Dennis Lee Bieber         AF6VN

If an exception is raised, section 11.4 of the RM comes into play.  11.4(1)
says that when an exception is raised, normal program execution is abandoned
and control is transferred to an applicable exception handler, if any.  Note
also section 11.4(7) which allows an exception handler to carry on assigning
variables, including ones that can be passed out.  When the exception handler
works, it lowers the exception and prevents propagation to the calling
procedure.  Thus, it is perfectly acceptable for the handler to assign
an "out" variable, which will be passed out.

In other words,

1) No exception is raised: pass-by-copy variables appear in the calling
procedure with the last value assigned before the called procedure exits;
there is no exception propagated back to the caller.

2) An exception is raised without an exception handler in the called procedure:
the exception is propagated back to the caller.  I believe a pass-by-copy
parameter that is an "out" parameter in the interface propagates out to the
caller with the last assigned value.

3) An exception is raised with an exception handler in the called procedure:
the exception is lowered and not propagated to the caller.  The exception
handling code can assign a legal value to an "out" parameter and it will appear
in the calling procedure with that value.

4) An exception is raised with an exception handler in the called procedure,
but the exception handler contains a raise; statement: the exception is reraised
and will be propagated back to the caller.  The exception handling code can
assign a legal value to an "out" parameter before the exception is re-raised,
in which case the new assignment will appear in the calling procedure.

5) The Exceptions Package of part 11.4.1 offers ready-made functions 
and procedures that can reduce programming effort.

These behaviors are consistent with what I've observed in the execution of the
compiled versions of the code I provided in previous posts.  I think the only
question about whether different compilers would implement this behavior is
item 2), although I have not been able to find a clear statement in RM as
to whether not passing back a pass-by-copy value is left to the implementer
in the event of the exception being raised.

Bruce B.