analogRead() overflow behavior changes across AVR-to-ARM int width boundary
0 reputation · 19 Aug 2026, 19:10 UTC
Moving a sketch from an 8-bit AVR board to a SAMD or ESP32 target changes the width of int from 16-bit to 32-bit, while analogRead() continues to return a plain int. The same sensor expression can therefore wrap at different thresholds depending on the target, even though the API signature appears identical.
The Arduino language reference documents this width difference, yet core functions such as analogRead() and map() still use int rather than fixed-width types. Because default build flags do not enable -Wconversion, ported code often compiles silently while truncating large intermediate values. No core-level deprecation or unified migration path to int16_t or int32_t has been documented for these APIs.
What is the recommended way to write sensor arithmetic that behaves identically across AVR and ARM cores? Should developers manually cast analogRead() results to fixed-width types to preserve intended overflow semantics, or is there a supported configuration change that surfaces width-dependent truncation at compile time? Is a core-level transition to fixed-width return types planned for future releases?
