From: Hallvard B Furuseth (h.b.furuseth@usit.uio.no)
Date: Sun Jan 11 2004 - 14:18:48 EST
Philippe Verdy writes:
>From: "Clark Cox" <clarkcox3@mac.com>
>> 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
This archive was generated by hypermail 2.1.5 : Sun Jan 11 2004 - 14:56:44 EST