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,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/16 Message-ID: <3496D55F.1312429E@ac3i.dseg.ti.com>#1/1 X-Deja-AN: 298781851 Content-Transfer-Encoding: 7bit References: <348F3DFC.10DB@nospam.flash.net> <3490252D.6B550F17@ac3i.dseg.ti.com> Mime-Version: 1.0 Reply-To: johnv@ac3i.dseg.ti.com Content-Type: text/plain; charset=us-ascii Organization: Raytheon TI Systems Newsgroups: comp.lang.ada Date: 1997-12-16T00:00:00+00:00 List-Id: Joe Gwinn wrote: > > 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.) I don't see how this requirement conflicts with the idiom I sketched before (derive a "holey" enumeration type from a parent "contiguous" enumeration type, and rely on Ada type conversions to provide the necessary mapping). Your program only needs to deal with these "secure" but "holey" message id bit patterns at its edges, where it receives and unpacks input messages (whose provenance may be questionable) and where it must pack up and transmit output messages (and establish their provenance). But once you've checked your input messages against whatever security measures you've established (including among other things 'Valid-ating their "holey" message id's) there is hardly any reason for your program to continue using the "holey" representation internally. Particularly if you proceed to use message id's in a lot of for-loops and array-indexes and other such enumerated-type operations that threaten to "blow up" if the type is "holey". If you simply type-convert the "holey" external versions of your message id's into "contiguous" internal versions, right at the point of input, then you incur the cost of the expensive mapping just once, rather than repeatedly throughout your program. The nice thing about this is that you don't have to give up on using your nice enumeration literals -- you only have to give up the *representation*. -- Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Raytheon/TI Advanced C3I Systems, San Jose, CA", Work_Email => "jvolan@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) ");