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,323f382d1271f5b6
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Safety Critical Systems and Ada 95
Date: 1998/06/18
Message-ID: <EACHUS.98Jun18180504@spectre.mitre.org>#1/1
X-Deja-AN: 364001281
References: <485015649wnr@diphi.demon.co.uk>
 <EuEBLM.97x.0.-s@inmet.camb.inmet.com>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1998-06-18T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <EuEBLM.97x.0.-s@inmet.camb.inmet.com> stt@houdini.camb.inmet.com (Tucker Taft) writes:

  > Any restriction whose violation can be detected at compile-time
  > or link-time is treated as an error by the compiler.  It is only
  > restrictions that are undetectable prior to run-time that can
  > result in erroneous execution upon violation.

   I'd like to amplify a bit.  What Tuck says is correct, but
mysterious to people who don't have the full context.  There are
several restrictions which are of great use in a safety context, and
are also useful for performance tuning.  Ada 95 combines these into a
single pragma, even though it is not always possible to detect
violations at compile time.  The easiest example to understand is

     pragma Restrictions(Max_Tasks => 0);

   Annex D requires support of the identifier, but for say Max_Tasks
=> 100, it is impossible to tell whether some programs violate the
restriction at compile time.  However, Annex H at H.4(2) requires that
Max_Tasks of zero be checked at compile or link time.  ("checked prior to
program execution.")

   So pragma Restrictions with some arguments will not be useful for
Annex H purposes.  But the restrictions defined in Annex H can and, if
Annex H is supported, must be checked prior to execution. There are
technically three exceptions: No_Exceptions and hardware signaled
exceptions, No_Recursion, and recursion which can not be detected at
compile time, and No_Reentrancy in a program with multiple tasks.  The
obvious way to avoid those problems is to choose a sensible set of
restrictions.  For example, No_Access_Subprograms and No_Dispatch
should be used with No_Recursion so that all potentially recursive
calls can be checked at compile time, and you can use modular types to
avoid cases where the hardware would signal integer overflow.
--

					Robert I. Eachus

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