dangernoodle-io / breadboard / 29785157504

96%

push

github

feat: add opt-in shortest-round-trippable f64 JSON formatting (B1-1102) (#965)

- bb_json_write_f64_shortest() in bb_serialize_json.c: NaN/Inf -> null,
  otherwise mirrors cJSON v1.7.18's print_number() byte-for-byte, INCLUDING
  its int32 fast-path (a whole-number double within int32 range prints via
  "%d" of a saturating int cast, not %g -- verified against actual cJSON
  output, not assumed; this is why -0.0 emits "0" not "-0", since an int
  has no negative-zero representation). Non-fast-path values use
  snprintf("%.15g") then replicate cJSON's own compare_double() exactly
  (relative-epsilon accept: fabs(reparse - v) <= fmax(fabs(reparse),
  fabs(v)) * DBL_EPSILON), upgrading to "%.17g" only when that check
  fails.
- corrects an earlier draft of this change that used an exact strtod()
  round-trip (== v) instead of cJSON's fuzzy compare_double(). That was
  NOT merely stricter-but-harmless: it was CONFIRMED reachable, not
  theoretical. nextafter(10.0, 0.0) == 9.9999999999999982 is a real
  counterexample -- cJSON's compare_double() accepts the %.15g reparse
  and emits "10"; the exact-== check rejected it and emitted
  "9.9999999999999982", a byte divergence from cJSON. Roughly 12.2%%
  of non-fast-path doubles fall in this exact-vs-epsilon divergence band,
  and any PATCH-writable setpoint can put such a double on the wire. This
  is now eliminated by construction -- the acceptance test is verbatim
  cJSON's compare_double(), not an approximation of it.
- selection is render-level, not per-field: new bool f64_shortest on
  bb_serialize_json_ctx_t, default false. bb_json_cb_emit_f64 branches on
  it for every BB_TYPE_F64 field.
- threaded via new _ex siblings on all four render entry points
  (bb_serialize_json_render_ex/_render_ref_ex/_stream_render_ex/
  _stream_compose_render_ex), each taking a trailing f64_shortest bool --
  same idiom as bb_cache_register_ex()/bb_queue_create_ex(). Existing
  entry points are now thin wrappers forwarding... (continued)

7568 of 8182 branches covered (92.5%)

Branch coverage included in aggregate %.

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

12824 of 12995 relevant lines covered (98.68%)

1186.99 hits per line