limits/imap.go: Prevent integer overflow on 32 bit platforms

[benthetechguy]

Fixes #382 Since the (signed) int type is used, MaxUInt32 is too big for use on 32 bit platforms. Changing to MaxInt32 solves this problem.

[benthetechguy]

Is there any reason we can't just use MaxInt32 for limits on all systems, like my original changes did?

[LBeernaertProton]

Is there any reason we can't just use MaxInt32 for limits on all systems, like my original changes did?

The maximum range of values we can represent with MaxInt32 is [0, 2147483647]

The maximum range of values we can represent with MaxUint32 is [0, 4294967295]

The current setup works, since int on 64bit system is equal to int64, which can safely express all the range of operations we need to perform to make the calculations.

While your original change compiles, it has some problems:

• 64bit systems are now handicapped (max range of values reduced by 2)
• Once we hit MaxInt32 values, the checks will always fail on 32bit system without due to signed integer overflow

[benthetechguy]

So you're okay with 32 bit platforms having half the max range as long as 64 bit ones don't also?

[LBeernaertProton]

So you're okay with 32 bit platforms having half the max range as long as 64 bit ones don't also?

Yes, 64bit should have full range. I see this as compromise for now.

There is much more work required to ensure that one can represent the max range of uint32 correctly across the entire code base in 32bit mode. But at least it would not block people from building under 32bits.

[LBeernaertProton]

Looks good now. Could you amend the commit to fix: Prevent IMAP Limits integer overflow on 32 bit platforms

[benthetechguy]

I don't know if you were notified, but I did it three days ago.