Exception on overflow

[phiferd]

It would be nice if Solidity, by default, threw an exception for arithmetic overflow, rather than allowing it.

Justification:

1. Overflow is rarely desired behavior and is commonly cited as a security vulnerability.
   2: Even in cases where overflow is desired behavior, throwing an exception is a far safer failure mode and easier to detect/correct.
   3: The goal of solidity, as I understand it, is to enable the creation of secure and reliable smart contacts. Therefore, although it is of course possible for the developer to include their own checks, including this as a feature of the language will make the common case both simple and more secure.

If this is not achievable, I welcome alternatives that do not require each and every developer to remember these corner cases for each and every arithmetic operation. A solution that states "everybody should do XYZ" will inevitably lead to failures.

I'm am not familiar enough with the code to propose a detailed solution. However, a compiler switch that is on by default and can be disabled for backward compatibility is the sort of approach I was imagining.

[chriseth]

The main Problem I see with this is that you still have to aware of the possibility of an arithmetic overflow. If we throw in that case, this could stall a smart contract.

The only solution I see is to use our formal verification system that automatically verifies whether overflow protection checks are in place (or not needed).

[phiferd]

Could the same argument be made for the exception that is thrown for division by 0 and a negative array index? Those could have the same effect, but I can't see arguing that coming up with some default but incorrect behavior would be better (e.g. We could just wrap array indices around).

My concern is that the failures that can come from overflow go undetected.

I am definitely not suggesting that formal verification should not be done, there is no substitute. But I think allowing overflow offers no real advantage, unless you're hoping to hack a contract.

[chriseth]

You have a valid point. Still, I think these are not exactly comparable:
Invalid array access and division by zero are more predictable and less "continuous" than arithmetic overflow.

But yes, it is probably better to stall a contract in case of overflow than to provoke undesired effects on state.

What are cases where overflow is actually desired? I think for most of them, we can still use mulmod and addmod.

[chriseth]

Note that this is quite expensive to do, especially for types shorter than 256 bits.

[rainbreak]

Would you consider this for 0.4.0, or is it a bit involved for that?

[ethernomad]

Maybe this should be implemented in the EVM?

[axic]

I think arithmetic overflow detection belongs to the EVM, but that would be a rather big change to it.

[rainbreak]

For the EVM I think it would need extra opcodes as overflowing math is still useful. In the meantime we can have it in Solidity and get the safety benefits at the expense of a bit of gas (completely worth it I think because you end up checking it in safe code anyway).

[chriseth]

@rainbeam This is too involved for 0.4.0. Arithmetics is almost for free when compared to storage writes or even a transaction, so I think it is fine to do it. I do not really agree that this belongs to the EVM. Something like an overflow flag might be added to the EVM, but not a "force-stop" on overflow.

[axic]

I think arithmetic overflow detection belongs to the EVM

By detection I meant the overflow flag. So perhaps that would then needs its on opcode for getting the overflow flag onto the stack and/or its own jump (JUMPOF).