Clean up the handling of parameter sequences - add a bunch of length
checking, give each parameter a protocol tree item with the
ID/length/value under it, and don't format variable-length string
parameters into fixed-length buffers. Use the parameter-sequence
dissector for the ISSUE message.
Use the "number of bits" value when dissecting a bitmap.
svn path=/trunk/; revision=10641
"dissect_rtps()", just in case a message with *no* submessages is sent.
Fetch the flags field in that loop, as we need the E bit value to
determine the byte order of the "next submessage offset" field; fetch
that value in the loop as well, and pass both those values, and the
byte-order flag, to submessage dissector routines as necessary.
Make the main protocol tree item for each submessage cover the entire
submessage; put into that protocol tree an item that covers the
submessage ID, with a named field.
Construct the submessage subtree in that loop, rather than in the
submessage dissectors.
Put into that subtree items for the flags and next submessage offset; we
do that in the submessage dissector, as the interpretation of the bits
in the flags field differs from submessage to submessage.
svn path=/trunk/; revision=10639
Before checking for the "RTPS" tag, make sure we have at least 4 bytes
in the message.
Use "tvb_reported_length()" to get the length of the message, so we
throw an exception on a packet cut short by a snapshot length.
Put in a comment asking whether the byte order of the "offset to next
submessage" field is little-endian or specified by the E bit.
svn path=/trunk/; revision=10636
to remember that at least at one point in the history of C, at least one
compiler required that.
Clean up the byte-order stuff - LITTLE_ENDIAN and BIG_ENDIAN aren't
defined by Ethereal or GLib, so we shouldn't use them (some platforms
might define them, but at least some platforms define them *both* as
non-zero values, so they can't be used as "true or false" values for
"e_bit"), and we don't need to worry about the byte order of the machine
running Ethereal - we should just use Ethereal's standard routines to
fetch little-endian or big-endian values.
Get rid of C++ comments.
svn path=/trunk/; revision=10631
Guy Harris