dangernoodle-io / breadboard / 30925420889

97%

push

github

fix: format-type mismatch + -Wrestrict false positive on xtensa target (#1224)

bb_serialize_json.c:265 used "%d" to format vi (int32_t), which is
long int on xtensa -- a -Werror=format= build-breaker once B1-1420
enables -Wall on the ESP-IDF target, invisible on host where int32_t
is a plain int. Route through bb_num_i64_to_dec() (already used
elsewhere in this file's number-formatting block) instead of adding
a second hand-rolled snprintf-based integer formatter.

bb_http_section.c:62 used snprintf(slot->wildcard, ..., "%s*",
slot->prefix), which GCC's -Wrestrict flags as a possible overlap
even though prefix/wildcard are disjoint struct members that cannot
alias -- confirmed a false positive, not reproducible on host gcc at
any -O level. Restructured to an explicit bounded copy + manual
terminator write (mirroring the strncpy idiom two lines above)
rather than suppressing with #pragma GCC diagnostic (this repo has
zero prior instances of that suppression).

Touching bb_http_section.c triggered the file-level coverage ratchet
on a pre-existing uncovered branch in bb_http_section_find()'s
"only a strictly-longer match can win" guard. Review caught that an
initial test for this used two DISTINCT equal-length prefixes, which
register_ns()'s duplicate-prefix guard makes unreachable in
combination (two different prefixes of equal length can never both
strncmp-match the same URI, since that requires byte-identical
content) -- the test executed the line but pinned no behavior.
Mutation-tested to confirm: flipping <= to < left all 5465 native
tests passing, proving the '=' case was genuinely dead. Narrowed the
operator to < and deleted that test. Coverage then re-flagged the
SAME original branch (its true side was still never hit under either
operator -- no existing test registers a longer prefix before an
overlapping shorter one). Replaced it with a real,
mutation-detectable test: register the longer match first, then a
shorter, distinct, but still-URI-mat... (continued)

8357 of 8918 branches covered (93.71%)

Branch coverage included in aggregate %.

6 of 6 new or added lines in 2 files covered. (100.0%)

14066 of 14221 relevant lines covered (98.91%)

2612.36 hits per line