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,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: gwinn@res.ray.com (Joe Gwinn) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/12 Message-ID: #1/1 X-Deja-AN: 297706098 References: <348F3DFC.10DB@nospam.flash.net> <3490252D.6B550F17@ac3i.dseg.ti.com> Organization: Raytheon Electronic Systems Newsgroups: comp.lang.ada Date: 1997-12-12T00:00:00+00:00 List-Id: In article <3490252D.6B550F17@ac3i.dseg.ti.com>, johnv@ac3i.dseg.ti.com wrote: > Ken Garlington wrote: [snip] > My feeling is that "holey" enumeration types (like other Chapter 13 > features) should really only be used at the "edges" of a program, > wherever you're immediately reading from or writing to some external > system that is expecting a certain data format. Contiguous enumeration > types should be used internally everywhere else in your program, for all > the efficiency reasons that have been ... enumerated :-) ... in this > thread. Luckily, Ada provides this convenient way of converting between > holey and contiguous representations. I have to disagree somewhat. We were using enumeration types as message type IDs all over the place, not just at the edges. For safety-critical messages, the enumerations are not permitted to be numerically contiguous, being required to differ in at least four bits from all other message type integer codes. This 4-bit requirement is intended to greatly reduce the probability of message spoofing. (I know this isn't by itself sufficient. This isn't the entire defense, only the part relevant to the current issue.) Joe Gwinn