Re: Beware: Rep spec on an enumeration type causes code explosion

["John G. Volan" <johnv@ac3i.dseg.ti.com>]

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? :-) ");