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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8a4455177648cb9e
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Idea: Array Boundary Checks on Write Access Only
Date: 1998/06/20
Message-ID: <EACHUS.98Jun19200052@spectre.mitre.org>#1/1
X-Deja-AN: 364349862
References: <35851B64.5BF271C4@cl.cam.ac.uk> <6m8v02$r2l$1@xenon.inbe.net>
 <3588D738.4BB32E5A@cl.cam.ac.uk> <6me766$l4t$1@xenon.inbe.net>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1998-06-20T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <6me766$l4t$1@xenon.inbe.net> Lieven Marchand <mal@bewoner.dma.be> writes:

  > One of the problems in doing this with Ada is that the language spec
  > describes the exact behaviour for errors like this. You have to raise
  > the correct exception after having done all the previous effects. This
  > restricts the freedom of the compiler to rearrange checks. In
  > languages with similar semantics for arrays like Modula-3 the only
  > behaviour prescribed is that it is a checked runtime error with leaves
  > the implementation with much more freedom...

   Sounds like Ada 83, not Ada 95.  From a user point of view, 11.6 is
a lot more strict in Ada 95 about the semantics of programs which do
not raise a predefined exception (in practice, Constraint_Error) and a
lot less strict about programs which do.  The intent is that when
Constraint_Error occurs, the only thing you know in the handler is
that it was raised by code in the scope of the handler.  Basically,
all variables potentially assigned to in that scope can become
"abnormal", and references to them erroneous.

   It does mean that you need to do a lot more work if you actually
intend to recover from a particular arithmetic overflow, but unless
you wrapped every arithmetic operation in the scope in a separate
handler in Ada 83, you were in basically the same boat.

   For example:

     begin
       for I in Some_Range loop
         A(I) := B(I) + C(I);
       end loop;
     exception
       when Constraint_Error => ...;
       -- I and all elements of A should be treated as bogus.
     end;

   To find where the error occurs you need to write:

     begin
       for I in Some_Range loop
         begin
           A(I) := B(I) + C(I);
         exception
           when Constraint_Error => ...;
           -- I can be trusted
         end;    
       end loop;
     exception
       when Constraint_Error => ...;
       -- Absent a raise, A is okay here, but I is not.
     end;
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...