Stefano,
One other possibility is to register the protocol field several times with
the *same* field name but with a *different* field type, depending on the
width of the field. You'd then for example define the following header
fields:
hf_alc_lct_toi_8 when the value is encoded in 1 byte (8 bits),
hf_alc_lct_toi_16 when in 2 bytes, hf_alc_lct_toi_24 when in 3 bytes,
hf_alc_lct_toi_32 when in 4 bytes, hf_alc_lct_toi_64 when in 8 bytes etc.
You would then register those with:
{ &hf_alc_lct_toi_8,
{ "ALC LCT TOI (8 bit)", "alc.lct.toi", FT_UINT8, BASE_DEC,
NULL, 0x00, "long version of description", HFILL } },
{ &hf_alc_lct_toi_16,
{ "ALC LCT TOI (16 bit)", "alc.lct.toi", FT_UINT16, BASE_DEC,
NULL, 0x00, "long version of description", HFILL } },
{ &hf_alc_lct_toi_24,
{ "ALC LCT TOI (24 bit)", "alc.lct.toi", FT_UINT24, BASE_DEC,
NULL, 0x00, "long version of description", HFILL } },
etc.
Best regards,
Olivier
----- Original Message -----
From: Stefano Pettini
Guy Harris wrote:
You'd have to write your own code, or find code, to do whatever's
necessary to support integral data types bigger than 64 bits.
I have an important field (alc.lct.toi) containing numeric values up to
2^112-1. Since its size is not fixed, this field is often 16-bits or
32-bits but it can potentially grow up to 112-bits.
I would like to make this field easily searchable, so I would like to use
an FT_UINT* format during registration, to allow the user to ask for
"alc.lct.toi == 1". But it's incompatible with a 112-bits integer, that
doesn't exists and isn't handled by ethereal.
The problem is partially solved using FT_BINARY (well, I don't remember
very well if this format exists :-). I've managed the field like an array
of bytes, not like a very large integer. Unfortunately this makes
searching difficult, since "alc.lct.toi == 1" doesn't work.
Even if more correct, I don't think this is the best solution, since the
field is going to contain often simple numbers (0, 1, 2).
Any suggestion?
Thanks.
Stefano