mirror of
https://github.com/Perl/perl5.git
synced 2026-01-26 08:38:23 +00:00
343b977ef3
GH #23903 In embed.fnc, commit v5.43.3-167-g45ea12db26 added SPTR, EPTR parameter modifiers to (amongst other API functions), Perl_pregexec(). These cause assert constraints to be added to the effect that SPTR < EPTR (since the latter is supposed to be a pointer to the byte after the last character in the string). This falls down for an empty string since in this case pregexec() is called with strbeg == strend. This was causing an assert failure in the test suite for Package-Stash-XS. The reason it wasn't noticed before is because: 1) pregexec() is a thin wrapper over regexec_flags(); 2) The perl core (e.g. pp_match()) calls regexec_flags() rather than pregexec(); 3) Package::Stash::XS has XS code which calls pregexec() directly rather than using CALLREGEXEC() (which would call regexec_flags()); 4) In embed.fnc, regexec_flags()'s strend parameter is declared as NN rather than EPTR, so it doesn't get the assert added. So very little code was actually using pregexec(). This commit, for now, changes pregexec()'s strend parameter from EPTR to EPTRQ, which has the net effect of allowing zero-length strings to be passed, and thus fixes the CPAN issue. But longer term, we need to decide: is the general logic for EPTR wrong? Should the assert be SPTR <= EPTR? And should EPTR be applied to regexec_flags()'s strend parameter too?