[lcn2]

Performed a major code audit.

Harden parser allocation and length handling across JSON decode and scanner entry points

This PR audits the parser and supporting utilities for high-confidence
memory-safety and logic issues, with emphasis on allocation sizing, decode
paths, scanner length boundaries, and exact-length buffer handling. The
changes target overflow/OOB conditions in public and internal APIs while
preserving existing parser behavior for valid inputs.

• JSON decode and encode bounds

  • Added checked size_t helpers for additive/multiplicative allocation math.
  • Guarded encoded/decoded length accumulation before allocation and before buffer growth assumptions.
  • Hardened decode buffer allocation against wrapped mlen + 2 sizing.

• Malformed \u escape handling

  • Changed utf8len() to return a signed length so malformed escapes propagate failure instead of wrapping to SIZE_MAX.
  • Updated JSON decode paths to reject invalid UTF-8 escape length results before folding them into decoded-size calculations.

• Scanner length boundary

  • Added an explicit INT_MAX guard before passing caller-controlled lengths into flex yy_scan_bytes().
  • Oversized inputs now fail safely instead of truncating through the scanner’s signed-length boundary.

• Exact-length API correctness

  • Fixed json_conv_bool() and json_conv_null() to copy exactly len bytes and terminate locally.
  • This removes the implicit read of len + 1 bytes from caller-provided slices that are not required to be NUL-terminated.

• Overflow hardening in utility paths

  • Applied checked allocation sizing to helper paths that duplicate or build derived strings
    (jstrencode, jstrdecode, jsemtblgen, verge).
  • Synced the scanner source change into the checked-in flex reference files used by non-regenerated builds.

• Focused regression coverage

  • Added a small API-level regression test binary covering:
    • malformed Unicode escapes
    • exact-length boolean/null slices
    • oversized parse_json() length rejection

Example of the exact-length fix:

    item->as_str = calloc(alloc_len, sizeof(*(item->as_str)));
    memcpy(item->as_str, ptr, len);
    item->as_str[len] = '\0';

In theory, the normal execution of this code should be identical to
"Release 2.5.11 2026-08-03", except in extreme or unusual cases.

Updated JPARSE_REPO_VERSION to "2.6.0 2026-09-25".
Updated JPARSE_TOOL_VERSION to "2.1.0 2026-09-25".
Updated JPARSE_LIBRARY_VERSION to "2.5.0 2026-09-25".
Updated JPARSE_UTILS_VERSION to "2.2.0 2026-06-25".

[Copilot]

Copilot review overview

🟡 Changes recommended

The checked-in parser reference artifact is out of sync, and several shipped component version identifiers remain stale.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Regenerate fallback parser artifact to sync error codes · New
• Bump UTF-8 API version for utf8len contract change · New

What changed in this PR

Release 2.6.0 hardens parser allocation, Unicode decoding, scanner length handling, and exact-length APIs, with focused regression tests.

Changes:

• Adds checked allocation arithmetic and malformed Unicode handling.
• Enforces scanner length limits and safe exact-length copying.
• Adds API regression tests and updates release metadata.

File	Reviewed change
version.h	Updates core release versions
verge.c	Hardens version-array allocation
util.h	Adds overflow helpers
test_jparse/​Makefile	Builds and runs API tests
test_jparse/​json_api_test.c	Adds regression coverage
jstrencode.c	Checks duplicate-buffer sizing
jstrdecode.c	Checks duplicate-buffer sizing
json_utf8.h	Changes UTF-8 length API
json_utf8.c	Propagates malformed escape failures
json_parse.c	Hardens encoding, decoding, and conversions
jsemtblgen.c	Checks generated-name allocation sizing
jparse.y	Updates parser error sequencing
jparse.ref.c	Adds scanner length validation
jparse.l	Adds scanner length validation
CHANGES.md	Documents release changes
.gitignore	Ignores the new test binary

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xexyl]

Well done @lcn2. Thanks! I do not know what Copilot is talking about and I am afraid that I can't check now but I am much more confident in you than it.

If however you seem to think it has any merit please do address it.

I cannot understand why it thinks versions are 'stale' though so unless I read it wrong (entirely possible atm) I can't fathom that objection.

[xexyl]

I now know what Copilot was whining about. I fixed it. If you would please, @lcn2, sync it to mkiocccentry that would be helpful - since you've been making a lot of changes (and I have other things I wish to do too).

Thanks!