On Sep 27, 2011, at 12:11 PM, Maynard, Chris wrote:
> I suppose, although I still question the real need for ENC_NA at all.
At this point, I'm willing to see it go away, too.
> Now that being said, changing the "const gboolean little_endian" argument to an "int endian" or better yet, "int encoding" argument
$ egrep encoding epan/proto.h
...
const gint start, gint length, const guint encoding);
> and then performing verification could open up other possibilities. To quote from README.developer:
>
> In the future, other
> elements of the encoding, such as the character encoding for
> character strings, might be supported.
I need to remove the future tense from that statement.
> If other elements of the encoding are to be added, then we will also likely need to change the definition of ENC_BIG_ENDIAN (and possibly ENC_LITTLE_ENDIAN too) so that they are both single bit assignments,
$ egrep 'ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN' epan/proto.h
* So, for now, we define ENC_BIG_ENDIAN and ENC_LITTLE_ENDIAN as
* the same. We therefore define ENC_BIG_ENDIAN as 0x00000000 and
* ENC_LITTLE_ENDIAN as 0x80000000 - we're using the high-order bit
#define ENC_BIG_ENDIAN 0x00000000
#define ENC_LITTLE_ENDIAN 0x80000000
> thus leaving room for other bits to be set, which will give the encoding a different meaning.
$ egrep ENC_ epan/proto.h
...
#define ENC_TIME_TIMESPEC 0
#define ENC_TIME_NTP 2
...
#define ENC_CHARENCODING_MASK 0x7FFFFFFE /* mask out byte-order bits */
#define ENC_UTF_8 0x00000000
#define ENC_ASCII 0x00000000
#define ENC_EBCDIC 0x0EBCD1C0
ENC_ASCII being all zeroes is temporary, and I will be introducing some additional ENC_ values for character codes.