It is odd that they're using 32-bit numbers when you'd be hard pressed to find a 32-bit only CPU and machines with over 4GB of memory are the standard.
Good luck overflowing a 64-bit unsigned.
Good luck overflowing a 64-bit unsigned.
More importantly, blindly increasing all of your 32-bit integers to 64-bit is going to double your memory usage, and ultimately just mask the real issue (i.e. improper bounds checking).
They made a mistake for sure, but 32-bit vs. 64-bit architectures should not be on trial.
The real impact on memory usage is likely the 8-byte pointers, but if you have a non-trivial amount of memory, it's rarely an issue worth fretting about.
If we cared about pointer sizes, we'd still be writing 16-bit code.
Running 64-bit would have "prevented" this bug simply by virtual of that fact that the default datatype would have been big enough to avoid overflow, but it isn't really a solution. I just find 32-bit vs. 64-bit to be inconsequential to the real mistake, which was an improper software development process.
It's entirely conceivable that people have billions in currency, but not quintillions. Though perhaps Zimbabwe serves as a counter-point to this. They've had to slash twelve zeroes off their currency valuation on at least one occasion.