Re: [OT] ASCII support in C/C++ (was: doubt)

From: Clark Cox (
Date: Sun Jan 11 2004 - 19:05:04 EST

  • Next message: Doug Ewell: "Re: Detecting encoding in Plain text"

    On Jan 11, 2004, at 17:07, Philippe Verdy wrote:

    > ----- Original Message -----
    > From: "Hallvard B Furuseth" <>
    > To: "Philippe Verdy" <>
    > Cc: "Clark Cox" <>; "Unicode Mailing List"
    > <>
    > Sent: Sunday, January 11, 2004 8:18 PM
    > Subject: Re: [OT] ASCII support in C/C++ (was: doubt)
    >> Philippe Verdy writes:
    >>> From: "Clark Cox" <>
    >>>> 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 (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 _ressembling_ C.
    > All this relates to the language that was standardized very lately by
    > ISO
    > and initially by ANSI (in collaboration with the initial designers
    > Kernighan
    > and Richie who designed the language to write Unix).

            C was standardized quite a while ago (1989). There may very well still
    be K&R implementations all over the place, but those are "K&R C", not
    "C". The language known as "C" is defined by the ISO standard. Claiming
    that "C" is still defined by K&R is like claiming that "Unicode" is
    still defined by Unicode 1.0.

    > There are still a lot
    > of code needing support of the K&R C language, which is a de-facto
    > (rather
    > than de-jure) standard, as it was specified in the first edition of
    > "the C
    > language" by Brian Kernighan & Dennis Richie (Prentice-Hall, 1978) and
    > translated into languages (1983 for the French edition) .
    > There are still a lot of systems which ONLY support a K&R C compliant
    > compiler (without "void", "signed char", "long long", and function
    > prototypes) but not the ANSI C american standard, or the late ISO C
    > standard. And most of these systems do not have all what is required to
    > support POSIX. And lots of other C++ compilers that were written and
    > used on
    > systems long before the ISO C standard was published, and still not
    > implementing the full ANSI C standard.

            You keep making a distinction between the ANSI C standard and the ISO
    C standard; the two are identical except for some formatting and the
    table of contents. ANSI C 1989 is the same as ISO C 1990, and ANSI and
    ISO C 1999 are the same.

    > Not all platforms are supporting fully IEEE-compliant floatting point
    > operations as well (because there's no FPU and fully implementing it by
    > software would impact too much performance). So the POSIX and ISO C
    > requirements cannot be applied to these systems. Note that even on PC
    > systems, the FPU is not always fully IEEE-compliant,

            C has no requirement that systems be IEEE compliant with respect to
    floating point numbers.

    Clark S. Cox III

    This archive was generated by hypermail 2.1.5 : Sun Jan 11 2004 - 19:43:49 EST