From: Clark Cox (clarkcox3@mac.com)
Date: Sun Jan 11 2004 - 19:05:04 EST
On Jan 11, 2004, at 17:07, Philippe Verdy wrote:
>
> ----- Original Message -----
> From: "Hallvard B Furuseth" <h.b.furuseth@usit.uio.no>
> To: "Philippe Verdy" <verdy_p@wanadoo.fr>
> Cc: "Clark Cox" <clarkcox3@mac.com>; "Unicode Mailing List"
> <unicode@unicode.org>
> Sent: Sunday, January 11, 2004 8:18 PM
> Subject: Re: [OT] ASCII support in C/C++ (was: doubt)
>
>
>> 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 _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 clarkcox3@mac.com http://homepage.mac.com/clarkcox3/ http://homepage.mac.com/clarkcox3/blog/B1196589870/index.html
This archive was generated by hypermail 2.1.5 : Sun Jan 11 2004 - 19:43:49 EST