Comment # 10
on bug 8472
from Evan Huus
(In reply to comment #9)
> (In reply to comment #8)
> > Committed in r49357.
>
> >> From me:
> >> Permit using 64-bit integers with value-strings, as this protocol actually
> >> seems to needs it. We'll misbehave for named values > 2^32 but there aren't any
> >> of those despite the field being 64 bits.
>
> Why? We don't support value_string nor in fill_label_numer64() nor in
> proto_custom_set() for FT_UINT64.
Because I was lazy and didn't think it through all that well :/
> It's confusing, I think we either need val64_to_str*() set of functions, or
> generate error^W warning.
The problem with creating a value_string64 (or similar solutions) is that it
seems reasonable for a set of value_strings to be shared between a fields of
different sizes (uint8 through uint64) and doing that would require two copies
of the value_string: one for uint64 and one for all the others.
I did a quick check of the memory cost of just making all value-strings 64-bit
(basically s/32/64/ in value_string.[ch]): libwireshark.so grew by only about
60KB. I'm not sure if this would have a performance impact on 32-bit systems (I
don't have one handy to test) but if it's not too bad then this is probably the
simplest solution.
You are receiving this mail because:
- You are watching all bug changes.
