Fixing this bug correctly would require a hard fork which is not happening anytime soon!
int64_t nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks
// which will occur approximately every 4 years.
nSubsidy >>= (nHeight / 210000);
The block number is divided by 210000 (the "apparent" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units.
Thanks to the new-goldmine interval being exactly 64 times the halving interval, and 64 being the size in bits of the currency datatype, the cycle repeats itself every 64 halvings.
this is not a bug, this is more like a convenience. right now and until hundreds of years we are going to use fixed bit integers (such as 32 and 64 bit ints)
to represent a lot of things. in programming we do this all the time. for example the year 2038 problem in time representation has been a thing for a long time as we were using 32 bit integers. now we are using 64 bit integers and that postpones it until we change it in a couple of hundred years!
the same is happening here, after a hundred years when we get close to this being a problem, by that time computers will surely support 256 bit numbers by default as their small integers that a CPU can handle in one call and we simply change int64_t to int256_t without needing any kind of hard fork or anything like that.
changing that line of code right now to anything bigger like 256-bit would require handling 192-bits of zero for no reason for 200+ years!