> Even though Ethereal itself sets a bad example in some places,
> you cannot portably copy an array of bytes onto a struct and expect
> a one-to-one correlation. The compiler may not have packed the
> fields in the struct next to each other --- there may be padding
> between fields. The only thing the ANSI C spec guarantees is the
> *order* of the fields in the struct, not their closeness.
Note also that at least some versions of GCC on ARM will, I think, pad
structures to a multiple of 4 bytes in size *even if the structure
doesn't contain any 4-byte integral fields*, so "sizeof (struct)" won't
necessarily reflect the number of bytes a given structure will use in a
packet.
Also, if you do a "tvb_memcpy()" - or a "tvb_get_ptr()" - the dissector
will throw an exception if you don't have at least the specified amount
of data in the packet.
If you can dissect part of the packet without having all that data - for
example, if not all that data would be used to generate the Info field
in the summary - dissecting the header a field at a time, rather than
copying the entire header to a structure and dissecting the fields of
that structure, means that the dissector might be more likely to be able
to provide some useful information about packets even if the capture was
made with a snapshot length too short to capture all of the packet
(e.g., the depressingly low default snapshot length of 68 or so used by
tcpdump).
