C compilers and non-ASCII systems

-----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Eric Smith Sent: 01 February 2012 07:48 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: C compilers and non-ASCII systems Mouse wrote: whatever the implementation-defined). Chuck Guzis wrote: That's definitely not allowed for unsigned char, which is not allowed to have any padding bits. If an unsigned char has n bits, it must be able to represent all values from 0 to (2^n)-1. For the larger integer types it is possible, as all larger integer types are allowed to have padding bits. The requirement is that any bit that is a value bit (and not a sign bit or padding bit) in a signed type must "have the same value as the same bit in the object representation of the corresponding unsigned type" (ISO/IEC 9899:1999 section 6.2.6.2 paragraph 2) Due to the requirements for the integer size limits (limits.h, section 5.2.4.2.1), if you want to do that your short and integer will have to be at least 17 bits, long will have to be at least 33 bits, and long long will have to be at least 65 bits. This would be somewhat reasonable on an 18-bit machine or 36-bit machine, with 9-bit chars, and the other integer types being 18-bit, 36-bit, and 72-bit. However, I think most people would prefer an implementation where the unsigned integer types did not have padding bits, and could represent the full range possible with the width of the type.