From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-09 13:59:03
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk