jm@bbn.com (John Morrison) (05/31/89)
In a bit of communications software, we may need to nest variant
records. Has anybody gotten this to work? It seems that our system
(we're on an R1000) insists that the inner variant record must be
constrained. If you ask me, that's not much of a variant record.
This has been so nasty, that we are now wondering if we're not looking
at the problem incorrectly. In other words, are variant records the
right (only?) way to do packet i/o? Anybody else had this problem?
It would crop up in the IP layer of the DoD protocol stack if you were
doing 802.3 link-layer with at least one other protocol stack as well.
The first discriminant would be the 802.3 length (HA!) field, and the
second would be IP protocol field.
John Morrison
ARPANET:jmorrison@bbn.com
PHONE :(617) 873-2648
ADDRESS:BBN Systems & Technologies Corp.
10 Moulton Street
Cambridge, Mass.
02238stt@inmet (06/01/89)
A nested variant record need not be constrained
if defaults are provided for the discriminants
when the nested record type is defined.
However, this will generally leave room for the
maximum possible instance.
Otherwise, the discriminant of a nested record
must be predefined, or the same as one of the
discriminants of the enclosing record type.
For example:
type rec(d : boolean := false) is record ... end record;
type bigrec(a : integer; b : boolean) is record
case a is
when 1 =>
r : rec(b); -- discrim same as one of encloser
when 2 =>
s : rec; -- discrims have defaults,
-- this will normally be "max-size"
when 3 =>
t : rec(g(5)>h(3); -- discrim calculated once,
-- used for all instances of bigrec
when others =>
null;
end case;
end record;
Alternative approaches generally involve using arrays of bytes,
or even bits, and doing your own layout, perhaps including
unchecked conversions to/from access types if you know
what you are doing.
Generally, relying on variant records, nested or otherwise,
to have a specific bit layout is "iffy" at best, since
there are frequently "hidden" fields added into the
record, depending on the particular compiler.
These hidden fields may be "dope" for nested arrays,
self-relative offsets to nested dynamic-length components,
discriminants of nested records (these aren't really "hidden"
but are sometimes unexpected), etc. Record rep clauses
can sometimes overcome these difficulties, but this whole
area of hidden fields is compiler-dependent.
Hence, controlling your own destiny via an array of bytes/bits
is probably the safest and most portable across compilers.
S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA 02138