g_json_parse_err is never reset by lenient JSON callers, so one malformed parse poisons the next json_path in the same thread

[Nitjsefnie]

Describe the bug

g_json_parse_err (src/builtins.c:979) is only ever reset in builtin_json_decode
(src/builtins.c:1199). Every other consumer of the JSON parser leaves it set, so one malformed
parse silently poisons the next parse in the same thread.

The comment above the flag (src/builtins.c:971-978) says lenient callers "ignore it" — and they do,
in the sense that they don't raise. But the parser itself checks it mid-parse, so ignoring it is
not enough: it has to be cleared.

builtin_json_path (src/builtins.c:2764) calls eigs_json_parse_value at :2784 with no reset —
that is the place that should clear it and doesn't. Same for src/ext_http.c:411, :623, :682 and
:1298.

The poison lands at two checks inside the parser:

• object key check, src/builtins.c:1131 — if (!key || g_json_parse_err) fires on the first key of
  the next parse, so a perfectly good object decodes to an empty dict;
• array element check, :1112 — fires after the first element, so an array decodes to a
  one-element list.

That object/array asymmetry is worth knowing: the same poisoned state truncates arrays but empties
objects.

To reproduce

No strict decode is needed — the lenient path poisons itself:

x is json_path of ["{\"a\": \"unterminated", "a"]
print of x
y is json_path of ["{\"user\": {\"name\": \"bob\"}}", "user.name"]
print of y

Expected behavior

The second json_path is a fresh, well-formed document and should print bob. A previous malformed
parse should not affect it.

Actual behavior

unterminated

The second line is empty. len of it is 0.

The same happens after a strict decode that raises: try: json_decode of "\"abc" catch … followed by
the well-formed json_path also prints empty.

Environment

• OS: Debian 13 (x86_64)
• GCC version: 14
• EigenScript version: 0.34.0, main @ abf8294

---

Found while working #724. Context that may be useful when you fix it: the #724 branch deliberately
keeps its recoverable substitutions (unpaired surrogate, escaped NUL, malformed \u) off this flag
on a separate channel, precisely so they don't widen the poison surface. Structural errors —
unterminated string, truncation, bad number — behave exactly as they do here on main.

Happy to send the reset as a PR if you'd like it, though where it belongs (each caller, or a helper
that owns the flag's lifetime) is your architectural call rather than mine to guess.

[InauguralPhysicist]

Confirmed on main @ 8661271 — your repro reproduces exactly: the second, well-formed json_path returns an empty string (len 0). The object-empties/array-truncates asymmetry note is a good catch; that's the kind of detail that saves the next debugging session.

On the architectural question you left open — a single root wrapper that owns the flags' lifetime, not per-caller resets. Concretely: an eigs_json_parse_root(const char *s, int *pos) that clears the error state and delegates to eigs_json_parse_value, with all six entry points (json_decode, json_path, the four ext_http.c sites) migrated to it. Reasoning:

• Per-caller resets are exactly how this bug happened — json_decode remembered, everyone else forgot. Adding five more remembering-sites reproduces the failure mode it fixes.
• The parser can't clear the flag itself because eigs_json_parse_value is recursive; the wrapper is the natural non-recursive entry that can.
• The reset should clear both channels — g_json_parse_err and the g_json_parse_recoverable flag json_decode: combine surrogate pairs, and stop an escaped NUL truncating the string #778 introduced — so the wrapper becomes the one place that defines "fresh parse."

Please do send the PR. Acceptance bar: a regression test covering both poison paths you identified (lenient-after-lenient and lenient-after-strict-raise), plus the object and array truncation shapes.

Labeling bug / help wanted.