Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > conversion of signed integer to unsigned integer

Reply
Thread Tools

conversion of signed integer to unsigned integer

 
 
junky_fellow@yahoo.co.in
Guest
Posts: n/a
 
      06-17-2005
Can anybody please explain this:

[ N869 6.3.1.3 ]

When a value with integer type is converted to another integer type
other than _Bool,
if the new type is unsigned, the value is converted by repeatedly
adding or subtracting one more than the maximum value that can be
represented in the new type until the value is in the range of the new
type.


Thanx ...

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      06-17-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> Can anybody please explain this:
>
> [ N869 6.3.1.3 ]
>
> When a value with integer type is converted to another integer type
> other than _Bool,
> if the new type is unsigned, the value is converted by repeatedly
> adding or subtracting one more than the maximum value that can be
> represented in the new type until the value is in the range of the new
> type.


unsigned short us; /* assume USHRT_MAX == 65535 */
us = -1000000;

The variable is unsigned, and not capable of expressing a
negative value. The assignment must set it to a non-negative
value, and 6.3.1.3 describes how that value is computed:

-1000000
+65536 (USHRT_MAX+1)
========
-934464
+65536
========
-868928
:
:
========
-16960
+65536
========
48576 (final answer, Regis)

Various computational shortcuts are available; all those
additions need not actually be peformed to get to the answer.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
junky_fellow@yahoo.co.in
Guest
Posts: n/a
 
      06-17-2005


Eric Sosman wrote:
> (E-Mail Removed) wrote:
>
> > Can anybody please explain this:
> >
> > [ N869 6.3.1.3 ]
> >
> > When a value with integer type is converted to another integer type
> > other than _Bool,
> > if the new type is unsigned, the value is converted by repeatedly
> > adding or subtracting one more than the maximum value that can be
> > represented in the new type until the value is in the range of the new
> > type.

>
> unsigned short us; /* assume USHRT_MAX == 65535 */
> us = -1000000;
>
> The variable is unsigned, and not capable of expressing a
> negative value. The assignment must set it to a non-negative
> value, and 6.3.1.3 describes how that value is computed:
>
> -1000000
> +65536 (USHRT_MAX+1)
> ========
> -934464
> +65536
> ========
> -868928
> :
> :
> ========
> -16960
> +65536
> ========
> 48576 (final answer, Regis)
>
> Various computational shortcuts are available; all those
> additions need not actually be peformed to get to the answer.
>
> --
> Eric Sosman
> (E-Mail Removed)lid


Consider,
signed char sc = -4; /* binary = 11111100 */
unsigned char uc = sc;

Now, if I print the value of sc it is 252 (binary 11111100).

So, if you see no conversion has been done. The bit values in
"uc" are exactly the same as in "sc".

Then, whats the need of performing so many additions/subtractions ?

 
Reply With Quote
 
Jean-Claude Arbaut
Guest
Posts: n/a
 
      06-17-2005

> Consider,
> signed char sc = -4; /* binary = 11111100 */
> unsigned char uc = sc;
>
> Now, if I print the value of sc it is 252 (binary 11111100).
>
> So, if you see no conversion has been done. The bit values in
> "uc" are exactly the same as in "sc".


Great confusion between bit pattern and actual value, here.
First, 252 = -4 + 256, needed to get a valid unsigned char.
Second, not all machines are 2-complement, though many are
nowadays.

As Eric said, there are computational shortcuts, and you
should note they depend on the machine (hence, on the
implementation of the standard). It's pure coincidence
if a signed char and an unsigned char have actually the same
representation for "s" and "256+s" respectively.

 
Reply With Quote
 
Jean-Claude Arbaut
Guest
Posts: n/a
 
      06-17-2005



Le 17/06/2005 15:49, dans BED8A19F.50FE%(E-Mail Removed),
«*Jean-Claude Arbaut*» <(E-Mail Removed)> a écrit*:

>
>> Consider,
>> signed char sc = -4; /* binary = 11111100 */
>> unsigned char uc = sc;
>>
>> Now, if I print the value of sc it is 252 (binary 11111100).
>>
>> So, if you see no conversion has been done. The bit values in
>> "uc" are exactly the same as in "sc".

>
> Great confusion between bit pattern and actual value, here.
> First, 252 = -4 + 256, needed to get a valid unsigned char.
> Second, not all machines are 2-complement, though many are
> nowadays.
>
> As Eric said, there are computational shortcuts, and you
> should note they depend on the machine (hence, on the
> implementation of the standard). It's pure coincidence
> if a signed char and an unsigned char have actually the same
> representation for "s" and "256+s" respectively.
>


Just for reference:

ISO 9899-1999, section 6.2.6.2#2 p39

 
Reply With Quote
 
Me
Guest
Posts: n/a
 
      06-17-2005
> Can anybody please explain this:
>
> When a value with integer type is converted to another integer type
> other than _Bool,
> if the new type is unsigned, the value is converted by repeatedly
> adding or subtracting one more than the maximum value that can be
> represented in the new type until the value is in the range of the new
> type.


