[akashdeshmukh-git]

pcre2_next_match() unconditionally dereferenced its pointer arguments (match_data->start_offset, match_data->ovector) without validating that match_data, pstart_offset, or poptions were non-NULL. Additionally, the internal do_bumpalong() helper dereferenced match_data->code to query newline and UTF options without verifying that match_data->code is non-NULL.

This change:

1. Adds PCRE2_ASSERT() preconditions and returns FALSE early if match_data, pstart_offset, or poptions is NULL.
2. Guards match_data->code and match_data->subject in do_bumpalong() when inspecting newline conventions and advancing across code units.
3. Extends unittest() in src/pcre2test_inc.h with test coverage verifying that NULL arguments safely return FALSE.
4. Documents the NULL pointer return behaviour in doc/pcre2api.adoc and doc/pcre2_next_match.adoc.

[NWilson]

We should not add runtime checks for preconditions.

[NWilson]

Interesting - elsewhere in PCRE2, do we make the assumption that ->code fields are non-null if match_data->rc is a success?

It's possible that we do. What was the scenario that you wanted to guard against here, in terms of a practical use-case?

I can only imagine here that the match_data has simply not even been passed to pcre2_match.

[akashdeshmukh-git]

@NWilson Thanks. You're right: after a successful match code is always set; it can only be unset if the match_data was never passed to a match function, which is a caller error. I've reduced the PR to precondition assertions only, as on #1052: no runtime checks, and the do_bumpalong guards, doc and test changes are dropped.