Re: Variant Record Component

[John Harbaugh <john.s.harbaugh2@boeing.com>]

Freezing rules are defined in ARM 13.14.  In short, freezing is the
point either in compilation or elaboration at which the memory structure
of an entity must be fixed.  Because of these rules, the following
representation clause is illegal:

   type Byte is mod 2**8;
   
   subtype Nibble is Byte range 0..2*4;
   for Nibble'Size use 4;

In the case of the variant record in question, the record type does not
have a defaulted discriminant (a definite type).  When a record object
is declared, a discriminant value must be supplied (a constrained
object), at which point the structure of the object is "frozen" at
compile time.  If, on the other hand, the record type had a default
expression for the discriminant (an indefinite type) and the object
declaration did not override the default (an unconstrained object), then
freezing would also occur at runtime, because the structure could change
(through whole-value assignment).  Variant records a are a little subtle
in this regard.

You are correct, the field "b" may not exist, in which case a
Constraint_Error is raised when the nonexistent field is referenced.

So, I guess it really is unnecessary to have a language feature to test
the structure.  One can simply test the discriminant.  In this
particular case, I would still advocate for re-factoring the routine
because it is obscenely big, but that's another issue.

Cheers,

	- John

> Constraint_Error because of errors in the data (a field is out of range,
> for instance), or because the program referenced msg.b when the
> discriminant/case statement said there was no field "b"?  In the latter
> case, it sounds like the symptom is the attempt to reference msg.b, but the
> problem is erroneously thinking this message is of the subtype with a "b".