3 ms·
Is there really a way around this? overflow should be an error in most languages - but isn't for a variety of reasons such as simplifying the construct c = a +
by lumost 4y ago
Is there really a way around this? overflow should be an error in most languages - but isn't for a variety of reasons such as simplifying the construct
c = a + b
In a language without native memory management, it's rare that this type of bug could lead to disclosure of sensitive information. In the cases it would, it's easy enough to guard the overflow with a test such as if (MAX_VAL - b) < a then error.
Chasing safety features which result in difficult to reason about semantics will inevitably lead to low language adoption. I'd be very interested in approaches which guard difficult cases while maintaining ease of use. I'd love a statically typed language which automatically increases the size of numeric type on over/underflow.
- est31 4y ago> overflow should be an error in most languages > Chasing safety features which result in difficult to reason about semantics will inevitably lead to low language adoption. Python solves this problem by not having overflow for integers at all, instead all integers are unlimited. It's still one of the most widely used languages in the world.
- lumost 4y agotrue, however python doesn't have static typing. It would be interesting to see more static languages adopt a "Number" primitive.
- kaba0 4y agoHaskell has it as well, in a very clever way in my opinion. Number literals don’t have a type themselves, they are inferred to be the correct type based on context/available type notations, etc. There is both a 64bit integer type and an “infinite” one, and you can change the implementation by a single type notation, in a completely safe way.