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

From: Clark Cox (clarkcox3@mac.com)
Date: Sat Jan 10 2004 - 18:03:30 EST

  • Next message: Philippe Verdy: "Re: [OT] ASCII support in C/C++ (was: doubt)"

    On Jan 10, 2004, at 17:50, Philippe Verdy wrote:

    > 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, my assertion holds true in *every* version of the C and
    C++ standards.

    > 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.

            I'm not talking about library requirements, I'm talking about core
    language requirements. Any conforming C or C++ compiler must accept the
    following code, if it doesn't, then it is not a conforming C or C++
    compiler:

    int main(int argc, char *argv[])
    {
            unsigned char uc = 0;
            unsigned char uc2 = 255;
            signed char c = -127;
            signed char c = 127;
            return 0;
    }

    >
    > 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.

            That's my point, yes you can. Both the C and C++ standards explicitly
    state the minimal ranges that various types must be able to represent.
    In order to support a smaller addressable unit, the language
    definitions would have to be changed.

    -- 
    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 : Sat Jan 10 2004 - 18:31:32 EST