Type conversion

[manik]

Assuming int is 32 bits and char is 8 bits on my machine

Say I have the following piece of code

int a = 0x12345678;
char b;

b=(char)a;

What would be the value of b?

Would the value of b depend on the endianness of the machine?

 

[santosh]

Assuming int is 32 bits and char is 8 bits on my machine

Say I have the following piece of code

int a = 0x12345678;
char b;

b=(char)a;

What would be the value of b?

Would the value of b depend on the endianness of the machine?

Yes. Also note that for maximum portability use either signed or
unsigned char for holding non-character values. The signedness of plain
char is implementation dependant, thus creating needless
non-portability.

 

[Mark L Pappin]

Yes.

C&V?

Casts, like most other operations, are defined in terms of value, not
representation, no? Thus the low-order 8 bits will be used, and in
this instance since
(a & 0xff) == (a & 0x7f)
even the signedness of 'char' is irrelevant as values up to 127 are
guaranteed representable even in 'signed char'.

mlp

 

[Richard Tobin]

Yes.

[/QUOTE]

Casts, like most other operations, are defined in terms of value, not
representation, no? Thus the low-order 8 bits will be used, and in
this instance since
(a & 0xff) == (a & 0x7f)
even the signedness of 'char' is irrelevant as values up to 127 are
guaranteed representable even in 'signed char'.

If char is signed, we have a conversion to a signed integer with
smaller size, and in that case if the value cannot be represented
the result is implementation-defined.

-- Richard

 

[Eric Sosman]

Yes.

No; endianness doesn't affect the outcome.

Also note that for maximum portability use either signed or
unsigned char for holding non-character values. The signedness of plain
char is implementation dependant, thus creating needless
non-portability.

Right. If char is unsigned (and eight bits wide, by
assumption), the value stored in `b' will be 0x78 == 120.
If char is signed, the conversion to char produces an
implementation-defined result or raises an implementation-
defined signal ("trap").

 

[Ben Bacarisse]

Assuming int is 32 bits and char is 8 bits on my machine

Say I have the following piece of code

int a = 0x12345678;
char b;

b=(char)a;

b = a;

is simpler and has the same effect. Casts are for cases where type
conversion do not otherwise take place.

What would be the value of b?

Even the value of a in doubt! Let's assume that the initialisation of
a does not overflow...

Would the value of b depend on the endianness of the machine?

No, not in any usual sense of the word.[1]

If char is unsigned the value is guaranteed by the standard (it is the
value of a mod UCHAR_MAX + 1) but the unsigned-ness of char is not
guaranteed, so the code is not portable. If char is signed, and the
value of a does not fit (it might!) then the result is implementation
defined.

[1] I say this because (since the result may be implementation-defined)
the implementation is permitted to cause the value of b to depend on
the (settable) endian-ness of the machine, but that is not what one
usually means by the phrase.

 

[Jack Klein]

C&V?

Casts, like most other operations, are defined in terms of value, not
representation, no? Thus the low-order 8 bits will be used, and in
this instance since
(a & 0xff) == (a & 0x7f)
even the signedness of 'char' is irrelevant as values up to 127 are
guaranteed representable even in 'signed char'.

That is not what the C standard guarantees.

If char is unsigned, the result of the assignment will indeed be 0x7b,
although it is actually defined as the value % (UCHAR_MAX + 1).

But if char is signed, there is no requirement that the result is what
you indicate, although it is common. When converting a higher rank
integer type to a lesser rank signed integer type, if the value is
outside the range of the lesser rank signed type, either an
implementation-defined value results, or an implementation-defined
signal is raised.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Mark L Pappin]

But if char is signed, there is no requirement that the result is
what you indicate, although it is common. When converting a higher
rank integer type to a lesser rank signed integer type, if the value
is outside the range of the lesser rank signed type, either an
implementation-defined value results, or an implementation-defined
signal is raised.

Thanks for clarifying that, Jack. I had convinced myself that the
assignment with cast was equivalent to

b = a & ((1ul<<CHAR_BIT)-1);

(yes, the expression would need to be tweaked to handle (sizeof
long)==1 properly; that's not relevant here)
but I see now that it is not necessarily so.

Long live "implementation-defined".

mlp