为什么此位黑客代码可移植？

Question

int v;
int sign; // the sign of v ;
sign = -(int)((unsigned int)((int)v) >> (sizeof(int) * CHAR_BIT - 1));

Q1: Since v in defined by type of int ,so why bother to cast it into int again? Is it related to portability?

Edit:

Q2:

sign = v >> (sizeof(int) * CHAR_BIT - 1); 

this snippt isn't portable, since right shift of signed int is implementation defined , how to pad the left margin bits is up to complier.So

 -(int)((unsigned int)((int)v) 

do the poratable trick. Explain me why thid works please. Isn't right shift of unsigned int alway padding 0 in the left margin bits ?

Answer 1

It's not strictly portable, since it is theoretically possible that int and/or unsigned int have padding bits.

In a hypothetical implementation where unsigned int has padding bits, shifting right by sizeof(int)*CHAR_BIT - 1 would produce undefined behaviour since then

sizeof(int)*CHAR_BIT - 1 >= WIDTH

But for all implementations where unsigned int has no padding bits - and as far as I know that means all existing implementations - the code

int v;
int sign; // the sign of v ;
sign = -(int)((unsigned int)((int)v) >> (sizeof(int) * CHAR_BIT - 1));

must set sign to -1 if v < 0 and to 0 if v >= 0 . (Note - thanks to Sander De Dycker for pointing it out - that if int has a negative zero, that would also produce sign = 0 , since -0 == 0 . If the implementation supports negative zeros and the sign for a negative zero should be -1 , neither this shifting, nor the comparison v < 0 would produce that, a direct inspection of the object representation would be required.)

The cast to int before the cast to unsigned int before the shift is entirely superfluous and does nothing.

It is - disregarding the hypothetical padding bits problem - portable because the conversion to unsigned integer types and the representation of unsigned integer types is prescribed by the standard.

Conversion to an unsigned integer type is reduction modulo 2^WIDTH , where WIDTH is the number of value bits in the type, so that the result lies in the range 0 to 2^WIDTH - 1 inclusive.

Since without padding bits in unsigned int the size of the range of int cannot be larger than that of unsigned int , and the standard mandates (6.2.6.2) that signed integers are represented in one of

• sign and magnitude
• ones' complement
• two's complement

the smallest possible representable int value is -2^(WIDTH-1) . So a negative int of value -k is converted to 2^WIDTH - k >= 2^(WIDTH-1) and thus has the most significant bit set.

A non-negative int value, on the other hand cannot be larger than 2^(WIDTH-1) - 1 and hence its value will be preserved by the conversion and the most significant bit will not be set.

So when the result of the conversion is shifted by WIDTH - 1 bits to the right (again, we assume no padding bits in unsigned int , hence WIDTH == sizeof(int)*CHAR_BIT ), it will produce a 0 if the int value was non-negative, and a 1 if it was negative.

Answer 2

Nope its just excessive casting. There is no need to cast it to an int. It doesn't hurt however.

Edit: Its worth noting that it may be done like that so the type of v can be changed to something else or it may have once been another data type and after it was converted to an int the cast was never removed.

Answer 3

It should be quite portable because when you convert int to unsigned int (via a cast), you receive a value that is 2's complement bit representation of the value of the original int , with the most significant bit being the sign bit.

UPDATE : A more detailed explanation...

I'm assuming there are no padding bits in int and unsigned int and all bits in the two types are utilized to represent integer values. It's a reasonable assumption for the modern hardware. Padding bits are a thing of the past, from where we're still carrying them around in the current and recent C standards for the purpose of backward compatibility (ie to be able to run code on old machines).

With that assumption, if int and unsigned int have N bits in them ( N = CHAR_BIT * sizeof(int) ), then per the C standard we have 3 options to represent int , which is a signed type:

1. sign-and-magnitude representation, allowing values from -(2 ^N-1 -1) to 2 ^N-1 -1
2. one's complement representation, also allowing values from -(2 ^N-1 -1) to 2 ^N-1 -1
3. two's complement representation, allowing values from -2 ^N-1 to 2 ^N-1 -1 or, possibly, from -(2 ^N-1 -1) to 2 ^N-1 -1

The sign-and-magnitude and one's complement representations are also a thing of the past, but let's not throw them out just yet.

When we convert int to unsigned int , the rule is that a non-negative value v (>=0) doesn't change, while a negative value v (<0) changes to the positive value of 2 ^N + v , hence (unsigned int)-1 = UINT_MAX .

Therefore, (unsigned int)v for a non-negative v will always be in the range from 0 to 2 ^N-1 -1 and the most significant bit of (unsigned int)v will be 0.

Now, for a negative v in the range from to -2 ^N-1 to -1 (this range is a superset of the negative ranges for the three possible representations of int ), (unsigned int)v will be in the range from 2 ^N +(-2 ^N-1 ) to 2 ^N +(-1), simplifying which we arrive at the range from 2 ^N-1 to 2 ^N -1. Clearly, the most significant bit of this value will always be 1.

If you look carefully at all this math, you will see that the value of (unsigned)v looks exactly the same in binary as v in 2's complement representation:

...
v = -2: (unsigned)v = 2 ^N - 2 = 111...110 ₂
v = -1: (unsigned)v = 2 ^N - 1 = 111...111 ₂
v = 0: (unsigned)v = 0 = 000...000 ₂
v = 1: (unsigned)v = 1 = 000...001 ₂
...

So, there, the most significant bit of the value (unsigned)v is going to be 0 for v >=0 and 1 for v <0.

Now, let's get back to the sign-and-magnitude and one's complement representations. These two representations may allow two zeroes, a +0 and a -0 . But arithmetic computations do not visibly distinguish between +0 and -0 , it's still a 0 , whether you add it, subtract it, multiply it or compare it. You, as an observer, normally wouldn't see +0 or -0 or any difference from having one or the other.

Trying to observe and distinguish +0 and -0 is generally pointless and you should not normally expect or rely on the presence of two zeroes if you want to make your code portable.

(unsigned int)v won't tell you the difference between v=+0 and v=-0 , in both cases (unsigned int)v will be equivalent to 0u .

So, with this method you won't be able to tell whether internally v is a -0 or a +0 , you won't extract v's sign bit this way for v=-0 .

But again, you gain nothing of practical value from differentiating between the two zeroes and you don't want this differentiation in portable code.

So, with this I dare to declare the method for sign extraction presented in the question quite/very/pretty-much/etc portable in practice.

This method is an overkill, though. And (int)v in the original code is unnecessary as v is already an int .

This should be more than enough and easy to comprehend:

int sign = -(v < 0);

Answer 4

It isn't. The Standard does not define the representation of integers, and therefore it's impossible to guarantee exactly what the result of that will be portably. The only way to get the sign of an integer is to do a comparison.