Padding bits in signed char

[Ioannis Vranos]

As far as I know, there are no padding bits in a char object and an unsigned char object. What about signed
char? Is it guaranteed that a signed char has no padding bits?


--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

 

[Michael DOUBEZ]

As far as I know, there are no padding bits in a char object and an
unsigned char object. What about signed char? Is it guaranteed that a
signed char has no padding bits?

Note that it is implementation defined whether a char is a signed or an
unsigned char; .

From the C standard, unsigned char is not allowed to have any padding
bits however any signed integer type can have padding bits and the
standard does not exclude signed char.

But the C++ standard 3.9.1 specifies:
[...] A char, a signed char, and an unsigned char occupy the same amount
of storage and have the same alignment requirements; that is, they have
the same object representation.[...]

My understanding is that under C++, signed char my not have padding bits.

 

[James Kanze]

It is. At least in C.

Note that it is implementation defined whether a char is a
signed or an unsigned char; .

Not exactly. It's implementation defined whether plain char has
the same representation as signed char or unsigned char. (While
I suspect that's what you meant, it's not quite the same thing.
Plain char is always a distinct type.)

From the C standard, unsigned char is not allowed to have any
padding bits however any signed integer type can have padding
bits and the standard does not exclude signed char.

No, at least not in C99. (I can't find any restrictions in C90,
not even that unsigned char cannot have padding bits. Although
I was sure that there were some.) In C++, a plain char is not
allowed to have a trapping representation (although C99
explicitely allows it).

But the C++ standard 3.9.1 specifies:
[...] A char, a signed char, and an unsigned char occupy the
same amount of storage and have the same alignment
requirements; that is, they have the same object
representation.[...]

My understanding is that under C++, signed char my not have
padding bits.

Hopefully, that's the intent. C99 managed to finally express
clearly what was and was not allowed; regretfully, it doesn't
like like C++ will follow suit.

 

[Ioannis Vranos]

As far as I know "there is a guarantee for no padding bits at unsigned char in C90/C95, and for unsigned char
and char in C++98/03".


However since

1. sizeof(signed char)== sizeof(unsigned char)== sizeof(char)== 1 Byte,


and

2. unsigned char (and char in C++) have no padding bits


doesn't this imply that signed char can not have padding bits, since the definition of the number of bits of a
Byte can not be different between unsigned char, char, and signed char?




--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

 

[James Kanze]

No it's not, not in C99.

6.2.6.2 p2:

"For signed integer types, the bits of the object
representation shall be divided into three groups: value bits,
padding bits, and the sign bit. There need not be any padding
bits; there shall be exactly one sign bit."

There is specifically no exemption for signed char, and plain
char if signed, as there is in the paragraph above for
unsigned char:

"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 I see. I was convinced that there was.

On the other hand, there is a requirement that signed char,
unsigned char and char have the same size, and that all of the
non-negative values of a signed char have the same
representation as the value in an unsigned char. Or I think
there was in C90 (last night, I only had access to C90, where I
am now, I only have access to C99)---the change in wording in
C99 makes this less certain: "Each bit that is a value bit shall
have the same value as the same bit in the object representation
of the corresponding unsigned type." I suppose that this does
leave open the possibility of an implementation with 9 bit
bytes, all 9 bits being used for unsigned char, but signed char
with 1 bit sign, 1 bit padding and 7 value bits.

Of course, in C++, we also have the guarantee that char has no
trapping representations (which C explicitly doesn't give---only
unsigned char has this characteristic).

And I might add that I find it rather disappointing that C and
C++ have gone separated ways here. I would have liked for the
integral types in both languages to be compatible. Of course,
there is a compatible subset, and for very pratical reasons, all
implementations will implement something in that subset. Thus,
on the implementations where signed char might have a trapping
representation, plain char will be unsigned. Similarly,
historically, there's so much C code around that counts on being
able to copy char like the C standard guarantees for unsigned
char, and like C++ guarantees for char, that no implementation
would dare break it. But these things are important enough,
IMHO, that one would like to see them enshrined in the standard.

 

[James Kanze]

As far as I know "there is a guarantee for no padding bits at unsigned char in C90/C95, and for unsigned char
and char in C++98/03".

However since

1. sizeof(signed char)== sizeof(unsigned char)== sizeof(char)== 1 Byte,

2. unsigned char (and char in C++) have no padding bits

I'm not sure that that's true in C++. It's necessary that the
padding bits copy correctly, of course, but I'm not sure that
anything more is required.

doesn't this imply that signed char can not have padding bits,
since the definition of the number of bits of a Byte can not
be different between unsigned char, char, and signed char?

The total number of bits cannot be different, but how they are
divided between the fields can. In C99, for example, an
implementation with 9 bit bytes, with signed char and char
having 1 sign bit, 1 pad bit and 7 value bits, and unsigned char
having 9 value bits, is clearly legal.

The current C++ standard has a number of problems in this
respect, and taken literally, can't be implemented on at
least one major modern architecture. See DR 689. This one is
still open, and hasn't been addressed in the CD; the current
wording in the CD, taken literally---which is the only way to
take a standard---cannot possibly be implemented. I presume
that this will be fixed before the final standard is adopted.