|
|
Keith Thompson <kst-u@xxxxxxx> writes:
> Ben Bacarisse <ben.usenet@xxxxxxxxx> writes:
>> Harald van Dijk <truedfx@xxxxxxxxx> writes:
>>> On Fri, 28 Mar 2008 16:01:54 -0500, CBFalconer wrote:
>>>> Ioannis Vranos wrote:
>>>>> Under C95: Is it guaranteed that char, unsigned char, signed char have
>>>>> no padding bits?
>>>
>>> Just a note: padding bits are a concept introduced in the standard in
>>> C99; C90/C95 left much more unspecified about the representation of
>>> integer types.
>>>
>>>> unsigned char, yes.
>>>
>>> Where is this guarantee made? In C99, 5.2.4.2.1 makes it as clear as it
>>> can: "The value UCHAR_MAX shall equal 2^CHAR_BIT - 1."
>>
>> But that alone is not enough, is it?
>
> I believe it is. Assume, for example, CHAR_BIT==8. Then there are
> 256 possible values for the 8 bits making up an unsigned char.
> UCHAR_MAX must equal 255, so there are 256 distinct values, each of
> which must be distinctly representable by one of those bit patterns.
> There are no bit patterns left over, so there can't be any padding
> bits or trap representations. This generalizes to other values of
> CHAR_BIT.
Yes, I got the arithmetic bit! My problem with the statement is that
is tells one that CHAR_BIT must be equal to the number of value bits,
not that there are no other bits.
I think I was just imagining trouble. I wanted some other text to say
that CHAR_BIT counts all the bits, but I think its definition does
that: "the number of bits for smallest object that is not a bit-field
(byte)". This must include any padding, so that is indeed enough. In
all these years, I'd never read the definition of CHAR_BIT.
>> The clearest statement comes
>> later in 6.2.6. p1: "For unsigned integer types other than unsigned
>> char, the bits of the object representation shall be divided into two
>> groups: value bits and padding bits (there need not be any of the
>> latter).". So, unsigned char has only value bits.
>
> You mean 6.2.6.2p1.
Yes. Thanks.
> This describes types other than unsigned char; it says nothing about
> unsigned char itself. If unsigned char were composed entirely of
> naughty bits, with no value bits or padding bits at all, it would not
> contradict that sentence (though it would contradict other
> requirements).
>
> In fact, the phrase "other than unsigned char" could have been left
> out. The bits of the object representation of *any* unsigned type are
> divided into value bits and padding bits, and there needn't be any
> padding bits. Furthermore, for unsigned char there *must* not be any
> padding bits (as implied by 5.2.4.2.1).
Right. I can see that now. In fact, if the phrase were left out,
my misreading of it would have been impossible.
--
Ben.
|
|