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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c9b7709f7cadc963
X-Google-Attributes: gid103376,public
From: Ken Garlington <kennieg@nospam.flash.net>
Subject: Re: Beware: Rep spec on an enumeration type clause
Date: 1997/12/12
Message-ID: <3491E5F1.44F2@nospam.flash.net>#1/1
X-Deja-AN: 297715858
References: <34911237.81B700D6@iei.pi.cnr.it>
Reply-To: Ken.Garlington@nospam.computer.org
Organization: Flashnet Communications, http://www.flash.net
Newsgroups: comp.lang.ada
Date: 1997-12-12T00:00:00+00:00
List-Id: <comp.lang.ada>


Franco Mazzanti wrote:
> 
> Rakesh Malhotra wrote:
> 
> > We work on safety critical projects.  And if we have a safety critical
> > bit of code that defines and uses an enumeration then we use the rep
> > clause to provide more than 1 bit separation between adjacent values in
> > the enumeration.  That way if 1 bit got corrupted the value could not
> > become some other legal value.
> >

[snip]

> 
> Since the program behaviour when some invalid object is encountered is
> highly
> implementation dependent, this approach seems really dangerous to me ...
> For example, for example, the following program, compiled with GNAT v.3.09
> happily (and legally) produces the output:
> 
> > I is neither AA, BB or CC
> > I is  AA or BB

You may want to look at Dr. Wichmann's implementation of such a "safe"
boolean
type, as described in an issue of Ada Letters some time back. The
difference is
that Safe_Boolean is defined as an abstract data type, and (I recall)
each
access to such an object is checked within the ADT, with an exception
raised
for invalid values. Thus, the "I is AA or BB" would not be reached when
"I" was
a Safe_Boolean type.

Personally, I don't think the added protection for a single data type is
worth
the complexity, particularly given the availability of more
comprehensive hardware-
based approaches to detecting and handling memory faults, but I wouldn't
describe
the approach as either "wrong" or "dangerous," assuming a proper
implementation.

> 
> ------------------------------------------------------------
>    Franco Mazzanti
>    Istituto di Elaborazione della Informazione
>    mazzanti@iei.pi.cnr.it
> ------------------------------------------------------------