byte to integer

Discussion in 'C Programming' started by Vtd, Jul 12, 2005.

  1. Vtd

    Vtd Guest

    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
    Vtd, Jul 12, 2005
    #1
    1. Advertising

  2. In article <>,
    Vtd <> 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
    Walter Roberson, Jul 12, 2005
    #2
    1. Advertising

  3. Vtd

    Eric Sosman Guest

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

    --
    Eric Sosman, Jul 12, 2005
    #3
  4. Vtd

    Vtd Guest

    Thanks Walter. So how can I sign extend char to integer?
    Vtd, Jul 12, 2005
    #4
  5. "Vtd" <> 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) <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.
    Keith Thompson, Jul 12, 2005
    #5
  6. On Tue, 12 Jul 2005 18:50:28 +0000, Walter Roberson wrote:

    > In article <>,
    > Vtd <> 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
    Lawrence Kirby, Jul 13, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andreas
    Replies:
    1
    Views:
    845
    Jonathan Bromley
    May 4, 2004
  2. Bharat Bhushan

    Appending byte[] to another byte[] array

    Bharat Bhushan, Aug 5, 2003, in forum: Java
    Replies:
    15
    Views:
    40,241
    Roedy Green
    Aug 5, 2003
  3. Jean-Daniel Gamache
    Replies:
    0
    Views:
    421
    Jean-Daniel Gamache
    Jul 14, 2004
  4. Peter
    Replies:
    3
    Views:
    725
    Michael Borgwardt
    Aug 5, 2004
  5. Polaris431
    Replies:
    8
    Views:
    755
    SM Ryan
    Dec 4, 2006
Loading...

Share This Page