dangernoodle-io / breadboard / 30185195802

97%

push

github

refactor(bb_storage): make bb_storage_txn_t capacity caller-sized (B1-1235 PR1) (#1096)

bb_storage_txn_t's slot table was a single repo-wide
BB_STORAGE_TXN_MAX_KEYS-sized array embedded in the struct, so any consumer
needing one more key forced every other consumer to pay for a wider table.
The handle is caller-allocated (no heap) by design, so the slot table can
instead be caller-owned backing storage sized per-txn.

- bb_storage_txn_slot_t is now a PUBLIC named type (was an anonymous member
  of bb_storage_txn_t's _slots array) -- a non-obvious but intentional
  consequence of caller-owned storage; callers declare arrays of it but must
  never inspect its fields.
- bb_storage_txn_t carries `_slots`/`_cap` (caller-owned pointer + caller-
  declared capacity) instead of an embedded array.
- bb_storage_txn_begin() gains `slots`/`cap` parameters, wired onto the txn
  before any vtable call -- backend txn_begin/txn_set/txn_commit/txn_abort
  fn-ptr signatures are unchanged (still take only `bb_storage_txn_t *`).
- New BB_STORAGE_TXN_DECLARE(name, n) / BB_STORAGE_TXN_DECLARE_DEFAULT(name)
  ergonomics macros.
- Every production loop bound keyed on BB_STORAGE_TXN_MAX_KEYS (bb_storage.c
  slot_stage, bb_storage_ram/bb_storage_rtc host+espidf commit/abort,
  fake_nvs_backend.h) now reads txn->_cap instead.
- Kconfig BB_STORAGE_TXN_MAX_KEYS is repurposed as the default capacity for
  BB_STORAGE_TXN_DECLARE_DEFAULT (no longer a repo-wide ceiling); floor
  relaxed from 3 to 1 -- the old floor protected bb_storage_rtc's fixed
  3-key commit under the single-global-cap model, now documented as a
  runtime, backend-scoped BB_ERR_NO_SPACE contract on bb_storage_rtc.h
  instead.
- bb_config_staged_t (the one existing multi-consumer wrapper) keeps its
  public API unchanged for this PR -- it now owns a private
  BB_STORAGE_TXN_MAX_KEYS-sized default backing array, wired internally at
  begin(), so every existing bb_settings.c consumer stays at its current
  capacity... (continued)

7794 of 8397 branches covered (92.82%)

Branch coverage included in aggregate %.

19 of 19 new or added lines in 4 files covered. (100.0%)

13245 of 13400 relevant lines covered (98.84%)

2620.16 hits per line