unsigned char --> int conversion
Author Message
unsigned char --> int conversion

What is the portable way of converting an unsigned char into an integer?

Sun, 02 Jan 2005 23:26:13 GMT
unsigned char --> int conversion

Quote:
> What is the portable way of converting an unsigned char into an integer?

I'm not sure, but I think S. 6.3.1.3 (ISO/IEC 9899:1999, p 43) answers your
question:

"1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type, it is
unchanged."

Since all the values in an unsigned char (0-255) can be represented by
'int', it should be right to simply do:

unsigned char uc;
int i;

...
i = (int) uc;

or even simpler

i = uc;

HTH (HIR :)

Matt

Sun, 02 Jan 2005 23:31:53 GMT
unsigned char --> int conversion

Quote:

> What is the portable way of converting an unsigned char into an integer?

An unsigned char is already an integer.

Mon, 03 Jan 2005 00:09:25 GMT
unsigned char --> int conversion

Quote:

> What is the portable way of converting an unsigned char into an integer?

AFAIK, there is no completely portable way.  On my
Deathstation 9000 (getting a little old now), it happens
that sizeof(int)==1 and that INT_MAX < UCHAR_MAX, so the
value of an unsigned char could exceed the range of an
int.  The conversion of an out-of-range value yields the
implementation-defined result -42 (on even-numbered days)
or raises SIGBOGUS (on odd-numbered days).

If the unsigned char value originated from reading a
text stream, I think the problem doesn't arise.  We know
that getc() returns an int whose value is either EOF or
equal to the value of the input character taken as an
unsigned char and converted to an int.  I think this
implies that all actual characters have values that can
be represented in an int; if UCHAR_MAX > INT_MAX it will
turn out that actual character encodings use only part
of the unsigned char range.  (I'm not 100% certain of
this interpretation, though: it could also be supposed
that getc() can convert the out-of-range unsigned char
to an int by means of Implementation Magic not available
to the user program.)

On real machines, just assign or cast.  (And I bet the
next TLA you read will be "DSP.")

--

Mon, 03 Jan 2005 00:08:48 GMT
unsigned char --> int conversion

Quote:

>> What is the portable way of converting an unsigned char into an integer?

> I'm not sure, but I think S. 6.3.1.3 (ISO/IEC 9899:1999, p 43) answers your
> question:

> "1 When a value with integer type is converted to another integer type
> other than _Bool, if the value can be represented by the new type, it is
> unchanged."

> Since all the values in an unsigned char (0-255) can be represented by
> 'int', it should be right to simply do:

But there are cases where not all values of a unsigned char can
be represented in an int. It is possible that sizeof(int) == 1,
for example on a system with 32Bit chars and ints. On such a
system a unsigned char with a value of  say 2147483648 would
overflow and in int and that would be handled in some system
specific way. So it is probably necessary to do

unsigned char uc = 2147483648;
int i = 0;

i = uc % ((unsigned int)INT_MAX + 1);

explicitly, so that we don't enter the system specific area.

That would be unnecessary for systems where UCHAR_MAX was
smaller than or equal to INT_MAX.
--

"LISP  is worth learning for  the profound enlightenment  experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days."   -- Eric S. Raymond

Mon, 03 Jan 2005 00:47:19 GMT
unsigned char --> int conversion

Quote:

> What is the portable way of converting an unsigned char into an integer?

You'll have to explain more about what you want. What is the value of
the unsigned char? Is it a character representation of a numeral, like
'8', or is a number you've stored there, irrespective of its character
value?

Brian Rodenborn

Mon, 03 Jan 2005 01:05:49 GMT
unsigned char --> int conversion

Quote:

>> What is the portable way of converting an unsigned char into an
integer?

>     AFAIK, there is no completely portable way.  On my
> Deathstation 9000 (getting a little old now), it happens
> that sizeof(int)==1 and that INT_MAX < UCHAR_MAX, so the
> value of an unsigned char could exceed the range of an
> int.  The conversion of an out-of-range value yields the
> implementation-defined result -42 (on even-numbered days)
> or raises SIGBOGUS (on odd-numbered days).

