Summary
-Wmaybe-uninitialized fires on fl::tuple in fl/remote/rpc/json_arg_converter.h:76 across 7 boards (Arduino Due / SAM3X8E, RP2040, RP2350, Adafruit Feather nRF52840 Sense, Adafruit XIAO BLE Sense, nRF52840 DK, XIAO BLE Sense nRF52).
warning: tuple may be used uninitialized [-Wmaybe-uninitialized]
lib/FastLED/fl/stl/tuple.h:25:9 (in fl::tuple move/copy ctor instantiation)
note: tuple was declared here
fl/remote/rpc/json_arg_converter.h:76:5 -> args_tuple tuple;
Why this is a real bug
args_tuple tuple; uses the default ctor, which leaves head/tail (and any nested tuple members) indeterminate. If JSON arg conversion fails before all positions are written (early-exit on type mismatch, missing field, etc.), the subsequent move/copy ctor reads indeterminate memory -> UB. On AVR / ARM this can manifest as garbage pointer values handed to RPC handlers, mis-typed callbacks, intermittent corruption that only repros for specific JSON inputs.
A parallel audit found ~56 instantiation chains hit this across the 7 boards. The early-return branches in JsonArgConverter::convert() copy the tuple before convertArgs ever writes to it.
Proposed fix
Value-initialize the local — one-line change:
// json_arg_converter.h:76
- args_tuple tuple;
+ args_tuple tuple{};Optionally also harden fl::tuple's default ctor in fl/stl/tuple.h:22-25 to value-initialize members.
Evidence
Surfaced by an audit of recent FastLED CI runs:
- sam3x8e_due run (4 instantiations, JsonArgConverter<json(int)> + JsonArgConverter<void(int)>)
- rp2040 / rp2350 runs (every Fx example using RPC)
- All 4 nRF52 runs
Cross-reference: fbuild meta-tracker (link added separately).
Summary
-Wmaybe-uninitializedfires onfl::tupleinfl/remote/rpc/json_arg_converter.h:76across 7 boards (Arduino Due / SAM3X8E, RP2040, RP2350, Adafruit Feather nRF52840 Sense, Adafruit XIAO BLE Sense, nRF52840 DK, XIAO BLE Sense nRF52).Why this is a real bug
args_tuple tuple;uses the default ctor, which leaveshead/tail(and any nested tuple members) indeterminate. If JSON arg conversion fails before all positions are written (early-exit on type mismatch, missing field, etc.), the subsequent move/copy ctor reads indeterminate memory -> UB. On AVR / ARM this can manifest as garbage pointer values handed to RPC handlers, mis-typed callbacks, intermittent corruption that only repros for specific JSON inputs.A parallel audit found ~56 instantiation chains hit this across the 7 boards. The early-return branches in
JsonArgConverter::convert()copy the tuple beforeconvertArgsever writes to it.Proposed fix
Value-initialize the local — one-line change:
// json_arg_converter.h:76 - args_tuple tuple; + args_tuple tuple{};Optionally also harden
fl::tuple's default ctor infl/stl/tuple.h:22-25to value-initialize members.Evidence
Surfaced by an audit of recent FastLED CI runs:
Cross-reference: fbuild meta-tracker (link added separately).