Parson’s simplicity and small footprint are major strengths, especially for embedded/native projects.
Because lightweight C JSON parsers are frequently used in:
- embedded systems,
- networking software,
- CLIs,
- agents/tools,
- and security-sensitive infrastructure,
I think parser robustness guarantees are becoming increasingly important.
Has there been any consideration for adding:
- continuous libFuzzer/AFL++ coverage-guided fuzzing,
- differential testing against other mature JSON parsers,
- property-based malformed-input testing,
- or sanitizer-backed CI (ASan/UBSan/MSan)?
Potential benefits:
- detect parser ambiguity edge cases,
- catch undefined behavior on malformed UTF-8 / deep nesting,
- identify integer-overflow or recursion-depth issues,
- validate serialization ↔ parsing roundtrip invariants,
- and strengthen confidence for embedded/security-critical adopters.
One especially interesting direction could be:
“Differential parsing mode”
where Parson outputs are continuously compared against parsers like:
- cJSON,
- Jansson,
- yyjson,
- RapidJSON,
- simdjson,
for randomly generated edge-case documents.
Given Parson’s small codebase, it seems uniquely positioned to become one of the most formally trustworthy lightweight C JSON parsers if fuzzing and invariant validation were first-class parts of CI.
Curious whether this aligns with the project’s long-term maintenance philosophy.
Parson’s simplicity and small footprint are major strengths, especially for embedded/native projects.
Because lightweight C JSON parsers are frequently used in:
I think parser robustness guarantees are becoming increasingly important.
Has there been any consideration for adding:
Potential benefits:
One especially interesting direction could be:
“Differential parsing mode”
where Parson outputs are continuously compared against parsers like:
for randomly generated edge-case documents.
Given Parson’s small codebase, it seems uniquely positioned to become one of the most formally trustworthy lightweight C JSON parsers if fuzzing and invariant validation were first-class parts of CI.
Curious whether this aligns with the project’s long-term maintenance philosophy.