[mckilljoy]

I don't find it that odd. 32-bit applications are still very common, if not the standard. Most processes don't need more than 4GB.

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).

[kabdib]

The actual money fields are probably small compared to the infrastructure used to track them. It's not going to double the amount of memory usage. I'd be surprised if memory use, network traffic and database I/O went up by more than a percent or two.

[mckilljoy]

I agree for this one integer, they obviously should have been using 64-bit. I just take issue with the implication that Blizzard is somehow at fault or unusual for (presumably) not running a 64-bit stack.

They made a mistake for sure, but 32-bit vs. 64-bit architectures should not be on trial.

[astrodust]

It's not about blindly increasing it, but using "long long" where normally "long" would be used, especially for values that have the possibility of wrapping.

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.

[mckilljoy]

At the time the original code was written, it wasn't possible for a 32-bit integer to overflow, which is presumably why they didn't use 64-bit. That possibility was only introduced in the patch, and no one caught the bug that came with it.

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.