byte to integer

[Vtd]

Hi All,
Simple question regarding byte to integer conversion:
integers are 32, char is 8 bits.

unsigned int a;
int b;
char c;
....
a = (unsigned int)c; /* c is 0 extended to integer (upper 24 bits of a
filled with 0's). Correct? */

b = (int)c; /* c is sign extended to integer (upper 24 bits of b are
filled with 1's or 0's depending on bit 7 of c). Correct? */

Thanks,
Vlad

[Walter Roberson]

In article <11**********************@g49g2000cwa.googlegroups .com>,
Vtd <vt*@charter.net> wrote:

Simple question regarding byte to integer conversion:
integers are 32, char is 8 bits.
[Not in general, but I will assume you are discussing a sample
implementation.]

unsigned int a;
int b;
char c; a = (unsigned int)c; /* c is 0 extended to integer (upper 24 bits of a
filled with 0's). Correct? */ b = (int)c; /* c is sign extended to integer (upper 24 bits of b are
filled with 1's or 0's depending on bit 7 of c). Correct? */

Not exactly. Whether 'char' is signed or unsigned is implementation
dependant. If it is unsigned, then because all the possible values
would fit within an int of the width you indicated for the implementation,
then the value would NOT have sign bit propagation.
--
Entropy is the logarithm of probability -- Boltzmann

[Vtd]

Thanks Walter. So how can I sign extend char to integer?

[Eric Sosman]

Vtd wrote:

Hi All,
Simple question regarding byte to integer conversion:
integers are 32, char is 8 bits.

unsigned int a;
int b;
char c;
...
a = (unsigned int)c; /* c is 0 extended to integer (upper 24 bits of a
filled with 0's). Correct? */
It depends on the value of `c'.

If `c' is non-negative (which will always be the case if
the implementation uses an unsigned `char'), converting this
non-negative value to `unsigned' will produce a small result
with a lot of high-order zero bits. If `c' is negative (which
can only happen if the implementation uses a signed `char'),
converting this negative value to `unsigned' will produce a
large result with a lot of high-order one bits.

Note that the cast has no effect; `a = c' would behave
exactly the same way.
b = (int)c; /* c is sign extended to integer (upper 24 bits of b are
filled with 1's or 0's depending on bit 7 of c). Correct? */

`b' will be set to the same numerical value as `c', which
will always be non-negative on an implementation with unsigned
`char' and could be either negative or non-negative on an
implementation with signed `char'.

Once again, the cast has no effect; `b = c' would behave
exactly the same way.

I imagine your next question might be "Well then, how do
I zero- or sign-extend a `char'?" The pedantic answer is
"It's difficult," but the practical answer is "It's easy:"

a = (unsigned char)c;
b = (signed char)c;

The analysis for systems that use two's complement for
negative `signed char' values is easy; I'll leave it to you.
The pedant's quibble arises because ones' complement and
signed-magnitude representations are also allowed, and these
make things tricker. It's strange to refer to the first line
above as "zero-extending" in a case where `(unsigned char)c'
may have a different bit pattern than plain `c'. The second
line is even more problematic: if `char' is unsigned and the
value of `c' is too large for a `signed char', the conversion
produces undefined behavior. However, such systems seem to
be quite rare nowadays -- hence the practical "It's easy."

--
Er*********@sun.com

[Keith Thompson]

"Vtd" <vt*@charter.net> writes:

Thanks Walter. So how can I sign extend char to integer?

Please provide some context when you post a followup. If you've been
following this newsgroup, you've seen the following many times; please
pay attention to it:

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

If you want sign extension, use signed char.

For example:

unsigned char uc = -1; /* value is UCHAR_MAX, typically 255 */
signed char sc = -1; /* value is -1 */
char c = -1; /* value could be either UCHAR_MAX or -1 */

If it matters whether a character type is signed or unsigned, don't
use "plain" char; use signed char or unsigned char explicitly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Lawrence Kirby]

On Tue, 12 Jul 2005 18:50:28 +0000, Walter Roberson wrote:

In article <11**********************@g49g2000cwa.googlegroups .com>,
Vtd <vt*@charter.net> wrote:

Simple question regarding byte to integer conversion:
integers are 32, char is 8 bits.
[Not in general, but I will assume you are discussing a sample
implementation.]

unsigned int a;
int b;
char c;

a = (unsigned int)c; /* c is 0 extended to integer (upper 24 bits of a
filled with 0's). Correct? */

Not if char has a signed representation. Note that conversions between
integer types are NOT defined in terms of "sign extension" which is a
definition based on representation, they are defined in terms of value. So
if a char with a value of -1 is converted to an int the result remains -1
irrespective of how that is represented. Obviously unsigned types can't
represent the value -1, so unsigned types have a special rule to determine
what the result will be. The rule is that you add or subtract one more
than the maximum value the unsigned type can represent as many times as is
necessary to give a value it can represent (it is essentially a modulo
reduction). For the case of -1 you just add one more than the maximum
value i.e. -1 + (UINT_MAX+1) which gives UINT_MAX as the result. On
2's complement systems this looks a lot like sign extension at the
representation level. Essentially you'll get sign extension on 2's
complement systems on converting to a wider type when the SOURCE type is
signed, the target type is not important.
b = (int)c; /* c is sign extended to integer (upper 24 bits of b are

filled with 1's or 0's depending on bit 7 of c). Correct? */

Not exactly. Whether 'char' is signed or unsigned is implementation
dependant. If it is unsigned, then because all the possible values would
fit within an int of the width you indicated for the implementation,
then the value would NOT have sign bit propagation.

Right - it makes little sense to talk about sign bit propagation from an
unsigned type i.e. a type that have no sign bit.

Lawrence