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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9da298537a16487e
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-01-12 07:54:26 PST
Path: 
 nntp.gmd.de!Germany.EU.net!wizard.pn.com!satisfied.elf.com!news.mathworks.com!hookup!olivea!uunet!newsgate.watson.ibm.com!watnews.watson.ibm.com!karthurs
From: karthurs@vnet.ibm.com (Keith Arthurs)
Newsgroups: comp.lang.ada
Subject: Re: Run-time checking and speed
Date: Thu, 12 Jan 1995 15:54:26 GMT
Organization: McDonnell Douglas Corporation
Message-ID: <19950112.105426.553@vnet.ibm.com>
Reply-To: karthurs@vnet.ibm.com (Keith Arthurs)
NNTP-Posting-Host: wmavm7.gburg.ibm.com
Date: 1995-01-12T15:54:26+00:00
List-Id: <comp.lang.ada>


In article <3ev16u$ojc@pong.lasc.lockheed.com>,
 on 10 Jan 1995 22:20:14 GMT,
 Tony Leavitt <tony@deepthought.Sgi.COM> writes:
>I have a question about developing Ada code that still has all of
>its normal run-time checking and is "fast."  Is there an execution
>difference with repsect to run-time checking in any of the following.
>Or, is there "a good real-time style" for this type of stuff?
>
>
>-- CASE 1
>-- This case seems to need all of the full run-time checking since
>-- the variables x and y can be unlimited when accessing the array.
>
>XY_array : array (integer range 1..100, integer range 1..100) of float ;
>
>for x in 1..100 loop
>  for y in 1..100 loop
>     XY_array(x,y) := calc_something  ;
>   end loop ;
>end loop ;
>

  In the above case, the compiler may be smart enough to optimize out the
index range check since the loops are hardcoded within a valid range.  But
I'm assuming you're more interested in what happens when you index an array
using a variable that has a larger range constraint than the array index
constraint.  In this case all compilers should perform an index constraint
check.

>
>
>-- CASE 2
>-- This case it seems that no runtime checking is needed when
>-- accessing the array since x and y are, by definition, within
>-- the array bounds (assuming memory doesn't go bad while running).
>
>subtype arraybounds is integer range 1..100 ;
>
>XY_array : array (arraybounds, arraybounds) of float ;
>
>for x in arraybounds loop
>  for y in arraybounds loop
>     XY_array(x,y) := calc_something  ;
>   end loop ;
>end loop ;
>
>

  In this case, or cases where you are indexing an array using a variable of
the same constraints as the array bounds, some compilers will optimize out
the constraint check.  I have a problem with this type of optimization
because I have seen two types of cases where this can cause problems.

problem case 1:

 x, y : boolean;  -- UNINITIALIZED!!!! The variables could be out of range!

 ...
 x := y;
 if x=TRUE then
   text_io.put_line("TRUE");
 elsif x=FALSE then
   text_io.put_line("FALSE");
 else
   text_io.put_line("x is neither TRUE nor FALSE!"); -- Shouldn't happen,
                                                     -- but does!
 end if;

In this case, there is no range check on the assignment of x with the
uninitialized value in y.  If y was out of range of FALSE..TRUE, then
the third case of the if would be executed, with no constraint_errors
being raised.


Problem case 2:

  function get_element (x : index_t) return element_t is
  begin
    return (element_array (x));
  end get_element;

  In this case, element_array has the index constraints of index_t, so no
range check is performed.  If the function is called with an uninitialized
variable, anything could happen.  I've seen this core dump!  Not a very
graceful way for an Ada program to terminate.  Also not a very safe
behaviour for safety critical software that contains exception handlers to
prevent the program from terminating.


Keith Arthurs
Software Engineer Specialist - McDonnell Douglas Corporation

/home/karthurs => cd /usr/bin/standard/disclaimer
/usr/bin/standard/disclaimer => grep "nions" *
The opinions expressed here do not reflect those of MDC.
then proceed to dice the onions into little pieces and
/usr/bin/standard/disclaimer =>