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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f51e93dacd9c7fca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-22 15:05:46 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: rieachus@attbi.com (Robert I. Eachus) Newsgroups: comp.lang.ada Subject: Re: status of Ada STL? Date: 22 Jun 2002 15:05:45 -0700 Organization: http://groups.google.com/ Message-ID: <45fd8ad1.0206221405.45dda96a@posting.google.com> References: <3d0ce154_5@news.bluewin.ch> <3D10B7C6.8030309@attbi.com> NNTP-Posting-Host: 24.61.239.24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1024783546 22710 127.0.0.1 (22 Jun 2002 22:05:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 22 Jun 2002 22:05:46 GMT Xref: archiver1.google.com comp.lang.ada:26610 Date: 2002-06-22T22:05:46+00:00 List-Id: Robert A Duff wrote in message news:... > That was true in Ada 83, but the rules in Ada 95 are much more lax. > As I read 11.6(6), if you have this: > > X := Matrix_Multiply(Y, Z); > > if some operation inside Matrix_Multiply overflows, then X can indeed be > destroyed. In RM terms, X can become "abnormal", which means merely > looking at it can cause you to turn into stone. The wording is very subtle, look at it again. But the real meaning is simple. The call to Matrix_Multiply(Y,Z) is not allowed to destroy X, unless Matrix_Multiply is declared with pragma Inline, and does not include an exception handler. The handler doesn't need to do anything really, it is a signal that the code from the inlined call cannot be mixed with the surrounding code. IF the call to Matrix_Multiply is not safe in this way, you can write: A := 1.0; begin X := Matrix_Multiply(Y, Z); exception when others => raise; end; B := 2.0; to protect A and B. If you want to protect X from an exception during the call as well, what do you write? A := 1.0; declare Temp: Matrix := X; begin begin Temp := Matrix_Multiply(Y, Z); exception when others => raise; end; end; B := 2.0; And you have made the requirement for a temporary variable explicit. Of course, in practice you would either declare a "wrapper" function for Matrix_Multiply or fix the original in-lined version if this was a problem. > 11.6 is very subtle, and I'm not sure I fully understand it, and I'm > sure I don't like it. ;-) I think the moral of the 11.6 story is, > "don't handle predefined exceptions". > > The changes to 11.6 were deliberate. The purpose was to allow more > optimizations, e.g. on some modern machines where exceptions don't > get noticed until long after they have occurred. I can assure that everyone on the ARG agrees on the don't like it part. In fact the section number was carefully preserved so that we could continue to use 11.6 as a swear word. (Or is that swear number?) As for normal programmers, there are only three rules to remember: If you have an Constraint_Error handler, it should make no assumptions about variable that may have been assigned to within the direct scope of the handler. If you write a library, any inlined operations should have local exception handlers if Constraint_Error within the subprogram is a concern. Use 'Valid to avoid problems when validating input data.