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?

manik wrote:

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

santosh <santosh.k83@gmail.com> writes:

> manik wrote:
>> Assuming int is 32 bits and char is 8 bits on my machine

>> int a = 0x12345678;
>> char b;
>> b=(char)a;

>> Would the value of b depend on the endianness of the machine?
>
> 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

In article <m3y7a6cfzp.fsf@Claudio.Messina>,
Mark L Pappin <mlp@acm.org> wrote:

>>> int a = 0x12345678;
>>> char b;
>>> b=(char)a;
>
>>> Would the value of b depend on the endianness of the machine?

>> Yes.

>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
--
:wq

santosh wrote:
> manik wrote:
>
>> 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.

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

--
Eric Sosman
esosman@ieee-dot-org.invalid

manik <manik.budhiraja@gmail.com> writes:

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

--
Ben.

On 31 Jan 2008 22:54:34 +1000, Mark L Pappin <mlp@acm.org> wrote in
comp.lang.c:

> santosh <santosh.k83@gmail.com> writes:
>
> > manik wrote:
> >> Assuming int is 32 bits and char is 8 bits on my machine
>
> >> int a = 0x12345678;
> >> char b;
> >> b=(char)a;
>
> >> Would the value of b depend on the endianness of the machine?
> >
> > 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'.

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

Jack Klein <jackklein@spamcop.net> writes:
> Mark L Pappin <mlp@acm.org> wrote:
>> santosh <santosh.k83@gmail.com> writes:
>>> manik wrote:
>>>> Assuming int is 32 bits and char is 8 bits on my machine
>>>> int a = 0x12345678;
>>>> char b;
>>>> b=(char)a;

>> even the signedness of 'char' is irrelevant as values up to 127 are
>> guaranteed representable even in 'signed char'.

> 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