comp.lang.ada
 help / color / mirror / Atom feed
* nested variant records query
@ 1989-05-31  2:15 John Morrison
  1989-06-01  8:45 ` stt
  0 siblings, 1 reply; 2+ messages in thread
From: John Morrison @ 1989-05-31  2:15 UTC (permalink / raw)



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.
        02238

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: nested variant records query
  1989-05-31  2:15 nested variant records query John Morrison
@ 1989-06-01  8:45 ` stt
  0 siblings, 0 replies; 2+ messages in thread
From: stt @ 1989-06-01  8:45 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1989-06-01  8:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-05-31  2:15 nested variant records query John Morrison
1989-06-01  8:45 ` stt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox