Branch: refs/heads/davem/gh23903
Home: https://github.com/Perl/perl5
Commit: 8993af9d1f44c04b8feaea56f46fbb33703e67a5
https://github.com/Perl/perl5/commit/8993af9d1f44c04b8feaea56f46fbb33703e67a5
Author: David Mitchell <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M embed.fnc
M ext/XS-APItest/APItest.pm
M ext/XS-APItest/APItest.xs
M ext/XS-APItest/t/callregexec.t
M proto.h
Log Message:
-----------
make pregexec() handle zero-length strings again
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?
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
