possible bug in CW 8.3 (PowerPC)

possible bug in CW 8.3 (PowerPC)

Post by yaron » Thu, 12 Aug 2004 20:21:52


Hi,

Assume the following code
long a = 99999;
unsigned short b = a;

Now b is -31073.

It makes sense to me that such a cast would truncate the long, but the
result seems strange. The compiler outputs a command extsh from a's
register to b's register.

Is that Ok, or is it a bug??

Thanx
Yaron Tamor
 
 
 

possible bug in CW 8.3 (PowerPC)

Post by Dana Cartw » Thu, 12 Aug 2004 22:46:51

When the computer truncates a long to a short, what result would you expect?
That is, do you have any formal definition of what truncation does? And is
the computer violating this definition?

Here is how I view your assignment: "Given two signed integers A and B,
stored in binary 2's-complement, where A is A' bits wide and B is B' bits
wide, with A' > B', assigning A to B loads the least significant B' bits of
A into B. The result is (of course) interpreted as 2's complement binary."

There are some important things here. One is the phrase "2's-complement",
and another is "least significant", and another is "binary".

You seriously need to understand those three concepts.

It would be useful to understand 1's complement as well, although I don't
know offhand of any modern computers that actually do 1's complement.

--
--------------------
My e-mail address doesn't have a 2 in it.

 
 
 

possible bug in CW 8.3 (PowerPC)

Post by David Phil » Fri, 13 Aug 2004 14:24:06

In article < XXXX@XXXXX.COM >,



You are getting confused by whatever tool you are using to print "b"
using C++'s standard type safe i/o, the following program:

#include <iostream>
using namespace std;

int main(){
long a = 99999;
unsigned short b = a;
cout << b << endl;

return 0;
}

prints:

34463
 
 
 

possible bug in CW 8.3 (PowerPC)

Post by Dana Cartw » Fri, 13 Aug 2004 19:52:55

After reading David Oster's post I think I probably seriously misunderstood
the question the OP posed. Was the question focused on why the result was
negative? If so, I completely mis-understood, and my post was way off base.
Apologies.

--
--------------------
My e-mail address doesn't have a 2 in it.



expect?
is
of
binary."
 
 
 

possible bug in CW 8.3 (PowerPC)

Post by yaron » Fri, 13 Aug 2004 23:25:49

Not really. I'm looking at the binary representation of b using the de *** .
I'll remind again that this only happens on the Mac (power PC processor).

And now I notice I made a mistake, b is a SIGNED short, not unsigned.

I would expect such an assignment to truncate a to a signed shorts maximum value.

Yaron
 
 
 

possible bug in CW 8.3 (PowerPC)

Post by Paul Russe » Fri, 13 Aug 2004 23:34:03


Bad assumption, I'm afraid. Strictly speaking the behaviour is
"undefined" but in practice you will just lose the high order bits. If
you're trying to use a short to store a value that is outside the
natural range for a short then that's called a "bug".

Paul
 
 
 

possible bug in CW 8.3 (PowerPC)

Post by David Phil » Sat, 14 Aug 2004 01:42:17

In article < XXXX@XXXXX.COM >,





That isn't how assignment works for built-in integer types in ANY C or
C++ compiler. When going from large to small, it just slices off as many
bits as will fit. Even float to int assignments don't round by default.
 
 
 

possible bug in CW 8.3 (PowerPC)

Post by Howard Hin » Sat, 14 Aug 2004 05:36:38


In article < XXXX@XXXXX.COM >,



Signed short makes all the difference in the world. Consider the case a
= -1:

long a = -1; // 0xFFFFFFFF
short b = a; // b should now be -1 too

In hex, b should look like 0xFFFF. If that is stored in a 32 bit
register, the compiler must sign extend the value in order to preserve
it.

Now back to your case:

long a = 99999; // 0x0001869F
short b = a; // 0x869F

If b is loaded into a 32 bit register, it still must be sign extended in
order to preserve its value (the algorithm of the cast does not depend
upon the value): 0xFFFF869F

-Howard