I looked into this and hit a real blocker around the sanitizer environment, so I'm pausing before opening a PR.
What I found
A msan_driver variant of fuzz_driver (built from `ConflictSet.c…
16f5d3cd9d
Merge pull request 'Handle null parser in WeaselJsonParser_parse' (#54) from null-parser into main
Thanks for the follow-up commit — this addresses most of the prior round's feedback: the header doc comment now mentions the null-parser behavior, the validate.cpp message is clearer ("parse called with a null parser"), and the new test now mirrors issue #51's exact reproduction (WeaselJsonParser_parse(nullptr, nullptr, 0) == WeaselJson_NULL), which cleanly isolates the null-parser case from the negative-length case. I verified the new test passes and that the build is clean under -Werror=switch-enum -Wswitch-enum.
The C enum now has WeaselJson_NULL (value 4), but this Python enum stops at OVERFLOW = 3. It's never returned through the bindings today (parse() raises via _check_open before calling into C when the parser is null), but please add NULL = 4 here so the two stay in sync — otherwise a future change that lets the raw status through would surface an unmapped value.
Thanks for fixing the null-parser crash in WeaselJsonParser_parse - the change is correct, the new test passes, and I verified the full suite (24/24) is green with this branch.
This couples the null-parser check with the negative-length case. Because the null check runs first it returns WeaselJson_NULL, but it would be clearer to use a valid length (e.g. WeaselJsonParser_parse(nullptr, buf, 5)) so the test isolates the null-parser behavior. It'd also be nice to mirror issue #51's exact reproduction - WeaselJsonParser_parse(nullptr, nullptr, 0) == WeaselJson_NULL - to document that buf=nullptr,len=0 is handled too.
This message ("Could not create parser") describes a different condition than the status: it's reached when parse() is called with a null pointer, not when create() failed. Something like fprintf(stderr, "parse called with a null parser\n"); would be clearer. (In this program the two coincide because parser.get() is only null when create failed, but the wording is still misleading relative to the status name.)
The doc comment covers the negative-length behavior but not the null-parser behavior added in this PR. Please add a sentence, e.g. "If parser is null, parse returns WeaselJson_NULL (or WeaselJson_REJECT) without dereferencing it.", so the header stays self-consistent with the implementation.
Adding a new member to this public C ABI enum is the most impactful part of this PR. Issue #51 suggested returning WeaselJson_REJECT (a null parser can never accept input), which would fix the crash without changing the ABI. Since the project compiles with -Werror=switch-enum -Wswitch-enum, any switch over WeaselJsonStatus now has to handle this new case (hence the validate.cpp change), and external consumers using -Wswitch/-Werror will break on upgrade. If a distinct status is desired for diagnostics that's fine, but consider reusing WeaselJson_REJECT to avoid an ABI bump - or at least call out in the header that this is a newly-added status callers must handle.