Asp Forum - int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned): I'll loose something?

pozz

3/18/2011 10:06:00 AM

int x = <value>;
int y = (int)((unsigned)x);

The value of y is the same of x for any starting value and C
implementation?

unsigned int x = <value>;
unsigned int y = (unsigned)((int)x);

And in this case?

In other words, is there a risk to loose any value switching from
signed to unsigned and viceversa representation of integers?

13 Answers

Ben Bacarisse

3/18/2011 11:46:00 AM

pozz <pozzugno@gmail.com> writes:

> int x = <value>;
> int y = (int)((unsigned)x);
>
> The value of y is the same of x for any starting value and C
> implementation?
>
> unsigned int x = <value>;
> unsigned int y = (unsigned)((int)x);
>
> And in this case?

Neither case is safe. Both can involve an out-of-range conversion from
unsigned to int. This is something that you might choose to live with.
In most cases the conversion is implementation defined[1] and will be
defined to do the "obvious" thing.

You can avoid a conversion by "type punning" using either a union or a
pointer conversion:

unsigned u = /* ... */;
int s = *(int *)&u;

This swaps the problem to one of representations. Rather than relying
on the conversion of an out of range value you reply on there being no
unsigned int bit patterns that are not valid signed int representations.
I don't know of any implementations where this is a problem but it is
permitted (by 6.2.6.2 paragraph 2).

As I've alread posted, you can get round both issues if you really need
to.

<snip>

[1] The C standard includes permission to raise a signal but this is not
often done as far as I know.

--
Ben.

pete

3/18/2011 11:57:00 AM

pozz wrote:
>
> int x = <value>;
> int y = (int)((unsigned)x);
>
> The value of y is the same of x for any starting value and C
> implementation?

If <value> is (-1),
then the value of (y) is equal to (int)UINT_MAX.

The value of UINT_MAX is implementation defined.

The value of (int)UINT_MAX may
again be implementation defined
depending on whether UINT_MAX is greater than INT_MAX.

Whether or not UINT_MAX is greater than INT_MAX,
is implementation defined.

--
pete

Eric Sosman

3/18/2011 12:35:00 PM

On 3/18/2011 6:06 AM, pozz wrote:
> int x =<value>;
> int y = (int)((unsigned)x);
>
> The value of y is the same of x for any starting value and C
> implementation?

No. Suppose x is negative. Since an unsigned value cannot be
negative, the (unsigned)x conversion produces a different value
UINT_MAX+x+1. This value is quite likely to be larger than INT_MAX,
so converting it to plain int again produces an implementation-defined
result or raises an implementation-defined signal.

On most C implementations the "implementation-defined result"
turns out to be x, but that's not guaranteed by the language and
can't be counted on for "any" C implementation.

> unsigned int x =<value>;
> unsigned int y = (unsigned)((int)x);
>
> And in this case?

Similar problem: If the value of x is greater than INT_MAX,
converting that value to int is problematic.

> In other words, is there a risk to loose any value switching from
> signed to unsigned and viceversa representation of integers?

Yes. (By the way, "vice versa" is a two-word phrase. Also,
"loose" is a perfectly good verb, but it doesn't mean "lose.")

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

pozz

3/18/2011 1:39:00 PM

On 18 Mar, 12:46, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Neither case is safe. Both can involve an out-of-range conversion from
> unsigned to int.

Hmm..., and what happens with printf, for example:
unsigned int x = UINT_MAX;
printf ("x=%u\n", x);

Is x converted to int (signed) when it is pushed onto the stack as an
argument for printf? Or maybe it is untouched onto the stack when the
parameter is one of the variable arguments (as happens in printf)?

pozz

3/18/2011 1:55:00 PM

On 18 Mar, 13:34, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > In other words, is there a risk to loose any value switching from
> > signed to unsigned and viceversa representation of integers?
>
> Yes. (By the way, "vice versa" is a two-word phrase. Also,
> "loose" is a perfectly good verb, but it doesn't mean "lose.")

I'm sorry, I don't know C language as English languange :-)

Ben Bacarisse

3/18/2011 3:08:00 PM

Keith Thompson

3/18/2011 3:44:00 PM

pozz <pozzugno@gmail.com> writes:
> On 18 Mar, 12:46, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Neither case is safe. Â Both can involve an out-of-range conversion from
>> unsigned to int.
>
> Hmm..., and what happens with printf, for example:
> unsigned int x = UINT_MAX;
> printf ("x=%u\n", x);
>
> Is x converted to int (signed) when it is pushed onto the stack as an
> argument for printf? Or maybe it is untouched onto the stack when the
> parameter is one of the variable arguments (as happens in printf)?

No, there is no conversion and no problem. The value of x is passed
as an argument to printf (this probably involves pushing it onto the
stack in most implementations, but the mechanism is irrelevant).
The "%u" tells printf to expect an unsigned argument -- which is
exactly what you gave it. There's no int in sight (other than
the value returned by printf).

