dangernoodle-io / breadboard / 29350267458

96%

push

github

refactor: migrate bb_tcp_client/bb_udp_client/bb_tls_creds off bb_nv generic KV (B1-756) (#864)

Moves the three smallest bb_nv generic-KV consumers onto bb_config (the
typed layer over bb_storage) directly, proving the migration pattern
bb_settings already established, ahead of the riskier remaining consumers
(bb_system, bb_diag, bb_mqtt_client, bb_net_health, bb_ota_boot).

Preserved namespaces/keys/types (byte-compatible on-flash, no format
change -- bb_nv's ESP-IDF forwarders and bb_config's typed encodings both
resolve to the same underlying bb_storage_nvs_* / nvs_* calls):
  - bb_tcp_client: ns "bb_tcp", keys "host" (STR), "port" (U16), "tls" (U8)
  - bb_udp_client: ns "bb_udp", keys "host" (STR), "port" (STR), "broadcast" (STR)
  - bb_tls_creds:  caller-supplied ns, keys "tls_ca"/"tls_cert"/"tls_key" (STR)

bb_udp_client's port/broadcast deliberately KEEP their existing
decimal-ASCII STR encoding ("9109"/"1") rather than moving to bb_config's
U16/BOOL typed encoding -- switching would change the on-flash NVS entry
type tag and silently orphan the value on every already-provisioned board.

bb_tls_creds gains an explicit NUL-termination fix: bb_config_get_str's
blob-fallback path (used by non-NVS-typed backends, i.e. host) does not
itself NUL-terminate the output buffer the way bb_nv_get_str's
bb_strlcpy-based implementation did, and bb_tls_creds' NVS read buffer is
heap-allocated via malloc (not zeroed) -- without the fix, a short read
could leave strlen() scanning into uninitialized heap.

Host tests for all three now register fake_nvs_backend.h's fake "nvs"
bb_storage backend (mirroring bb_settings' precedent) instead of relying
on bb_nv's private host in-memory store, and the tcp/udp round-trip tests
gained literal-address BITE assertions -- the prior versions only checked
BB_OK, never that the persisted value actually landed at the byte-compat
address. Two new tests (cert/key resolve-failure propagation) backfill
real coverage for branches w... (continued)

6896 of 7533 branches covered (91.54%)

Branch coverage included in aggregate %.

23 of 23 new or added lines in 3 files covered. (100.0%)

11590 of 11859 relevant lines covered (97.73%)

2401.22 hits per line