Buffer overflows and learning about bit depth – An accidential revelation
In my latest programming class – C/C++, a fellow student posted a question about buffer overflows in the short data type of C++.
Frankly, I didn’t know much about the different data types in C, why they had their ranges, or why their byte size was set the way it was: to me they just were.
My classmate was experimenting with these overflows and produced this simple algorithm:
#include <iostream>
using namespace std;
int main()
{
short little;
little = 32768;
cout << "The vaule of little is " << little << endl;
return 0;
}
And he reported that the output would be -32768.
Short’s range is from -32,768 to 32,767, and he wondered why the compile didn’t bug out during compile time.
Thinking the answer not that hard to attain, I started playing with the ranges.
To my pleasure: taking the sum of of integers in a data type’s range and dividing them by 8 will eventually divide evenly into the byte size for the date type.
For instance: short range includes 65,535 integers, including zero and all the positive and negative numbers.
Short’s size is 2 bytes.
65,535 divided by 8^5 equals 2.
Sexy, no?
Playing with these data types further: the data type unsigned short has a range from zero to 65,535.
Which is a total range of 65,536 integers.
It is also evenly divisible by 8^5 into 2.
Unsigned short’s size is also 2 bytes.
This trend continues with int’s, unsigned int’s, long’s, unsigned long’s, and I assume each and every other data type’s size and range.
And what limits computers are the processor’s bit depth.
For instance what makes a 32 bit processor a 32 bit processor, is it’s ability to handle variables whose sizes reach 32 bytes. And the same follows the 64 bit processors: their ability to handle variables whose sizes reach 64 bytes.
What it boils down to is the machine’s capability to handle arithmetic operations. Mathematics are infinite, however our machines are not.
I thought that was kind of beautiful and tragic.
Anyway, feeding my classmates’ program more numbers to crunch, I found that should I set the variable little a number over it’s positive integer range, it would spit out a non-random number in closely related to the original number entered, but negative.
For instance: setting little to 32769 then compiling it, on execution, the value of little will output as -32767.
An experiment came to mind, and I set little to 65535 (short’s total integer range) and compiled.
The number output as -1. How sexy as that? The number line in our machines is like a ring!
Setting the variable little to 65536, I compiled and GCC spit out a discouraging warning about a overflow on line 8. (The out of range variable.)
Executing the program, it output as 0.
How sexy is this? The number line is like a ring and goes outside of it’s range into something that is in it’s range.
It also works backwards: setting little to -65536 will output little as 0.
There’s no doubt this causes issues for many programmers, as buffer overflows, and anticipating them are quite a pain.
But I just thought it was too sexy to stay quiet about.
Posted on February 17th, 2010 by Matt Walther
Filed under: Programming in color | No Comments »