RE: Section 4.1 clarifications

["Michael Krueger" <michael.krueger@windriver.com>]

Pat,

> I think Michael's point is that the decimal encoding for a 1024
> byte binary is around 2500 characters (if I've done the math
> right) while the hexadecimal encoding is 2050 characters and
> someone anticipating the binary might not have made wherever they
> store the string before conversion big enough for the extra ~450
> characters.
>
> The extra storage is small compared to the amount of data one may
> be moving later once the connection is up, but I also don't see
> the readability argument as applying to these large constants.

Actually, I'm concerned neither with storage space nor with speed, but
rather with code complexity.  Unlike hexadecimal and base-64 encoding, there
is not a simple correspondence between decimal digits in the string
representation and bit locations in the binary item.  Most implementation of
decimal-to-binary conversion functions like strtoul() do integer arithmetic
to obtain the binary representation, but this isn't feasible for binary
items larger than 4 (or, at an absolute maximum, 8) bytes.  Show me a simple
algorithm or a widely available library function for converting a
2,467-digit string to its 1024-byte binary representation, and I'll use it;
otherwise, support for decimal encoding of large binary items seems like a
needless complication that pays back very little added value.

Michael

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010