Philippe Verdy writes: >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...
No, it doesn't. > The language itself does not require it, just the implementation guidelines > for applications on generic OS. The C and C++ languages are defined by the C and C++ standards. As Clark says, the standards do require this. See for example ISO C section 5.2.4.2.1 (Sizes of integer types <limits.h>). > If you look at some C compilers created for microcontrolers or hardware > devices, you'll see that it supports the full core language, If it does, it has 8-bit 'char' or wider. Otherwise it is not a C compiler, however much it might claim to be. It is a compiler for a language _resembling_ C. > 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). Right. The C standard is divided in core language and library. It defines two types of implementations: 'hosted implementations' which must support the full library, and 'freestanding implementations' which need not. Both types of implementations are required to support the full core language, except complex types in C99. Both must have the header <limits.h>, which describes the sizes of various types and must describe char has having at least 8 bits. See ISO C section 4 (Conformance). > 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. Right. > 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. Wrong. That assertion is in the C core language. I don't know if it is in the the POSIX standard too, but if so that's irrelevant. > The compiler may be tuned specially to support the native pointer > types, which may use actual physical memory units smaller than 8 bits. As extensions to the language, yes. The language standard has no objection to extensions, as long as they do not violate the other requirements of the language. Most C compilers extend the language in one way or another. Hosted and freestanding implementations are no different in this respect. > 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). There are basically two ways to do this: - extend the language to support a bit pointer type and operations on it, - define a bit pointer type - either as a separate type in the language, or just use e.g. the type 'long' - and create a library with bit pointer operations. One might then optimize the compiler to turn the library function calls into bit pointer code, so they won't be any slower than if one had put the operations in the language itself. BTW, whatever one puts in the language itself might not be intended to be used directly, but only by via bit pointer manipulation macros provided by some header file. It might be less work for the implementor to put only a few general bit pointer operations in the language itself, and just provide a macro interface to the various ways to use it. -- Hallvard