It's basically describing a mod operation. Lets say you want to convert
any random signed integer to an unsigned int, a table of those values
looks like:

....
UINT_MAX+2 1
UINT_MAX+1 0
UINT_MAX UINT_MAX
UINT_MAX-1 UINT_MAX-1
UINT_MAX-2 UINT_MAX-2
....
2 2
1 1
0 0
-1 UINT_MAX
-2 UINT_MAX-1
....
-UINT_MAX+1 2
-UINT_MAX 1
-UINT_MAX-1 0
-UINT_MAX-2 UINT_MAX
-UINT_MAX-3 UINT_MAX-1
....

Where the left side is the signed integer value and the right side is
the resulting value when converted to unsigned int. I'm sure you can
figure it out from there.

 
Reply With Quote
 
Mac
Guest
Posts: n/a
 
      06-17-2005
On Fri, 17 Jun 2005 06:35:09 -0700, junky_fellow wrote:

>
>
> Eric Sosman wrote:
>> (E-Mail Removed) wrote:
>>
>> > Can anybody please explain this:
>> >
>> > [ N869 6.3.1.3 ]
>> >
>> > When a value with integer type is converted to another integer type
>> > other than _Bool,
>> > if the new type is unsigned, the value is converted by repeatedly
>> > adding or subtracting one more than the maximum value that can be
>> > represented in the new type until the value is in the range of the new
>> > type.

>>
>> unsigned short us; /* assume USHRT_MAX == 65535 */
>> us = -1000000;
>>
>> The variable is unsigned, and not capable of expressing a
>> negative value. The assignment must set it to a non-negative
>> value, and 6.3.1.3 describes how that value is computed:
>>
>> -1000000
>> +65536 (USHRT_MAX+1)
>> ========
>> -934464
>> +65536
>> ========
>> -868928
>> :
>> :
>> ========
>> -16960
>> +65536
>> ========
>> 48576 (final answer, Regis)
>>
>> Various computational shortcuts are available; all those
>> additions need not actually be peformed to get to the answer.
>>
>> --
>> Eric Sosman
>> (E-Mail Removed)lid

>
> Consider,
> signed char sc = -4; /* binary = 11111100 */
> unsigned char uc = sc;
>
> Now, if I print the value of sc it is 252 (binary 11111100).
>
> So, if you see no conversion has been done. The bit values in
> "uc" are exactly the same as in "sc".
>
> Then, whats the need of performing so many additions/subtractions ?


junky,

Eric is pretty sharp. He dumbed down his answer a bit because he was
afraid of confusing you. Your first post made it look like you were prone
to confusion. Your second post has not changed that appearance.

But now you are coming back like a smart-alec.

Even so, nothing in Eric's post is incorrect, as far as I can see, and
nothing in your followup contradicts anything in Eric's post.

He specifically said that the additions and/or subtractions need not
actually be performed to get the answer.

In the case of typical architectures, converting from unsigned to signed
of the same size may well be a no-op. The conversion really just means
that the compiler will change how it thinks of the bit pattern, not the
bit-pattern itself. As it turns out, this behavior satisfies the
mathematical rules laid out in the standard. This is probably not a
coincidence. I believe the intent of the rule was to force any non two's
complement architectures to emulate two's complement behavior. This is
convenient for programmers.

Even in the cases where a conversion from signed to unsigned involves
types of different sizes, typical architectures will have minimal work to
do to perform the conversion as specified in the standard. Non-typical
architectures, if there really are any, might have to do some arithmetic.

--Mac

 
Reply With Quote
 
Jean-Claude Arbaut
Guest
Posts: n/a
 
      06-17-2005



Le 17/06/2005 18:20, dans (E-Mail Removed), «*Mac*»
<(E-Mail Removed)> a écrit*:

> On Fri, 17 Jun 2005 06:35:09 -0700, junky_fellow wrote:



> In the case of typical architectures, converting from unsigned to signed
> of the same size may well be a no-op. The conversion really just means
> that the compiler will change how it thinks of the bit pattern, not the
> bit-pattern itself.


Only on 2-complement architectures, but the standard envisages three
possibilities.

On other machines, a negative signed char and its unsigned char counterpart
cannot have same bit pattern.

> As it turns out, this behavior satisfies the
> mathematical rules laid out in the standard. This is probably not a
> coincidence. I believe the intent of the rule was to force any non two's
> complement architectures to emulate two's complement behavior.


I don't see why. The additions required by the standard are on mathematical
values, not on registers. Sections 6.2.6.2 and 6.3.1.3 do no rely
particularly on (or emulate) 2-complement behaviour.



> This is
> convenient for programmers.
>
> Even in the cases where a conversion from signed to unsigned involves
> types of different sizes, typical architectures will have minimal work to
> do to perform the conversion as specified in the standard. Non-typical
> architectures, if there really are any, might have to do some arithmetic.


At least there were. IBM 704 had 36 bits words, with 1 sign bit and 35 bits
of magnitude. There may be more modern machines with same kind of
arithmetic, I just looked for one Reference is: "IBM 704, Manual
Of Operation, 1955" at www.bitsavers.org. Of course nothing to do with the C
language, just an example of a different machine. If anybody knows of modern
ones, I'm of course interested.


 
Reply With Quote
 
