Padding bits and char, unsigned char, signed char

[Ioannis Vranos]

Under C95:

Is it guaranteed that char, unsigned char, signed char have no padding bits?

 

[CBFalconer]

Under C95: Is it guaranteed that char, unsigned char, signed
char have no padding bits?

unsigned char, yes. The others by implication. I haven't checked
the standard. Why don't you?

 

[Harald van Dijk]

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." I don't have a
copy of an older standard. Does it make the same guarantee?

The others by implication.

How so? What's preventing a signed integer type and its corresponding
unsigned type from having a different number of padding bits?

 

[pete]

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.


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." I don't have a
copy of an older standard. Does it make the same guarantee?

It doesn't.
There's really nothing about padding in the "basic types" in C90.

How so? What's preventing a signed integer type and its corresponding
unsigned type from having a different number of padding bits?

I think he meant char and signed char, but even then I disagree.

As far as I know, signed char can have padding bits.

 

[Ben Bacarisse]

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.


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

 

[Keith Thompson]

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.

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.

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

 

[Ben Bacarisse]

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.

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.