On an Arduino Uno an int is 16 bits and holds only up to 32767. Larger results wrap around to negative numbers.
What the message means
Integer maths is done in the type of the operands. 200 * 200 is 40000, which does not fit in an int, so the result overflows before it is stored.
Fix it in this order
- Store large values in long or unsigned long variables.
- Write a constant as 200L or 1000UL so the maths runs in 32 bits.
- Do the multiplication before the division to keep precision, but in a long variable.
- Use float only when you need fractions. It costs speed and memory on an Uno.
- Print the intermediate values to find where the number goes wrong.
- Use unsigned long for millis() and micros() values.
Why it happens
On an Arduino Uno, an int is 16 bits, so its range ends at 32767. Arithmetic on two ints is done in int, even if the result is assigned to a long variable later. The overflow happens during the calculation, so the stored result is already wrong, and it wraps around to a negative number. The language raises no error when this happens, so the bad number simply appears in the output and looks like a flaw in your formula.
The fix is to choose the type before the arithmetic happens. Declaring variables as long or unsigned long, or adding an L or UL suffix to constants, makes the maths run at the wider size. Multiply before dividing when integer division is in the way, since dividing first discards the fraction. Remember that millis() returns an unsigned long, so storing it in an int breaks timing after a short time.
If you see this, do this
| You see | Do this |
|---|---|
| Value jumps to negative | int overflow. |
| Division gives zero | Integer division. Use floats or scale first. |
Confirm the fix
- Print sizeof(int) and sizeof(long) in setup(); on an Uno, int is 2 bytes and long is 4 bytes.
- Calculate int(200) * 200 and then 200L * 200 in the same sketch, and compare the two printed results.
- Print each intermediate step; the first line that goes negative or unexpectedly small shows where the overflow starts.
Common mistake: Readers assume the formula is wrong when the real cause is that intermediate arithmetic overflowed a 16-bit int before it reached the long variable.
Related
millis() timing, Serial.print speed.
Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.