On 10/4/2011 2:45 PM, Guy Harris wrote:
... FT_STRING, FT_STRINGZ, and FT_UINT_STRING, for which an
encoding should also be supplied.
The endianness is irrelevant for ENC_UTF_8, ENC_ASCII, and
ENC_EBCDIC.
> In the future, there will be ENC_UTF_16 and possibly ENC_UCS_2, for
> which the endianness will be relevant.
>
> Should we always specify an endianness for strings, or only for those
> character encodings where it's relevant?
For FT_STRING..., rather than cluttering up the encoding arg with
ENC_NA, I would be sightly inclined to specify endianness only where
relevant.
For FT_UINT_STRING obviously ENC_[BIG|LITTLE]_... would be needed for all.
However, I can understand the approach of always specifying an
endianness to be consistent with other usage. After all, we're already
using ENC_NA for FT_BYTES, FT_NONE & etc.
Thoughts ?
-------
In any case, no matter what is decided, changes will be needed for
FT_STRING & etc.
Is it OK to just change all the instances with no character encoding to
ENC_ASCII (with or without ENC_NA) ?
Currently: the encoding arg instance count for proto_tree_add_item()
calls in epan/dissectors is as follows:
FT_STRING/FT_STRINGZ:
593 FALSE
124 TRUE
38 0
394 ENC_BIG_ENDIAN
105 ENC_LITTLE_ENDIAN
85 ENC_NA
17 ENC_ASCII|ENC_BIG_ENDIAN
1 ENC_ASCII|ENC_LITTLE_ENDIAN
25 ENC_UTF_8|ENC_BIG_ENDIAN
14 ENC_UTF_8|ENC_LITTLE_ENDIAN
2 ENC_UTF_8|ENC_NA
1 ENC_UTF_8
29 ENC_EBCDIC|ENC_NA
FT_UINT_STRING (9 or so files):
36 ENC_BIG_ENDIAN
14 ENC_LITTLE_ENDIAN
10 ENC_UTF_8|ENC_BIG_ENDIAN
