ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Is there a good way of handling bitfields withdifferent bitm

From: "Martin Mathieson" <martin.r.mathieson@xxxxxxxxxxxxxx>
Date: Wed, 14 Nov 2007 18:34:03 +0000
I used the not-long-since-added proto_tree_add_bits_ret_val() in
packet-umts_fp.c.
There is also proto_tree_add_bits_item() which doesn't extract the
value for you.

Are these functions not suitable for your purpose?  It certainly
simplified the part of the code I needed it for.

Martin

On Nov 14, 2007 6:22 PM, Neil Piercy <Neil.Piercy@xxxxxxxxxxxx> wrote:
>
>
> > -----Original Message-----
> > [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of
> > ronnie sahlberg
>
> > Not tested!
> > grab the hfinfo structure and modify the fields at runtime :
> >
> > header_field_info *hfinfo;
> >
> > hfinfo = proto_registrar_get_nth(hf_index);
> > hfinfo->bitmask = new bitmask
> > hfinfo->bitshift = new bit shift
>
> > very ugly.   it could work.
>
> I agree - but I'll try!
>
> > please do not contribute any code to wireshark that does
> > anything like this  :-)
>
> That's a shame, because this is needed in order to extend the current
> gsm_a dissector to cope with half octet IE which can be in the upper or
> lower half of the octet.  I did ask for an _good_ way ;-).
>
> I still reckon the general way is to add bit_offset to all the proto
> calls - but I guess that won't happen anytime soon ;-).  Even more ugly
> hack: use the _top_ 3 bits of the current offset in those calls as a bit
> offset......  maybe not!
>
>
> Neil
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>