If you had used a "%d" format rather than "%u", then the behavior
would be undefined. There would still be no *conversion*; instead,
printf would most likely try to interpret the passed unsigned
int value as if it were of type int. The behavior is likely
to be what you'd expect, but the standard doesn't guarantee it.
(There's a special-case guarantee for the case where the value is
within the range of both types, but that doesn't apply here, since
UINT_MAX is outside the range of int.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

puppi

3/20/2011 1:48:00 AM

On Mar 18, 7:06 am, pozz <pozzu...@gmail.com> wrote:
> int x = <value>;
> int y = (int)((unsigned)x);
>
> The value of y is the same of x for any starting value and C
> implementation?
>
> unsigned int x = <value>;
> unsigned int y = (unsigned)((int)x);
>
> And in this case?
>
> In other words, is there a risk to loose any value switching from
> signed to unsigned and viceversa representation of integers?

No. There is no risk. Unsigned and signed integers are the same: they
only differ in how the sign bit is interpreted. y will be exactly x,
ALWAYS. If y was signed, on the other hand, the value could be
different (if and only if it was interpreted as negative, i.e. the
sign bit was set), but the binary content would be rigorously the
same. Even in the case that y were signed, (unsigned)y would be
exactly x. That's because since the binary content is not modified, a
conversion that in the end converts back to the original type will
mean exatcly the same thing.

Keith Thompson

3/20/2011 2:14:00 AM

puppi <fabricio.puppi@gmail.com> writes:
> On Mar 18, 7:06Â am, pozz <pozzu...@gmail.com> wrote:
>> int x = <value>;
>> int y = (int)((unsigned)x);
>>
>> The value of y is the same of x for any starting value and C
>> implementation?
>>
>> unsigned int x = <value>;
>> unsigned int y = (unsigned)((int)x);
>>
>> And in this case?
>>
>> In other words, is there a risk to loose any value switching from
>> signed to unsigned and viceversa representation of integers?
>
> No. There is no risk. Unsigned and signed integers are the same: they
> only differ in how the sign bit is interpreted. y will be exactly x,
> ALWAYS. If y was signed, on the other hand, the value could be
> different (if and only if it was interpreted as negative, i.e. the
> sign bit was set), but the binary content would be rigorously the
> same. Even in the case that y were signed, (unsigned)y would be
> exactly x. That's because since the binary content is not modified, a
> conversion that in the end converts back to the original type will
> mean exatcly the same thing.

What you say is true for many (most) implementations, but it's not
at all guaranteed by the language.

Integer types can have padding bits and/or trap representations.
signed and unsigned int, for example, might not necessarily be
able to represent the same number of values; (signed) int might
have two different representations for zero.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

puppi

3/20/2011 5:40:00 AM

On Mar 19, 11:14 pm, Keith Thompson <ks...@mib.org> wrote:
> puppi <fabricio.pu...@gmail.com> writes:
> > On Mar 18, 7:06 am, pozz <pozzu...@gmail.com> wrote:
> >> int x = <value>;
> >> int y = (int)((unsigned)x);
>
> >> The value of y is the same of x for any starting value and C
> >> implementation?
>
> >> unsigned int x = <value>;
> >> unsigned int y = (unsigned)((int)x);
>
> >> And in this case?
>
> >> In other words, is there a risk to loose any value switching from
> >> signed to unsigned and viceversa representation of integers?
>
> > No. There is no risk. Unsigned and signed integers are the same: they
> > only differ in how the sign bit is interpreted. y will be exactly x,
> > ALWAYS. If y was signed, on the other hand, the value could be
> > different (if and only if it was interpreted as negative, i.e. the
> > sign bit was set), but the binary content would be rigorously the
> > same. Even in the case that y were signed, (unsigned)y would be
> > exactly x. That's because since the binary content is not modified, a
> > conversion that in the end converts back to the original type will
> > mean exatcly the same thing.
>
> What you say is true for many (most) implementations, but it's not
> at all guaranteed by the language.
>
> Integer types can have padding bits and/or trap representations.
> signed and unsigned int, for example, might not necessarily be
> able to represent the same number of values; (signed) int might
> have two different representations for zero.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.ne...
> Nokia
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"

You're correct, of course. I was assuming that signed integers were
represented in two complement's form. Is there any (major) current
implementation that disagrees with that?

comp.lang.c

int) -> (unsigned) -> (int) or (unsigned) -> (int) -> (unsigned): I'll loose something?

pozz

Ben Bacarisse

pete

Eric Sosman

pozz

pozz

Ben Bacarisse

Keith Thompson

puppi

Keith Thompson

puppi

x Login to ForumsZone