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

[pozz]

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?

 

[Ben Bacarisse]

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.

 

[Eric Sosman]

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

 

[pozz]

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]

     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]

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, you are passing an unsigned int not an it. The default argument
promotions don't affect unsigned int.

 

[Keith Thompson]

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

 

[puppi]

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]

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.

 

[puppi]

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) (e-mail address removed)  <http://www.ghoti.net/~kst>
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?

 

[Keith Thompson]

You're correct, of course. I was assuming that signed integers were
represented in two complement's form.

You were also (implicitly) assuming that the most negative
representable value isn't treated as a trap representation, and
that unsigned-to-signed conversion for values exceeding INT_MAX
works as expected (it's implementation-defined).

Is there any (majorm) current
implementation that disagrees with that?

I don't believe there are any conforming *hosted* implementations
that don't meet those assumptions. There tends to be more variation
among freestanding implementations, but I don't know the details.

 

[Peter Nilsson]

pozz <[email protected]> writes:

Neither case is safe.  Both can involve an out-of-range
conversion from unsigned to int.

More subtle is the case...

unsigned short x = USHRT_MAX;
unsigned short y = ++x;

The second initialisor expression can overflow if USHRT_MAX <=
INT_MAX. Since ++x is just shorthand for x = x + 1, the sub-
expression x + 1 can overflow if x is promoted to int and not
unsigned int. That can be true even if USHRT_MAX == UINT_MAX in
the case where UINT_MAX == INT_MAX.

 

[Tim Rentsch]

pozz <[email protected]> writes:

Neither case is safe. Both can involve an out-of-range
conversion from unsigned to int.

More subtle is the case...

unsigned short x = USHRT_MAX;
unsigned short y = ++x;

The second initialisor expression can overflow if USHRT_MAX <=
INT_MAX. [snip elaboration]

Presumably you mean ++x can overflow if USHRT_MAX == INT_MAX.
There is no overflow if USHRT_MAX < INT_MAX.