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

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

Joe Gwinn wrote:
> 
> In article <3496D55F.1312429E@ac3i.dseg.ti.com>, johnv@ac3i.dseg.ti.com wrote:
> 
> > 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)...[snip]
> 
> Well, it depends on where one chooses to put the boundaries between safe
> and unsafe.  Because we choose not to attempt safety validation of VxWorks
> and the various COTS communications systems, an impossible task, every
> VxWorks task stands alone, so safety critical messages between tasks must
> have message type IDs differing in at least 4 bits.  I think this meets
> the definition of holey; in fact, it's more hole than anything else, by
> design.
> 
> So, can one convert to a compact enumeration within those tasks, defining
> the "edges" to be the task boundaries?  

Sure, why not?

> Not really, both by common sense

"Common sense"?  If common sense has anything to do with this, I'm
afraid you aren't very convincing in showing the connection...

> and by a specific contractual safety requirement.  Enumeration types
> within the task are still implemented using physical memory, there being
> no other way, and thus have no more divine protection from bitflips and
> other forms of spoofing then they do outside the tasks.

There must be some limit to this paranoia, else we degenerate into
infinite regress!  I can understand being paranoid about flipped bits in
messages coming in over a network connection, where the communication
line may be held suspect, but to worry about a bit flipping in a
variable in memory while it is being used within a single task on a
single host processor is surely beyond the pale.  One may as well outlaw
the use of standard 2's-complement integers and floats for representing
critical physical quantities, on the grounds that a single bit flip
could suddenly double a quantity, or worse yet, change its sign! We
would also have to preclude the use of standard CPU models with
instruction sets that aren't sufficiently "holey", on the grounds that a
single bit flip could suddently turn, say, a LOAD instruction into a
STORE instruction!

Even putting that aside, let's asume that there is some compelling
reason to keep using a "holey" representation even within a single task
(and let's also assume that your comments are not simply a troll). Then,
as you say:

[snip, fast-forward to the end]

> The
> holes are absolutely required and thus will remain.  Something else will
> be forced to give.

... Of course: You must give up some efficiency.  If one cannot trust an
enumerated value to remain intact from one executable statement to the
next, then one is forced to constantly check and re-check it to make
sure it hasn't gone bad.  Each iteration through a for-loop, each index
into an array, and so forth, must pay the cost of mapping the
representation to the position number (raising Constraint_Error if the
represented value is not 'Valid). In short, you incur the "blow up"
which you previously complained about.  You cannot have it both ways:
You can get speed or you can get safety, but not both at once.

At any rate, what does this have to say about the suitability of an Ada
enumeration type as an abstraction for a "holey" set of bit-patterns? 
If you choose some other data abstraction to implement the bit-patterns,
you will get the same sort of performance, but you will have to do some
programming work to implement the very same mapping operations that the
Ada compiler already provides for a holey enumeration type. Seems like
wrong-headedness leading to wasted effort...

> Because of the need to talk to entities written in languages other than
> Ada95, or in Ada95 but compiled and linked at a different time perhaps
> using a different compiler and compiler version, the specific enumeration
> mapping must be explicitly nailed down, with no discretion left to any of
> the various compilers.  This was the reason for the rep specs.  Now that
> the rep specs are gone, some other equivalent method will be needed.  

Huh? What do you mean?  Last time I checked, rep specs were very much
alive and well in Ada95!  Or do you simply mean that your project has
chosen to give up on using rep specs for some incomprehensible reason
... ? :-)

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