[Guy Harris <gharris@xxxxxxxxx>]

On Mon, Feb 17, 2003 at 08:39:37PM -0500, Craig Rodrigues wrote:
> > The *length* is used?  Not the *offset* of the first byte after the byte
> > order octet?
> > 
> > That's *really* odd.  Are you certain that's the case?
> 
> I'm very certain I know what I am talking about.

Actually, what determines the alignment in the "get_CDR_short()" call in
"decode_RTCorbaPriority()" is the sum of the offset and the length.  If
the length of the sequence is passed, that length is presumably a
multiple of 2 bytes, and thus the length doesn't matter - 0 could also
be passed.

I added a dissector for CodeSet service contexts and, if I passed it the
length of what remains in the sequence, which isn't a multiple of 4
bytes, it gets the alignment wrong.

However, if I pass it the "encapsulation_boundary" result from
"get_CDR_encap_info()", that works.

I've checked in a change to pass that as the boundary argument to
"decode_RTCorbaPriority()" as well.

> The OMG has reserved those VSCID's, but they have only defined
> 16 SCID values for VSCID == 0.  The 16 SCID values which they have
> defined are encapsulated.  However in the future, there is no
> guarantee that new SCID values will be encapsulated.  When new
> SCID values are specified, I don't mind modifying the dissector appropriately.

I've checked in a change to dissect those with a new
"decode_UnencodedServiceContext()" routine, which just shows the
sequence length and the sequence data; for sequence contexts known in
the sense that the vscid is 0 and the scid is < max_service_context_id,
but for which there is not yet a dissector,
"decode_UnknownServiceContext()" is still used, so it at least dissects
the endianness item.