Re: [Wireshark-dev] proto_tree_add_item() calls where length doesn't match type of hf item

2020-10-17 Thread Martin Mathieson via Wireshark-dev
On Fri, Oct 16, 2020 at 11:14 PM Guy Harris wrote: > On Oct 16, 2020, at 2:54 PM, Martin Mathieson < > martin.r.mathie...@googlemail.com> wrote: > > > 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

Re: [Wireshark-dev] proto_tree_add_item() calls where length doesn't match type of hf item

2020-10-16 Thread Guy Harris
On Oct 16, 2020, at 2:54 PM, Martin Mathieson wrote: > 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. That's because the nearest supported size is FT_{U}INT5

Re: [Wireshark-dev] proto_tree_add_item() calls where length doesn't match type of hf item

2020-10-16 Thread Martin Mathieson via Wireshark-dev
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

Re: [Wireshark-dev] proto_tree_add_item() calls where length doesn't match type of hf item

2020-10-16 Thread Guy Harris
On Oct 16, 2020, at 2:38 PM, Martin Mathieson via Wireshark-dev 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