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 Oct 16, 2020, at 2:38 PM, Martin Mathieson via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> 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.
