Kim Barrett wrote:
At 12:51 PM -0400 6/8/06, Beman Dawes wrote:
Gennaro Prota wrote:
* there is no guarantee that an unsigned char has 8 bits...
The C and C++ standards specify char, signed char, and unsigned char all have exactly 8 bits, AFAIK.
CHAR_BITS is defined to be *at least* 8 bits. No guarantee that it is *exactly* 8 bits.
Oops! Sorry, you are correct.
This is not just a historical artifact to support strange ancient processors with odd addressing unit sizes either. There are modern C/C++ implementations for modern DSP processors where, for example, sizeof(char) == sizeof(int) == 1, and CHAR_BITS is 16 or 32 (or perhaps even 64, though I haven't actually run across that last case myself).
I'll have to give that some thought. The primary purpose of endian byte-holders is data interchange between platforms, so I'm not sure endians are of any use if the hardware doesn't support data interchange. OTOH, if the platform does support data interchange at least for certain sizes, then endians have a role and need to work correctly (or yield a noisy failure) and be named and specified accordingly.
Of course, the vast majority of even purportedly portable code ignores this fact, because it can be a real PITA to deal with, usually for little or no benefit.
Yes, understood. Let's say sizeof(char) == sizeof(int) == 1 and CHAR_BITS is 32. My initial reactions is that it is possible to write an implementation that will work for the 4-byte and 8-byte endians to work, but not the other sizes. However, the Boost implementation won't work, and that's just the way the cookie crumbles. I'll add compile time tests so that the Boost implementation will yield a noisy rather than silent failure if CHAR_BITS != 8. Thanks! --Beman