From: "Clark Cox" <[EMAIL PROTECTED]> > Actually, both the C and C++ standards require that the char type be > at least 8-bits. that is, the signed char type must be able to > represent the values in the range [-127, 127], and the unsigned char > type must be able to represent the values in the range [0, 255]. Any C > or C++ compiler that cannot meet those requirements is non-conformant.
Yes of course (however this depends on which standard you discuss here... The language itself does not require it, just the implementation guidelines for applications on generic OS. If you look at some C compilers created for microcontrolers or hardware devices, you'll see that it supports the full core language, but not always with the "standard" library which usually comes bundled with compilers for generic OS platforms, because this library is too fat to be incorporated in the device's firmware). You'll see for example that most BIOS software is written today with a significant part written in C, because it's easier to maintain than assembly language when optimal performance is not a real issue. But the same BIOS will typically never use the standard library. And so a C compiler tuned for writing a BIOS software may ignore the library requirements defined in a C standard made for applications supported by general purpose OS. In such cases, as soon as you start ignoring the POSIX standard (which is not by itself part of the core C language), you can't assert that "char" needs to be at least 8 bits. The compiler may be tuned specially to support the native pointer types, which may use actual physical memory units smaller than 8 bits. The case of bit-adressable memory is intersting here: why do we need in C/C++ to handle individual bits with tricky shift operations if the native platforms could allow you to adress each bit individually or in groups not aligned on char boundaries? This is a performance problem for hardware devices that require faster computing with a microcontroler allowing operations on unaligned bit patterns. This performance problem also affects generic pieces of geral purpose softwares like data compressors, and protocol stacks, full of tricky shift operations that are hard to write cleanly and debug. With bit-addressable memory and processor instructions designed to read/write/operate on unaligned groups of bits simply by their starting address, without needing shift and mask instructions, the code could be much cleaner and faster. And I don't think that C/C++ can't be used to write software for a bit-addressable environment (i.e. with a native and complete support for bit pointers, instead of just char pointers).
