Wireshark · Wireshark-dev: Re: [Wireshark-dev] Some apparent type bugs

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

Don’t know, just noticed the UINT part and thought about returning 'a value' should be possible.

Will have to look into this more closely to see if and what makes sense.

Thanks,

Jaap

On 31 Jul 2020, at 14:05, John Thacker <johnthacker@xxxxxxxxx> wrote:

On Fri, Jul 31, 2020 at 7:51 AM Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:

Hi,

Shouldn’t these be supported? After all, they have a UINT.

On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...) called at ./tools/../epan/dissectors/packet-ppp.c 2377 with type FT_UINT_BYTES
    (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 'FT_UINT8'} )

Error: proto_tree_add_item_ret_uint (.., hf_slsk_directory_name , ...) called at ./tools/../epan/dissectors/packet-slsk.c 1051 with type FT_UINT_STRING
    (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 'FT_UINT8'} )

There's a UINT passed in that's the fixed length of the length field, there's the total length (which is the value in the length field of

the variable bytes plus the passed in fixed UINT) returned by proto_tree_add_item_ret_length(), and then there's the value of the

variable length field only.

Is the proposed change to have proto_tree_add_item_ret_uint() return the value contained in the variable length field

instead of the total length? Is that ever necessary? Shouldn't in most cases just _ret_length() be used instead?

John Thacker