Why is the INT (2 byte) representation range in C language-32768 ~ 32767!

Source: Internet
Author: User

1. This should start with the binary original code (digital logic-teacher dongye ):
If the highest bit is used as the symbol bit, the maximum binary original code is 0111111111111111 = the 15th power of 2 minus 1 = 32767
The minimum value is 1111111111111111 =-2 to the 15th power minus 1 =-32767
In this case, 0 has two Representation Methods: positive 0 and negative 0: 0 then 000000000000 = 1000000000000000 = 0
Therefore, when the binary original code is expressed, the range is-32767 ~ -0 and 0 ~ 32767, because there are two zeros, so the number of different values is only two to the power of 16 minus one, 1 less than the 16-bit binary code that can provide 2 to the 16 power.
However, binary complement codes are used in the computer to store data. That is, the positive number encoding remains unchanged. From 0000000000000000 to 0111111111111111, the positive number encoding is still 0 to 32767, while the negative number needs to reverse the part after the symbol bit by 1, that is, the Supplementary Code of-32767 is 1000000000000001.
At this point, let's look at the positive 0 and negative 0: 00 of the original code 0000000000000000 and 1000000000000000. The complement Code indicates that the complement code of the former is 0000000000000000, and the latter is added after the unsigned bit is reversed by 1, it also becomes 0000000000000000, that is, the encoding of positive 0 and negative 0 in the complement system is the same. However, we know that the 16-bit binary number can represent the 16-power encoding of 2, and there is only one zero encoding in the complement code, that is, one more encoding than the original code, this encoding is 1000000000000000, because no source code can be converted to 1000000000000000 when it is converted into a complement code. Therefore, the human code 1000000000000000 is coded as-32768.
Therefore, in the CAPTCHA human Bypass System, the range is-32768 ~ 32767.
Therefore, in fact, the minimum value of binary is indeed 1111111111111111, but the minimum value of binary complement is 100000000000001, And the 1111111111111111 value of complement is-1 of the decimal value.

{In addition, the conversion process from the complement code to the original code is: positive number remains unchanged, negative number retains 1 of the symbol bit, and other bits are reversed and incremented.

The complement code is calculated in the following way: 1. Its symbol bit and value are involved in the operation.
2. After the signed bits of the complement sign are added, if any incoming bits appear, remove the carry (naturally lost ).
3. The result of the complement operation is also a complement. When it is converted to a true value, if the sign bit is 0, the digit remains unchanged. If the sign bit is 1, the result should be supplemented to its true value .}

 

2. Here is a question about how codeforces hurts. I didn't notice it before:

Long long intnum =-2147483648; <br/> so we cout <intnum; 2147483648, <br/> Why? <Br/> because some compilers regard 2147483648 as a (INT) type <br/> you need to define it as follows: <br/> long intnum =-(long) 2147483648; <br/> then cout <intnum; is-2147483648. 

3. There is another issue of warning during compilation:

"Warning: This decimal constant is unsigned only in ISO C90"

Note: The constant in C language is a 32-bit signed integer by default.

Solution:

1. Add a UL mark or ull sign after the constant, for example, 4294967295ul, so that no alarm will be reported.
2. Use a hexadecimal number, for example, 0 xffffffff.
3 Use gcc-STD = c99 to compile with 99 Standard

Original article:

The C90 rule that the default type of a decimal integer constant is either int, long, or Unsigned long, depending on which type is large enough to hold the value without Overflow, Simplifies the use of constants. The choices in c99 are int, long and long. C89 added the suffixes U and u to specify unsigned numbers. c99 adds ll to specify long Long. Unlike decimal constants, octal and hexadecimal constants too large to be ints are typed Unsigned int if within range of that type, since it is more likely that they represent bit Patterns or masks, which are generally best treated as unsigned, rather than "real" numbers. Little support was expressed for the old practice of permitting the digits 8 and 9 in an octal Constant, so it was dropped in c89.A proposal to add binary constants was rejected due to lack of precedent and insufficient utility. despite a concern that a "lower-case-L" cocould be taken for the numeral one at the end of anumeric literal, The c89 Committee rejected proposals to remove this usage, primarily on thegrounds of sanctioning existing practice.

Now let's get it clear. This alarm is actually triggered by GCC reminding you to upgrade your compilation options. However, the safest thing is to use the hexadecimal format, or add ul or ull.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.