>     If the unsigned char value originated from reading a
> text stream, I think the problem doesn't arise.  We know
> that getc() returns an int whose value is either EOF or
> equal to the value of the input character taken as an
> unsigned char and converted to an int.  I think this
> implies that all actual characters have values that can
> be represented in an int; if UCHAR_MAX > INT_MAX it will
> turn out that actual character encodings use only part
> of the unsigned char range.  (I'm not 100% certain of
> this interpretation, though: it could also be supposed
> that getc() can convert the out-of-range unsigned char
> to an int by means of Implementation Magic not available
> to the user program.)

>     On real machines, just assign or cast.  (And I bet the
> next TLA you read will be "DSP.")

Hmm... what about the part of 9899:1999 that says:

"5.2.4.2.1 Sizes of integer types <limits.h>
1 The values given below shall be replaced by constant expressions
suitable for use in #if preprocessing directives. Moreover, except for
CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions
that have the same type as would an expression that is an object of the
corresponding type converted according to the integer promotions. Their
implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign."

It lists, in the table that follows, that:

maximum value for an object of type unsigned char
UCHAR_MAX 255 // 2^8 - 1

maximum value for an object of type int
INT_MAX +32767 // 2^15 - 1

So sizeof (int) can never be 1, right?

So does that mean that your DS 9000 does not have a conforming
implementation?

Mon, 03 Jan 2005 01:35:16 GMT
unsigned char --> int conversion

Quote:

> "5.2.4.2.1 Sizes of integer types <limits.h>
> 1 The values given below shall be replaced by constant expressions
> suitable for use in #if preprocessing directives. Moreover, except for
> CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions
> that have the same type as would an expression that is an object of the
> corresponding type converted according to the integer promotions. Their
> implementation-defined values shall be equal or greater in magnitude
> (absolute value) to those shown, with the same sign."

> It lists, in the table that follows, that:

> - maximum value for an object of type unsigned char
> UCHAR_MAX 255 // 2^8 - 1

> - maximum value for an object of type int
> INT_MAX +32767 // 2^15 - 1

> So sizeof (int) can never be 1, right?

Note the final quoted sentence: the listed values are minima
(in magnitude), and an implementation can exceed those minima.
sizeof(int) must be >1 if CHAR_BIT is <16, but on a machine
with 16-bit or wider characters sizeof(int) could perfectly
well be 1.

Quote:
> So does that mean that your DS 9000 does not have a conforming
> implementation?

The DeathStation 9000 is designed and manufactured by Armed
Response Technologies, who have made every effort to comply with
the Standard's every provision while violating its every intent
as egregiously as possible.  ART may, of course, have blundered.
But considering the other hardware they deploy (see their Web
site at http://dialspace.dial.pipex.com/town/green/gfd34/art/)
and their attitude about using it (see ditto), I don't want to
be the first to file a bug report.

--

Mon, 03 Jan 2005 03:00:30 GMT
unsigned char --> int conversion

...

Quote:

> Hmm... what about the part of 9899:1999 that says:

> "5.2.4.2.1 Sizes of integer types <limits.h>
> 1 The values given below shall be replaced by constant expressions
> suitable for use in #if preprocessing directives. Moreover, except for
> CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions
> that have the same type as would an expression that is an object of the
> corresponding type converted according to the integer promotions. Their
> implementation-defined values shall be equal or greater in

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Quote:
> magnitude (absolute value) to those shown, with the same

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sign."
^^^^^^

Quote:

> It lists, in the table that follows, that:

> maximum value for an object of type unsigned char
> UCHAR_MAX 255 // 2^8 - 1

> maximum value for an object of type int
> INT_MAX +32767 // 2^15 - 1

> So sizeof (int) can never be 1, right?

> So does that mean that your DS 9000 does not have a conforming
> implementation?

"equal or greater" allows for

sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) ==
sizeof(long long) == sizeof(float) == sizeof(double) ==
sizeof(unsigned char) == sizeof(unsigned short) ==
sizeof(unsigned int) == sizeof(unsigned long) ==
sizeof(unsigned long long)

with SCHAR_MAX == SHORT_MAX == INT_MAX == LONG_MAX == LLONG_MAX

and UCHAR_MAX ==  USHORT_MAX == UINT_MAX == ULONG_MAX ==
ULLONG_MAX

but UCHAR_MAX > LLONG_MAX

--

"LISP  is worth learning for  the profound enlightenment  experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days."   -- Eric S. Raymond

Mon, 03 Jan 2005 13:54:02 GMT

 Page 1 of 1 [ 9 post ]

Relevant Pages