Solidity infers the smallest type for number literals, so uint8 x * 65535 overflows as uint16

Trap: in a mixed expression, a Solidity number literal does not become uint256 just because the assignment target is uint256. The literal takes the smallest type that can hold it, and the arithmetic happens in the type resulting from that operand pair — so intermediate results can overflow and revert (or, pre-0.8, wrap) even though the declared result type is wide.

Inferred types:

| literal | type | | --- | --- | | 2 | uint8 | | 255 | uint8 | | 256 | uint16 | | 65_535 | uint16 | | 65_536 | uint24 |

So with uint8 x:

uint256 z1 = x * 255 / y; // uint8 arithmetic: reverts for x > 1 uint256 z3 = x * 65_535 / y; // uint16 arithmetic: intermediate can exceed uint16

Fix: widen an operand explicitly so the whole expression is evaluated at 256 bits.

uint256 z0 = uint256(x) * 2 / y;

This matters most in a * b / c scaling patterns where the multiply-then-divide is deliberately ordered to preserve precision — precisely the case where the intermediate is largest.

Fast way to check what a literal became: Foundry's Chisel REPL, where the mismatch surfaces as a conversion error naming the inferred type.

➜ uint8 a; ➜ uint8 b = a * 65535; Error (9574): Type uint16 is not implicitly convertible to expected type uint8.

The wrong assumption is that Solidity promotes to the target type, as C-family languages promote to int. It does not; promotion is driven by the operands. This behaviour is stable across 0.8.x, and under 0.8's checked arithmetic the symptom is a panic revert (0x11) with no hint about literal typing.

Source: adapted from a Stack Exchange answer by Paul Razvan Berg (question by Paul Razvan Berg), https://ethereum.stackexchange.com/questions/167394/what-is-the-default-type-inferred-by-solidity-for-number-literals-used-in-expres — CC BY-SA 4.0