dangernoodle-io / breadboard / 29971560295 / 1

96%

main: 96%

push

github

fix: emit JSON integers via bb_num, not nano-newlib-broken PRId64 (B1-1172) (#1010)

- bb_http_resp_json_obj_set_int() used snprintf("%" PRId64, ...), which expands
  to %lld on 32-bit esp32; under CONFIG_NEWLIB_NANO_FORMAT nano-newlib has no
  64-bit int formatter, so the specifier mangles and emits the literal string
  "ld" instead of the value, producing invalid JSON on-device
- confirmed live on hardware on GET /api/diag/heap, /api/diag/sockets, and
  /api/diag/boot's ts_ms envelope; host tests never caught it because 64-bit
  host %PRId64 is %ld and formats correctly there
- replaced the snprintf call with bb_num_i64_to_dec(), the hand-rolled,
  nano-newlib-safe decimal formatter (same class as B1-988)
- added bb_num to bb_http_server's PRIV_REQUIRES (private impl detail, no
  public-header dependency); bb_num has no component dependencies of its own,
  so no REQUIRES cycle
- investigated bb_http_resp_json_obj_set_num()'s snprintf("%g", ...) for the
  same nano-newlib class of bug: bb_num has no float/double decimal formatter,
  and set_num currently has zero live callers (only its own declaration/
  definition), so this PR leaves it as-is and flags it for a separate ticket
  rather than expanding scope
- extended host coverage for set_int with 0, INT64_MIN, and INT64_MAX to
  guard the bb_num integration and buffer/length handling (host %PRId64
  already worked, so this cannot reproduce the on-device nano-newlib bug
  itself -- device behavior is verified on hardware separately)

7386 of 7976 branches covered (92.6%)

Branch coverage included in aggregate %.

12530 of 12692 relevant lines covered (98.72%)

2498.53 hits per line