On 10/10/2011 2:44 PM, Bill Meier wrote:
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 ?
Ok: I'd like to get the work done for FT_STRING, ... (and having not
received much comment on this)
I propose to do the following for
the FT_STRING, FT_STRINGZ, FT_UINT_STRING "encoding" parameter:
Essentially: Specify a character encoding but specify endianness only
where relevant.
Conversions:
1. For other than FT_UINT_STRING, remove all existing True/1/FALSE/0
& ENC_NA/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN;
2. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
As Guy noted re the choice of character encoding:
> That, or ENC_UTF_8. I suspect most new protocols support UTF-8;
> older ones either only specify ASCII or use various legacy encodings.
> Automated replacement will get it wrong for some protocols regardless
> of whether we use ENC_ASCII or ENC_UTF_8; the question is which of
> those would be worse, for some value of "worse".
I've no idea of which is "worse" (or how to decide) so I picked ENC_ASCII.
I'll hold off doing any changes until tomorrow to wait for any comments.
Bill
