Padding bits and char, unsigned char, signed char

[Ioannis Vranos]

Under C++03:

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

 

[Victor Bazarov]

Under C++03:

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

I can find no such guaranteed in the document (you still haven't
got your own copy?)

V

 

[Ron Natalie]

Under C++03:

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

Yes, the first paragraph of 3.9.1:

For character types, all bits of
the object representation participate in the value representation

 

[Ron Natalie]

I can find no such guaranteed in the document (you still haven't
got your own copy?)

V

3.9.1

For character types, all bits of
the object representation participate in the value representation

 

[Ioannis Vranos]

Yes, the first paragraph of 3.9.1:

For character types, all bits of
the object representation participate in the value representation

OK, thanks. The plural form "types" obviously contains char, signed char
and unsigned char.

 

[Andrey Tarasevich]

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

Yes. Also, it is guaranteed that any combination of value forming bits
in unsigned character type is a valid combination. There's no such
guarantee for signed character type.

 

[Ioannis Vranos]

Yes. Also, it is guaranteed that any combination of value forming bits
in unsigned character type is a valid combination. There's no such
guarantee for signed character type.

I suppose it is guaranteed for plain char too.

 

[Andrey Tarasevich]

I suppose it is guaranteed for plain char too.

Er.... Plain 'char' gets the same guarantees as the signed/unsigned char
type it shares its representation with.

This is actually why I used term 'character type' instead of 'char type'
in my previous message. "Unsigned character type" refers to both
'unsigned char' and 'char' on a platform where 'char' is unsigned. Same
for signed.

 

[Ioannis Vranos]

Er.... Plain 'char' gets the same guarantees as the signed/unsigned char
type it shares its representation with.

This is actually why I used term 'character type' instead of 'char type'
in my previous message. "Unsigned character type" refers to both
'unsigned char' and 'char' on a platform where 'char' is unsigned. Same
for signed.

I think there is a difference between C95 and C++03 on these. In both
languages it is guaranteed that any POD type can be treated as a
sequence of unsigned chars. I do not remember which language also
permits to be treated as a sequence of plain chars and/or-not signed chars.

 

[Ron Natalie]

I think there is a difference between C95 and C++03 on these. In both
languages it is guaranteed that any POD type can be treated as a
sequence of unsigned chars. I do not remember which language also
permits to be treated as a sequence of plain chars and/or-not signed chars.

char, unsigned char, signed char. None can have padding bits in C++.
PODS can be copied to arrays of "char" or "unsigned char". Signed
char behavior isn't specified.

In C (99, what the fark is 95?), you are right. It only makes
guarantees for unsigned char.

 

[Default User]

Ron Natalie wrote:

In C (99, what the fark is 95?)

C89 with some corrections.



Brian

 

[Ioannis Vranos]

char, unsigned char, signed char. None can have padding bits in C++.
PODS can be copied to arrays of "char" or "unsigned char". Signed
char behavior isn't specified.

In C (99, what the fark is 95?), you are right. It only makes
guarantees for unsigned char.

OK, thanks for the clarification. C95 is ISO/IEC 9899:1995 - Amendment 1.

Basically it is C90+ 3 standard header files, <wchar.h>, <wctype.h>,
<iso646.h>.


C95 is really the C "subset" of C++98, not C90.