Re: BItfields Larger than 32 Bits

["Shanks, Graham (UK)" <graham.shanks () baesystems com>]

On 14 May 2014 09:06 Michal Labedzki <michal.labedzki () tieto com> wrote:

> I have new idea: leave current 32bit mask as is, add two new fields (or 
> [pointer to?] structure): "bit offset" and "bit length". This works only >
> for contiguous masks, but I think it is ok. For example:
> 1111000111
> bitoffset = 4
> bitlength = 3
> Result: ..110.....
>
> This should be suffice for a long time (UINT32_MAX bits are supported).

+1

Although I expect that adding two new fields to the hf struct would be too much of a breaking change. Perhaps a new 
field type (FT_BITFIELD?) and some creative overloading of the other hf struct fields. Display could be used to specify 
the length of the underlying data and we could use bitmask to hold the bit offset and length as 16 bit values 
(UINT16_MAX should still be enough for a long time) with a macro to hide the packing of two 16 bit values in the 32 bit 
field. A typical use would be:


{ &hf_a_field, {
        "Name", "id",
        FT_BITFIELD, 64, VALS(my_values), MAKE_BIT_DEF(30, 4),
        NULL, HFILL
} },

Where my_values is an appropriate value_string array and MAKE_BIT_DEF is defined as:

#define MAKE_BIT_DEF(start, offset) ( ((start) << 16) + (offset))


I think that bitfields larger than 128 would cause problems in the display (one character for each bit in the bitfield 
is required) so perhaps we should limit the valid bitfield length to multiples of 8 less than or equal to 128, at least 
at the start.

Methinks it is time to learn about git, gerrit and the whole new kit and caboodle with building the latest Wireshark

Regards,
Graham

BAE Systems Integrated System Technologies Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 3456325 
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe