Max/min values of standard data types

Where can I find the maximum and minimum values that various types can store? And an epsilon value for floats?

I'm looking for something like C's limits.h, but for Solidity / EVM.

Updated 2020

Solidity 0.6.8 introduced min and max keywords that can now natively tell you the min and max of an expected type. From the release page:

Implemented type(T).min and type(T).max for every integer type T that returns the smallest and largest value representable by the type.

You can try it out with the following code. Note that the uint256 values can be swapped for any valid integer type:

pragma solidity ^0.6.8;

contract TestContract {
uint256 public a;
uint256 public b;

function myTest() external {
a = type(uint256).min;
b = type(uint256).max;
}
}

I assume you mean the integer types, because those are really the only types in Solidity that have a maximum and a minimum.

Solidity does not support floating point types, and most likely will never because they are considered not to be precise enough. Ethereum contracts need to be 100% deterministic, and always run the same way on all hardware.

Solidity will in the future support fixed-point types, but it doesn't yet.

Firstly, int means int256 and uint means uint256. Once you know the amount of bits your integer has, you can easily calculate the minimum and maximum using bitwise arithmetic:

int256 constant INT256_MIN = int256(uint256(1) << 255);
int256 constant INT256_MAX = int256(~(uint256(1) << 255));
uint256 constant UINT256_MIN = 0;
uint256 constant UINT256_MAX = ~uint256(0);

All the bitwise shifting is done on unsigned ints to avoid any special behaviour on the sign bit.

• Cheers! FYI, standard like IEEE754 would run deterministically on all hardware. Regardless, there is a virtual machine abstraction layer. Oct 5 '17 at 8:35
• @TomHale Yeah, a standard is a standard ofcourse. Thing is, I've had problems with 64-bit float arithmetic being compiled to extended precision 80-bit float arithmetic without anyone noticing. After the calculations were done, the compiler converted the 80-bit float back to 64-bit float. This caused apparent differences on different hardware, which was kind of a disaster. Ofcourse it was the compiler's and the programmers' fault, not the hardware's or the standard's. I guess I'm a bit prejudiced against floats :-) Oct 5 '17 at 8:46