On Tue, Jul 14, 2009 at 11:09:01AM -0700, Guy Harris wrote:
> Making the field FT_UINT32 - or FT_UINT64 if it's likely to have
> values > 2^32-1, or FT_INT32 if it's signed, or FT_INT64 if it's
> signed and likely to have values > 2^31-1 or < -2^31 - and using
> proto_tree_add_uint() after fetching the value is probably the best
> idea.
>
> For better or worse, we don't have a FT_INT and FT_UINT (with no "n")
> that can handle arbitrary-size integral values, which, at least in
> theory, could be required by protocols using at least some ASN.1
> encodings, as well as by your encoding.
In addition, if the value simply needs to be displayed as hex and it is
not a 64-bit or less integer, we have FT_BYTES for an arbritary length
hex field.
Steve