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.