Go's handling of large numbers arithmetic!


(Salamu) #1

I would like to engage with someone(s) into discussing the design decision of GO not to produce Errors for when a user does some arithmetic that involve large numbers (which overflows their underlying type).

CODE
LINK TO PLAYGROUND

Even though adding two very very large int64 yields an overflow, GO still give back an int64 which is not the right intended- Correct result for such an operation?
How is the trust relationship between the CPU/ALU and the GO Compiler and who should take charge here?
For a second i thought about opening an issue but then I realised that maybe there is a good reason for the go team to leave it up to the user to know what they are doing!
Thanks in advance!


(Christophe Meessen) #2

You have to make a choice, cause a panic in case of overflow or wrap silently. If the choice is to panic in case of overflow, a test of overflow must be added after every arithmetic operation. This would slow down program execution. Unexpected overflows are very infrequent. The overhead is not worth it.

So I assume it is because of performance that the language designers chose to silently wrap and not panic in case of overflow.


(Eric Lindblad) #3

J. Griffin has a GH ‘overflow’ repo.

https://github.com/JohnCGriffin


(Salamu) #4

Thank you for your input. Brief and concise!


(Salamu) #5

Handling such overflow is as simple as checking wether the outcome of the operation is smaller than the biggest operand! Thank you for your input


(Eric Lindblad) #6

design decision

Integer Overflow in Golang (E. Williams’ Medium website)

J. Griffin - Jun 10, 2017

“In that legitimate design decision, Golang keeps the company of C, C++, and Java.”