About: Arithmetic overflow is a research topic. Over the lifetime, 62 publications have been published within this topic receiving 723 citations. The topic is also known as: numeric overflow & overflow.
TL;DR: This paper presents how the component currently translates a subset of Solidity into SMT statements using different theories, and discusses future challenges such as multi-transaction and state invariants.
Abstract: Ethereum smart contracts are programs that run inside a public distributed database called a blockchain. These smart contracts are used to handle tokens of value, can be accessed and analyzed by everyone and are immutable once deployed. Those characteristics make it imperative that smart contracts are bug-free at deployment time, hence the need to verify them formally. In this paper we describe our current efforts in building an SMT-based formal verification module within the compiler of Solidity, a popular language for writing smart contracts. The tool is seamlessly integrated into the compiler, where during compilation, the user is automatically warned of and given counterexamples for potential arithmetic overflow/underflow, unreachable code, trivial conditions, and assertion fails. We present how the component currently translates a subset of Solidity into SMT statements using different theories, and discuss future challenges such as multi-transaction and state invariants.
TL;DR: This paper formalises a simple assembly language with procedures and a safety policy for arithmetic overflow in Isabelle/HOL and discusses both variants pointing out their specific strengths and weaknesses.
Abstract: We formalise a simple assembly language with procedures and a safety policy for arithmetic overflow in Isabelle/HOL. To verify individual programs we use a safety logic. Such a logic can be realised in Isabelle/HOL either as shallow or deep embedding. In a shallow embedding logical formulas are written as HOL predicates, whereas a deep embedding models formulas as a datatype. This paper presents and discusses both variants pointing out their specific strengths and weaknesses.
TL;DR: The proposed conditions guarantee that the correcting term is exact when the result is a number, and have validated the proofs against Coq automatic proof checker.
Abstract: Studying floating point arithmetic, authors have shown that the implemented operations (addition, subtraction, multiplication, division and square root) can compute a result and an exact correcting term using the same format as the inputs. Following a path initiated in 1965, many authors supposed that neither underflow nor overflow occurred in the process. Overflow is not critical as this kind of exception creates persisting nonnumeric quantities. Underflow may be fatal to the process as it returns wrong numeric values with little warning. Our new conditions guarantee that the correcting term is exact when the result is a number. We have validated our proofs against Coq automatic proof checker. Our development has raised many questions, some of them were expected while other ones were surprising.
TL;DR: In this article, the overflow detection logic circuitry within the arithmetic logic unit detects positive overflow or negative overflow resulting from the arithmetic operation and replaces the output of the two's complement adder with a value of 0.
Abstract: A computer system provides handling of positive and negative overflow. A first arithmetic operation is performed on a first n-bit unsigned binary operand and a second n-bit signed binary operand to produce an n-bit unsigned binary result. Overflow detection logic circuitry within the arithmetic logic unit detects positive overflow or negative overflow resulting from the arithmetic operation. When there is a positive overflow, saturation logic replaces the output of the two's complement adder with a value of 2 n-1 . When there is a negative overflow, the saturation logic replaces the output of the two's complement adder with a value of 0. In an alternate embodiment, a first arithmetic operation is performed on a first n-bit signed binary operand and a second n-bit signed binary operand to produce an n-bit positive signed binary result. For example the arithmetic operation is an addition or subtraction performed by a two's complement adder. In the alternate embodiment, overflow detection logic circuitry within the arithmetic logic unit detects positive overflow or negative overflow resulting from the arithmetic operation. When there is a positive overflow, saturation logic replaces the output of the two's complement adder with a value of 2 n-1 -1. When there is a negative overflow, the saturation logic replaces the output of the two's complement adder with a value of 0.
TL;DR: The Runcheck Verifier is a working system for proving the absence of common runtime errors in Pascal without variant records, side effects in functions, shared variable parameters to procedures, or functional arguments.
Abstract: The Runcheck Verifier is a working system for proving the absence of common runtime errors. The language accepted is Pascal without variant records, side effects in functions, shared variable parameters to procedures, or functional arguments. The errors checked are: 1) accessing a variable that has not been assigned a value, 2) array subscripting out of range, 3) subrange type error, 4) dereferencing a NIL pointer, 5) arithmetic overflow, and 6) division by zero.