Problem
The project currently uses custom parsers for Markdown and LaTeX (MathML conversion) without any fuzz testing. Given the complexity and typical issues with string parsing, there is risk of crashes, infinite loops, buffer overflows, or silent rendering failures with malformed or adversarial input—especially as parsing failures currently exit silently or degrade without logging.
Proposed Solution
- Integrate a fuzz testing framework (e.g., LLVM libFuzzer) for key parsing entry points such as
render_markdown() and math_to_mathml().
- Create test harnesses or standalone binaries exposing these functions to the fuzzer.
- Add GitHub Actions job and badge for continuous fuzzing on PRs (or run locally with a script)
- Document the process and provide sample inputs that triggered bugs.
Acceptance Criteria
- Crash, buffer overflow, and infinite loop bugs are caught by fuzzing
- Corpus of test cases is maintained with representative edge cases
- Fuzzing is reproducible/documented for contributors
References
Problem
The project currently uses custom parsers for Markdown and LaTeX (MathML conversion) without any fuzz testing. Given the complexity and typical issues with string parsing, there is risk of crashes, infinite loops, buffer overflows, or silent rendering failures with malformed or adversarial input—especially as parsing failures currently exit silently or degrade without logging.
Proposed Solution
render_markdown()andmath_to_mathml().Acceptance Criteria
References