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,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ca9eef4d5e2078ea
X-Google-Attributes: gid103376,public
From: Rakesh Malhotra <rakesh.malhotra@safetran.com>
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/11
Message-ID: <66po35$1a1$1@gte2.gte.net>#1/1
X-Deja-AN: 297351205
References: <gwinn-0812971210080001@dh5055133.res.ray.com>
 <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com>
X-Priority: 3 (Normal)
Organization: gte.net
X-Auth: UNKNOWN@207.175.180.7
Newsgroups: comp.lang.ada
Date: 1997-12-11T00:00:00+00:00
List-Id: <comp.lang.ada>


Tucker Taft wrote:
> 
> Joe Gwinn (gwinn@res.ray.com) wrote:
> : In article <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>,
> [lots deleted]
> -Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
> Intermetrics, Inc.  Burlington, MA  USA

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.

Hence type SIGNAL_TYPE is (RED, GREEN);
for SIGNAL_TYPE use (RED => 16#00#, GREEN => 16#03#);

So if a signal was supposed to be RED, with just a 1 bit corruption it
could never become GREEN.  Obviously we have these kinds of enum's and
rep clauses all over the code space, and they are used in arrays to
index etc etc.    An even worse example (from the coder's point of view)
is that we create our own BOOLEAN_TYPE with states defined as TRUE_STATE
and FALSE_STATE ; then give both true and false explicit values; and
then test for those in "if" statements etc :)  Pretty horrible eh ?

--
Rakesh.