CHAR_BIT > 8 and int8_t

[Jens Thoms Toerring]

Hi,

I am a bit unsure about the sizes of objects of types like
int8_t on systems where CHAR_BIT is larger than 8. I guess
that e.g. the result of sizeof on an array like

int8_t a[ 4 ];

will be 4 even on a system where CHAR_BIT is e.g. 16, or that

int_8 *b = malloc( 4 * sizeof *b );

will result in a pointer to an object that's as large as
one with 4 chars. At least that would look reasonable to
me since, as far as I can see, sizeof can't result in a
fraction of a "byte". Or, in another example, would on
such systems

int8_t a[ 4 ] = { 1, 2, 3, 4 };
int8_t b[ 2 ];
memcpy( b, a, 2 );

be ok to copy the first two elements of a to b or would
one need

memcpy( b, a, 2 * sizeof *a );

to get the last argument right?

In the standard I found: "The typedef name intN_t designates
a signed integer with width N, no padding bits, and a two's
complement representation. Thus, int8_t denotes a signed
integer type with a width ofexactly 8 bits."

What got me confused the most is the "no padding" part of this.
If CHAR_BIT is e.g. 16 how can there ne no padding? Does this
imply that 2 objects of int8_t must be stuffed into a single
char (which would be even more difficult in case CHAR_BIT is
something even more unusal like 37;-)

On the other hand these intN_t etc. types are optional. So
it's possible that e.g. int8_t simply doesn't (or can't)
exist on systems with CHAR_BIT > 8. But I don't have access
to any such system, so I have no idea what to expect....

Thanks for your help, Jens

 

[jameskuyper]

Hi,

I am a bit unsure about the sizes of objects of types like
int8_t on systems where CHAR_BIT is larger than 8. I guess
that e.g. the result of sizeof on an array like ....
On the other hand these intN_t etc. types are optional. So
it's possible that e.g. int8_t simply doesn't (or can't)
exist on systems with CHAR_BIT > 8.

That is exactly correct. This is, in fact, a prime example of
precisely why the exact-sized types are optional.

 

[Jens Thoms Toerring]

That is exactly correct. This is, in fact, a prime example of
precisely why the exact-sized types are optional.

Thank you, that restores my peace of mind (at least in this
regard;-)
Best regards, Jens