The C language comes with a variety of data types that hold integer (whole number) values. But each type is limited by its size. The issue is to ensure that whatever value the program is manipulating never exceeds the given size.
\n
\nHere is a summary of C language integer data types:<\/p>\n
| Type<\/th>\n | Width<\/th>\n | Minimum Range<\/th>\n | Maximum Range<\/th>\n<\/tr>\n<\/thead>\n |
|---|---|---|---|
| signed char<\/td>\n | 1 byte<\/td>\n | -128<\/td>\n | 127<\/td>\n<\/tr>\n |
| unsigned char<\/td>\n | 1 byte<\/td>\n | 0<\/td>\n | 255<\/td>\n<\/tr>\n |
| short int<\/td>\n | 2 bytes<\/td>\n | -32,768<\/td>\n | 32,767<\/td>\n<\/tr>\n |
| unsigned short int<\/td>\n | 2 bytes<\/td>\n | 0<\/td>\n | 65,535<\/td>\n<\/tr>\n |
| int<\/td>\n | 4 bytes<\/td>\n | -2,147,483,648<\/td>\n | 2,147,483,647<\/td>\n<\/tr>\n |
| unsigned int<\/td>\n | 4 bytes<\/td>\n | 0<\/td>\n | 4,294,967,295<\/td>\n<\/tr>\n |
| long int<\/td>\n | 4 or 8 bytes<\/td>\n | (See above\/below)<\/td>\n | (See above\/below)<\/td>\n<\/tr>\n |
| unsigned long int<\/td>\n | 4 or 8 bytes<\/td>\n | 0<\/td>\n | (See above\/below)<\/td>\n<\/tr>\n |
| long long int<\/td>\n | 8 bytes<\/td>\n | -9,223,372,036,854,775,808<\/td>\n | 9,223,372,036,854,775,807<\/td>\n<\/tr>\n |
| unsigned long long int<\/td>\n | 8 bytes<\/td>\n | 0<\/td>\n | 18,446,744,073,709,551,615<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Various C functions, typedefs, and defined constants are used to help your code with these ranges and values, but in all cases there is a minimum and maximum number that sits safely in an integer space.<\/p>\n When I first learned to program, I was curious why programmers didn’t always use the maximum size, such as a long long<\/em>. (Though, back then the largest integer value was a 16-bit int<\/em>.) The answer is efficiency, but also storage conservation. Especially in the olden days, uses the smallest container that accommodated a given value was the best way to use memory.<\/p>\n The issue that triggers when to use the next largest integer container is overflow.<\/p>\n For example, the next char<\/em> value after 127 is -128, which makes no sense to anyone unfamiliar with programming: Adding one to a char<\/em> variable that holds 127 suddenly subtracts 255 from the value. Weird to mortals, but sensical to a programmer.<\/p>\n Ditto for unsigned<\/em> data, where you add one to short int<\/em> 65,535 and you’re back at zero again.<\/p>\n Finding the integer overflow values is the topic for this month’s C programming exercise.<\/p>\n Write a program that counts from zero on up. Flag when the value overflows for the char<\/em> data type. Don’t cheat by using defined constants<\/a> from the Here is a sample run from my solution:<\/p>\n Please try this exercise on your own before checking out my solution, which I’ll post in a week.<\/p>\n","protected":false},"excerpt":{"rendered":" An integer can be only so large. Continue reading |