Lawrence Kirby
Guest
Posts: n/a
 
      06-17-2005
On Fri, 17 Jun 2005 06:35:09 -0700, junky_fellow wrote:

....

> Consider,
> signed char sc = -4; /* binary = 11111100 */


That is the representation on your implementation, it may be something
else on another implementation.

> unsigned char uc = sc;
>
> Now, if I print the value of sc it is 252 (binary 11111100).
>
> So, if you see no conversion has been done.


Yes it has. You had a value of -4, now you have a value of 252. A very
real conversion has happened that has produced a different value.

> The bit values in
> "uc" are exactly the same as in "sc".


That's a happy coincidence, well not entirely a coincidence. The
conversion rules are designed to be efficiently implementable on common
architectures as well as being useful.

The underlying representation is not important, the result of the
conversion is defined on VALUES. You stared with a value and following the
conversion rules you added (UCHAR_MAX+1) in this case 256 to produce a
result of 252. You didn't need to know anything about the underlying
representation to determine that. On a 1's complement implementation -4
would be represented in 8 bits as 11111011, but uc = sc would still
produce the result 252 because the conversion is defined in terms of
value. On such systems the implementation must change the representation
to produce the correct result. That's the price you pay for portability
and consistent results.

> Then, whats the need of performing so many additions/subtractions ?


The additions/subtractions are just a means in the standard to specify
what the correct result should be. In practice a compiler would not
perform lots of additions or subtractions to actually calculate the result.

As you've noted in a lot of cases it doesn't have to do anything at all
except reinterpret a bit pattern according to a new type.

Lawrence
 
Reply With Quote
 
Mac
Guest
Posts: n/a
 
      06-17-2005
On Fri, 17 Jun 2005 18:46:03 +0200, Jean-Claude Arbaut wrote:

> Le 17/06/2005 18:20, dans (E-Mail Removed), «*Mac*»
> <(E-Mail Removed)> a écrit*:
>
>> On Fri, 17 Jun 2005 06:35:09 -0700, junky_fellow wrote:

>
>
>> In the case of typical architectures, converting from unsigned to signed
>> of the same size may well be a no-op. The conversion really just means
>> that the compiler will change how it thinks of the bit pattern, not the
>> bit-pattern itself.

>
> Only on 2-complement architectures, but the standard envisages three
> possibilities.


Right. As far as I'm concerned, all typical architectures use two's
complement representations. Also note I say "may well be," not "is" or
"must be."

[snip]
>> As it turns out, this behavior satisfies the
>> mathematical rules laid out in the standard. This is probably not a
>> coincidence. I believe the intent of the rule was to force any non two's
>> complement architectures to emulate two's complement behavior.

>
> I don't see why. The additions required by the standard are on mathematical
> values, not on registers. Sections 6.2.6.2 and 6.3.1.3 do no rely
> particularly on (or emulate) 2-complement behaviour.
>
>


I'm only talking about the conversion from signed to unsigned here. The
rule doesn't explicitly say that the result must be the same as if two's
complement representation is used, but that is the result. Why would this
be a coincidence?

Probably the folks writing the standard did not want to leave
signed-to-unsigned conversions implementation-defined, so they specified
the behavior to be the most natural thing for two's-complement machines.
This is just a guess on my part.

I did not mean to make any claims regarding any other arithmetic
issues.

>
>> This is
>> convenient for programmers.
>>
>> Even in the cases where a conversion from signed to unsigned involves
>> types of different sizes, typical architectures will have minimal work to
>> do to perform the conversion as specified in the standard. Non-typical
>> architectures, if there really are any, might have to do some arithmetic.

>
> At least there were. IBM 704 had 36 bits words, with 1 sign bit and 35 bits
> of magnitude. There may be more modern machines with same kind of
> arithmetic, I just looked for one Reference is: "IBM 704, Manual
> Of Operation, 1955" at www.bitsavers.org. Of course nothing to do with the C
> language, just an example of a different machine. If anybody knows of modern
> ones, I'm of course interested.


On a system which uses sign-magnitude representation, aren't all positive
integers represented the same way, regardless of whether the type is
signed or unsigned? Or is the sign convention that 1 is positive?

Anyway, I know there are lots of architectures out there, but I hesitate
to call most of them typical. And non two's-complement machines seem to be
getting rarer with every passing decade. Note that I am not advocating
ignoring the standard, or writing code which has undefined behavior.

--Mac

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned):I'll loose something? pozz C Programming 12 03-20-2011 11:32 PM
unsigned int with signed long int (same width) - how is conversion done? G Fernandes C Programming 2 02-16-2005 10:55 AM
Conversion from Unsigned to Signed for bitwise. codefixer@gmail.com C Programming 3 02-04-2005 07:03 AM
Explicit unsigned/signed conversion: ANSI/ISO rules? Ken Tough C Programming 4 06-08-2004 04:38 PM
silly unsigned/signed byte conversion question aspa Java 9 10-29-2003 10:37 PM



Advertisments