Velocity Reviews > unsigned to signed integer convesion

# unsigned to signed integer convesion

junky_fellow@yahoo.co.in
Guest
Posts: n/a

 08-08-2005
How the unsigned to signed integet conversion is done ?
For eg:

unsigned int ui = 100;
int si = ui;

What will be the value if "si" is printed ? How this conversion
is done ?

Thanx for any help in advance ....

Robert Gamble
Guest
Posts: n/a

 08-08-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> How the unsigned to signed integet conversion is done ?
> For eg:
>
> unsigned int ui = 100;
> int si = ui;
>
> What will be the value if "si" is printed ? How this conversion
> is done ?

si will be 100, the value of ui is converted to the type of si (signed
int) and the result is stored in si. If the value of ui is larger than
INT_MAX (which it isn't in this case), overflow will occur during this
conversion process resulting in undefined behavior.

Robert Gamble

Keith Thompson
Guest
Posts: n/a

 08-08-2005
(E-Mail Removed) writes:
> How the unsigned to signed integet conversion is done ?

C99 6.3.1.3:

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.

Otherwise, 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. (Footnote: The rules describe arithmetic
on the mathematical value, not the value of a given type of
expression.)

Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined or
an implementation-defined signal is raised.

> For eg:
>
> unsigned int ui = 100;
> int si = ui;
>
> What will be the value if "si" is printed ? How this conversion
> is done ?

Since both unsigned int and int are guaranteed to be able to represent
the value 100, the value of si will be 100.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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
Guest
Posts: n/a

 08-08-2005
"Robert Gamble" <(E-Mail Removed)> writes:
> (E-Mail Removed) wrote:
>> How the unsigned to signed integet conversion is done ?
>> For eg:
>>
>> unsigned int ui = 100;
>> int si = ui;
>>
>> What will be the value if "si" is printed ? How this conversion
>> is done ?

>
> si will be 100, the value of ui is converted to the type of si (signed
> int) and the result is stored in si. If the value of ui is larger than
> INT_MAX (which it isn't in this case), overflow will occur during this
> conversion process resulting in undefined behavior.

No, the rules for conversions are different from the rules for
arithmetic operators.

When converting a signed or unsigned type to an unsigned type,
the result is well-defined (it wraps around).

When converting a signed or unsigned type to an unsigned type, if the
result can't be represented, either the result is
implementation-defined or an implementation-defined signal is raised.
No nasal demons are allowed.

See my other response in this thread for the standard's definition.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.

Eric Sosman
Guest
Posts: n/a

 08-08-2005

Keith Thompson wrote:
> "Robert Gamble" <(E-Mail Removed)> writes:
>
>>(E-Mail Removed) wrote:
>>
>>>How the unsigned to signed integet conversion is done ?
>>>For eg:
>>>
>>>unsigned int ui = 100;
>>>int si = ui;
>>>
>>>What will be the value if "si" is printed ? How this conversion
>>>is done ?

>>
>>si will be 100, the value of ui is converted to the type of si (signed
>>int) and the result is stored in si. If the value of ui is larger than
>>INT_MAX (which it isn't in this case), overflow will occur during this
>>conversion process resulting in undefined behavior.

>
>
> No, the rules for conversions are different from the rules for
> arithmetic operators.
>
> When converting a signed or unsigned type to an unsigned type,
> the result is well-defined (it wraps around).
>
> When converting a signed or unsigned type to an unsigned type, if the
> result can't be represented, either the result is
> implementation-defined or an implementation-defined signal is raised.
> No nasal demons are allowed.

The conversion doesn't yield undefined behavior, but
it yields something very nearly as good (if that's the right
word). The raising of the implementation-defined signal is
the moment when the behavior becomes if not undefined at least
unreliable. It's up to the implementation whether the signal
is treated as if with SIG_IGN or SIG_DFL; it's also up to the
implementation just what's involved in SIG_DFL for each signal.
If you install a handler, things *do* become undefined:

7.14.1.1/3
[...] If and when the function returns, if the value
of sig is [any] value corresponding to a computational
exception, the behavior is undefined; [...]

So the only way to handle the signal without invoking U.B. is
to terminate the program by calling abort() or _Exit() in the
handler. The signal is fatal unless it is SIG_IGN'ed (if the
implementation permits it) or SIG_DFL'ed with an implementation-
defined handling that itself isn't fatal.

So, yes: You're right, and the behavior is not undefined
unless a signal handler tries to return. But that's a bit
like the observation that falling from atop a forty-story
building won't hurt you -- the fall is harmless, but watch
out for that sudden stop at the bottom ...

--

Alexei A. Frounze
Guest
Posts: n/a

 08-08-2005
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> How the unsigned to signed integet conversion is done ?
> For eg:
>
> unsigned int ui = 100;
> int si = ui;
>
> What will be the value if "si" is printed ? How this conversion
> is done ?
>
> Thanx for any help in advance ....

There's one more problem related to what's being discussed in "find out the
problem" by me and others...
Shamefully, but I had to fix a few bugs in my recent code... The code was
something like this:

typedef uint unsigned int;

void drawlineh (int x, int y, uint len, uint color)
{
if (x+len < 0)
return;
// the rest of code that's properly working...
}

The problem is that x gets converted to unsigned int in the expression
"x+len" and hence for negative x I wouldn't have the desired return from the
function.
This is really an annoying feature of C... The only way to make it work w/o
changing the API (i.e. making len of type int too) is to do a cast:

if (x+(int)len < 0)
return;

That makes me love asm more and more. Asm is the simplest programming
language ever -- I always know what the code does and I know that for all
bugs and problems it's me to blame. But C is such a wonderful creature,
no surprise so many people get it all wrong. They have always been getting
it wrong and they continue to do so. At times it's so counter intuitive for
an HLL. And it seems like most (or all) the books on C that I had in the
past never really described all this conversion well. I don't know if recent
do (now's the time to get it right finally!), but these days I always check
either in the standard or in the code if there's a doubt about something.
Thankfully, I'm not writing bad code for I know many things outside the C
scope... I don't wonder now that I should declare a variable before using it
(Hello Basic, matlab, etc users!, I don't wonder now about the range and
precision of fixed and floating point things, etc etc.

If I were to change C, I'd change the conversions/promotions to be more
math-like, not C-like. But that's not going to happen anytime soon. Sigh.

Alex

Old Wolf
Guest
Posts: n/a

 08-08-2005
Alexei A. Frounze wrote:
> if (x+len < 0)
> return;
>
> The problem is that x gets converted to unsigned int in the expression
> "x+len" and hence for negative x I wouldn't have the desired return from the
> function.
> This is really an annoying feature of C... The only way to make it work w/o
> changing the API (i.e. making len of type int too) is to do a cast:
>
> if (x+(int)len < 0)
> return;

What if len > INT_MAX ?

> That makes me love asm more and more. Asm is the simplest programming
> language ever -- I always know what the code does and I know that for all
> bugs and problems it's me to blame.

So how would you compare -2000000000 and +3000000000 in ASM,
without something at least as complicated as you would do in C ?

Alexei A. Frounze
Guest
Posts: n/a

 08-08-2005
"Old Wolf" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Alexei A. Frounze wrote:
> > if (x+len < 0)
> > return;
> >
> > The problem is that x gets converted to unsigned int in the expression
> > "x+len" and hence for negative x I wouldn't have the desired return from

the
> > function.
> > This is really an annoying feature of C... The only way to make it work

w/o
> > changing the API (i.e. making len of type int too) is to do a cast:
> >
> > if (x+(int)len < 0)
> > return;

>
> What if len > INT_MAX ?

Right. And using long would help neither on msvc++ nor on gcc on x86.
int=long there. Only long long would do, but I guess it would be _int64 or
something in terms of m\$.

> > That makes me love asm more and more. Asm is the simplest programming
> > language ever -- I always know what the code does and I know that for

all
> > bugs and problems it's me to blame.

>
> So how would you compare -2000000000 and +3000000000 in ASM,
> without something at least as complicated as you would do in C ?

At least I would know about it for sure, w/o special books and standards

Am I the only who feels uncomfortable with certain aspects of C? Or is there
anyone who understands a bit of my concerns?

Alex

Chris Croughton
Guest
Posts: n/a

 08-08-2005
On Tue, 9 Aug 2005 00:44:30 +0400, Alexei A. Frounze
<(E-Mail Removed)> wrote:

> Shamefully, but I had to fix a few bugs in my recent code... The code was
> something like this:
>
> typedef uint unsigned int;
>
> void drawlineh (int x, int y, uint len, uint color)
> {
> if (x+len < 0)
> return;
> // the rest of code that's properly working...
> }
>
> The problem is that x gets converted to unsigned int in the expression
> "x+len" and hence for negative x I wouldn't have the desired return from the
> function.

Several popular compilers will warn you about that if you enable
warnings, because the condition can never be true so the statements
after it are unreachable.

> This is really an annoying feature of C... The only way to make it work w/o
> changing the API (i.e. making len of type int too) is to do a cast:
>
> if (x+(int)len < 0)
> return;

If that's what you mean then do it -- but if len is larger than MAXINT
it will have undefined effect so you need to check for that first.

> That makes me love asm more and more. Asm is the simplest programming
> language ever -- I always know what the code does and I know that for all
> bugs and problems it's me to blame.

And is totally non-portable. Even between assemblers for the same
platform.

> But C is such a wonderful creature,
> no surprise so many people get it all wrong. They have always been getting
> it wrong and they continue to do so. At times it's so counter intuitive for
> an HLL.

But different people find different parts of it counter-intuitive,
that's the problem, and same is true for all other programming
languages. Including asssembler.

NOT R1
BIC R1, R0

AND R1, R0

And many other oddities which only make sense if you know a particular
processor in detail.

> And it seems like most (or all) the books on C that I had in the
> past never really described all this conversion well. I don't know if recent
> do (now's the time to get it right finally!), but these days I always check
> either in the standard or in the code if there's a doubt about something.

Yup. At least the C standard is clearer than the C++ standard...

> Thankfully, I'm not writing bad code for I know many things outside the C
> scope... I don't wonder now that I should declare a variable before using it
> (Hello Basic, matlab, etc users!, I don't wonder now about the range and
> precision of fixed and floating point things, etc etc.
>
> If I were to change C, I'd change the conversions/promotions to be more
> math-like, not C-like. But that's not going to happen anytime soon. Sigh.

And would confuse many more. C was written for systems programmers,
largely, and so was designed tro do what you told it and nothing more.
So if you want to do some conversions other than the default, you do
them. C is not designed for mathematics (try FORTRAN -- "FORmula
TRANslation"), so you get 1/2 == 0 because that is what is expected in
integer arithmetic even though it isn't in mathematics, and if you then
assign the result to a floating point variable it sets it to zero.

It's certainly not perfect, at least one of the original authors of the
language has admitted that the precedence of some of the operators was
wrong, but there is by now no chance of changing it because there is too
much code which depends on it. Just as with natural language, we can't
just change English spelling to something more lojikal at a wim, evn tho
sum pepl hav trid to do that. Except it's worse with computer languages
because you can probably understand what I wrote where a compiler
can't...

(And yes, I know that the Cyrillic alphabet did have several letters
removed as an act of the government, but that can only be done when the
government can say that all books in the previous script have to be
replaced and be obeyed...)

Chris C

Keith Thompson
Guest
Posts: n/a

 08-09-2005
"Alexei A. Frounze" <(E-Mail Removed)> writes:
> "Old Wolf" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...

[...]
>> So how would you compare -2000000000 and +3000000000 in ASM,
>> without something at least as complicated as you would do in C ?

>
> At least I would know about it for sure, w/o special books and standards

There are no special books for assembly language?

> Am I the only who feels uncomfortable with certain aspects of C? Or is there
> anyone who understands a bit of my concerns?

I'd be suspicious of anyone who *wasn't* uncomfortable with some
aspects of C. K&R themselves (or at least K and/or R) have expressed
misgivings about some of the design choices.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.