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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.231.113 with SMTP id k107mr26540158yhq.57.1416923145265; Tue, 25 Nov 2014 05:45:45 -0800 (PST) X-Received: by 10.140.93.106 with SMTP id c97mr176qge.41.1416923145247; Tue, 25 Nov 2014 05:45:45 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!s7no1764859qap.1!news-out.google.com!w7ni50qay.0!nntp.google.com!w8no2258743qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 25 Nov 2014 05:45:45 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.111.125.244; posting-account=Ies7ywoAAACcdHZMiIRy0M84lcJvfxwg NNTP-Posting-Host: 50.111.125.244 References: <0d8452a9-68c9-4835-b6f3-17407132ca9f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8194a204-7b15-463d-a2fd-4d3ba342fe97@googlegroups.com> Subject: Re: How to get nice with GNAT? From: brbarkstrom@gmail.com Injection-Date: Tue, 25 Nov 2014 13:45:45 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 5772 X-Received-Body-CRC: 3888770096 Xref: news.eternal-september.org comp.lang.ada:23710 Date: 2014-11-25T05:45:45-08:00 List-Id: 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.