dangernoodle-io / breadboard / 30870703062

97%

push

github

feat: add bb_data table producer shape + per-row console render (#1218)

bb_serialize already supports table shapes end-to-end for JSON via
BB_TYPE_ARR + elem_type == BB_TYPE_OBJ, and bb_data_render() needed no
change for that path. The real gap was console-only: bb_serialize_console's
begin_arr/begin_obj are documented no-ops that never key-qualify nested
fields, so a table descriptor walked straight through renders as one
flattened, duplicate-keyed line. bb_serialize_console_tasks_report()
already ships the fix (gather rows, render once per row); this applies
that same per-row idiom behind bb_data's binding table. It does NOT
migrate bb_serialize_console_tasks_report()'s own live caller onto the
new path -- that is deliberately deferred to a tracked follow-up.

- bb_data_binding_t gains an OPTIONAL rows field (bb_data_row_binding_t);
  bb_data_bind() validates row_size == row_desc->snap_size when set.
- bb_data_render_rows() is the new, console-only entry point: looks up the
  binding, gathers into caller-owned row_scratch, and renders + emits one
  line per row via a caller-supplied emit_row callback (host-testable,
  format-neutral -- no bb_log_i() baked in).
- bb_data_row_gather_fn's contract is now stated in MUST-NOT language:
  the hook must never write past max_rows rows into dst_rows, since
  bb_data_render_rows()'s row-count clamp only bounds its own render loop
  after the fact and cannot protect the caller's buffer from an overrun
  that already happened inside the hook.
- The internal per-row line buffer (160 bytes) is documented as an
  independent, bb_data-owned bound -- it does not bridge
  bb_serialize_console's Kconfig (a layering violation bb_data avoids by
  design), it only happens to match that component's own default today.
- Added a host test pinning the documented behavior for a row whose
  rendered content exceeds that 160-byte bound (silent, NUL-terminated
  truncation, not an error).
- Deliberately additive: every existing ... (continued)

8326 of 8888 branches covered (93.68%)

Branch coverage included in aggregate %.

22 of 22 new or added lines in 1 file covered. (100.0%)

14054 of 14209 relevant lines covered (98.91%)

2608.66 hits per line