Misleading of the unsigned type

Recently, when I was writing a program, I accidentally encountered an error. After careful consideration and debugging, I confirmed that the error was due to the unsigned type. Baidu has summarized it for a long time.

 

I believe many people know that there are roughly two types of C language standards, one is the old K & R C standard and the other is the new ANSI C standard (of course, these two standards have many differences about some details, but after all, they only allow correction and cannot be abolished, just like intel 8086's segment address: the addressing method of the Offset address has to be retained for the sake of compatibility, and the change in the C language standard is called a "quiet change ".

 

 

Int main (void) <br/>{< br/> If (-1 <(unsigned INT) 1) <br/>{< br/> printf ("ansi c "); <br/>}< br/> else <br/> {<br/> printf ("K & r c "); <br/>}< br/> return 0; <br/>}

 

This code tells you whether you are using K & r c or ansi c, because although the-1 bit mode is the same, but there are indeed different interpretations under the two different compilers. ansi c interprets it as a negative number, while K & r c strangely interprets it as a positive number.

 

It's not surprising to say something strange, because there are standards that can be referenced and explained:

 

K & r c adopts the unsigned preserving principle, that is, when an unsigned type is mixed with an int or a smaller integer, The result type is unsigned. This is a simple rule and has nothing to do with hardware. However, it will make a negative number lose the symbol bit as shown in the preceding example.

 

Ansi c adopts the value preserving principle, that is, when several integer operations are mixed like the preceding example, The result type may be a signed number or an unsigned number, it depends on the relative size of the operand type.

 

The problem I encountered is as follows:

# Define total_elements (sizeof (ARR)/sizeof (ARR [0]) </P> <p> int main (void) <br/>{< br/> int arr [] = {1, 2, 3, 4, 5 };< br/> int d =-1; <br/> /*...... */<br/> If (d <= total_elements-2) <br/> /*...... */<br/> return 0; <br/>}

 

After debugging, it is found that the original if judgment statement should be true, but this is not the case. Then, when reading the introduction of sizeof (), it is found that the return value type is size_t, that is, unsigned Int, when the if statement determines the size between the signed int and the unsigned int, D is upgraded to the unsigned int type, which causes-1 to be forcibly converted to a very large number, the expression is false.

 

In fact, it is also very easy to fix this problem, and it is forced type conversion, that is:

If (d <= (INT) total_elements-2)

 

After this time, we need a more positive opinion. do not define a number as an unsigned number because it cannot be a negative number (such as an age, this may cause an inexplicable problem in later programming. We recommend that you use the unsigned number only when bit segments and binary masks are used. Use forced type conversion in expressions so that the operands are all signed or unsigned. Do not use the compiler to select the type of the result.