Thinking about #20678 (and #19624) made me wonder what other unchecked overflows are lurking in the standard library. I've found another one, but I don't have real-world code that triggers it. (I'm filing this issue just for reference.)
(*sync.WaitGroup).Add accepts an int parameter, so it is reasonable for users to expect that they cannot make Add calls summing to more than the maximum possible int. However, in practice WaitGroup only supports Add calls that sum to within math.MaxInt32.
Add currently detects (and panics on) overflows that happen to land in the negative half of the int32 space, but fails to detect other overflows entirely.
Add should be fixed to reliably panic on all overflows. It should ideally support the full positive int range, but if that isn't feasible the supported range should be made clear in the documentation.
$ go version
go version devel +0a0e45d5c6 Thu May 25 17:57:21 2017 -0400 linux/amd64
As already mentioned in the abandoned CL, I'm not sure anymore, if it is possible to detect overflows in all cases, without turning Add into a CAS loop.
Maybe there should be a variation of sync/atomic.AddUint64, which checks for overflows and reports them:
func AddUintptr(addr *uintptr, delta uintptr) (new uintptr, overflowed bool)
If an overflow is reported during counter modification, the program could be terminated by throw since the counter may be in an inconsistent state due to concurrent modifications.
The case in which the counter becomes negative could still cause a panic which can be recovered from (if no overflow was involved).