On Wed, Jan 8, 2014 at 3:38 PM, rfc2822 email@example.com wrote:
Have a look at RFC 791
September 1981. Not convinced.
‘byte’ - 31
‘octet’ - 5
‘byte’ - 15
‘octet’ - 17
For me the pattern is rather clear - it looks like people use bytes,
and think in bytes, but because other guys from 1981 here, and they
still think in octets, they will rigorously fix all inconsistencies.
“conservative resistance to change” as they call it. It is easier to
comply than to oppose them, because it is mostly non-constructive and
doesn’t leave these people happy in the end anyway.
»Addresses are fixed length of four octets (32 bits).« Nearly all these
specifications use the term “octet”, this is why I like it (and it has the
8 bits in the term, as well as “bit” has the 1 bit [binary digit] in its
term). So we could write “2 octets (int) Version number”, but then it would
still be open if this integer is signed or unsigned. Maybe “2 octets
(unsigned int) Version number” would be the most accurate description.
My personal opinion, is that unless the protocol is bit-based, there is no
need to complicate the context with details. If you didn’t specify
different size for your bytes, then it is the default. I thought that 16
bits is the default for words, but you showed me that modern CPUs are still
using different sizes for this concept. If it will make you feel easier,
unlike words, the 8-bit size of byte is fixed in international IEC
As for unsigned. I usually work with hex and for me there are three levels
of data interpretation: byte range (hex), type (int, string, stringz, …),
structure (list, tree, index, …) - I don’t usually really care about 2nd
level interpretation - because it depends on how do you use the data, so
it’s up to implementation. I doubt I’d ever sum or multiply version field,
so its sign is completely useless for me, but I may want to interpret it as
a string. In this case the knowledge that its source data in hex form is
binary digit, is helpful.
More arguments - if we say that the range of values is 0…65535 - it is
explicit and obvious. If we say that this is (unsigned short) - it is still
ambiguous. GfxTablet on Galaxy Note 10.1, for example, returns max 65535/2
for both coordinates and I suspect that it is a problem with protocol
description. If there was just ushort, I couldn’t rely on that.
And in the end, I find that I don’t like (unsigned int) label because it is
long, but otherwise it is fine with me.