Re: proto_tree_add_item() calls where length doesn't match type of hf item

[Martin Mathieson via Wireshark-dev <wireshark-dev () wireshark org>]

Yes, I thought I might see some cases where the field was longer than most
usages, because at least 1 usage required the full size, but in my limited
checking didn't see this.  This probably wouldn't be too hard to track in
the script (the checker works on one file at a time), but I'd probably want
to see some cases of it before adding the check.

There might be some protocols where there was (say) a 7 byte integer field,
so the dissector writer had to round it up to the nearest supported size,
but again I didn't see that.

Another clue is the amount by which 'offset' might be added to in the very
next line (i.e. which size does it match?), but that would be hard to
reliably parse.

On Fri, Oct 16, 2020 at 10:43 PM Guy Harris <gharris () sonic net> wrote:

> On Oct 16, 2020, at 2:38 PM, Martin Mathieson via Wireshark-dev <
> wireshark-dev () wireshark org> wrote:
>
> > I made a quick change to have tools/check_typed_proto_items.py to check
> calls to proto_tree_add_item() - in particular if the length field in the
> call matches the length implied by the FT_ type.  The fewI've looked at
> seem to be genuine bugs to me, but if anyone could scan the list and check
> any dissectors they know well, it'd be good to work out if there are
> cases/patterns not worth flagging.
>
> Sometimes a given field in a protocol is N bytes in some packets and M
> bytes in others, where N > M.
>
> In those cases the field will be FT_UINT{N}, and some calls will have
> shorter lengths.
>
> Having tools/check_typed_proto_items.py handle that would be more
> complicated, in that it'd have to check all calls before reporting an issue.
>
> Whether any of these instances are cases of that is another matter.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe