Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 39143: /trunk/epan/dissectors/ /trun

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 2 Oct 2011 12:31:27 -0700
On Sep 30, 2011, at 12:43 PM, Maynard, Chris wrote:

> Well what's the expression?  I guess this is me not seeing the forest through the trees here.  I was so focused on ENC_NA == ENC_BIG_ENDIAN, I didn't even notice the other ENC's, nor the guint encoding.  I also happened to read other things like, "In the future" from README.developer, so I didn't even think to look.

I've updated README.developer to reflect current reality.

> OK, well that confusion aside, and assuming we want to do *something* to try to avoid situations where ENC_NA is incorrectly used where ENC_BIG_ENDIAN or [especially] ENC_LITTLE_ENDIAN should be, how does something like the attached patch grab you?  Keep in mind that this is a VERY INCOMPLETE patch (especially proto.c) and obviously needs more work; it's just to get the basic idea across.

> + * the same.  We therefore define the encoding argument as follows:
> + *
> + *    32 31        30 - 2        1
> + *  +---+---+--------//--------+---+
> + *  |ENDIAN |   CHAR ENCODING  | H |
> + *  +---+---+--------//--------+---+
> + *
> + *  ENDIAN = Endian as follows:
> + *      00 = Historic.  The H bit determines the endian
> + *      10 = Little Endian
> + *      01 = Big Endian
> + *      11 = N/A or Invalid
> + *  CHAR ENCODING = Character encoding as follows:
> + *      0x00000000 = UTF-8 or ASCII
> + *      0x0EBCD1C0 = EBCDIC
> + *  H = Historic endian bit:
> + *      0 = Big Endian
> + *      1 = Little Endian

"CHAR ENCODING" should be replaced by "TYPE ENCODING"; strings aren't the only types where there is additional encoding information - we added support for multiple FT_ABSOLUTE_TIME encodings ("struct timespec", with 32-bit seconds followed by 32-bit nanoseconds, and "NTP time").

The description of the type encoding should probably be left open in that comment, referring to #defines later in the file, so that the comment doesn't have to be updated if new encodings are added.