These internal functions can handle empty strings, but it aren't called
with those so far, and it is better practice to not call them with an
empty string, so guard against it now.
This makes sure the terminating character is a NUL. This internal
function isn't documented as having that requirement, but that's always
the case in our test suite. And functions it calls assume there is at
least one character in the input, so the assertion shouldn't be EPTRge,
and the test suite fails if it is EPTRgt.
This function takes a string argument with beginning and ending
positions. It appears to me that those positions are overwritten
without being examined, but the function does get called with an
apparently empty string, but it actually contains a NUL.
Some functions take arguments that point to the terminating NUL
character of a string. This commit adds a way to declare in embed.fnc
that a given argument is of that kind.
This commit adds an entry in embed.fnc for S_is_dup_mode, removing the
assert and __attribute lines in op.c.
The proximal cause for this commit is that I tried compiling with
Perl_assert() enabled, which resulted in a lot of compiler warnings
because of the __attribute__non_null__ line
But I also think it is better to not hand-roll things unless absolutely
necessary. Changes someone makes to the general scheme are not likely
to be propagated to the hand-rolled items.
some refactoring next, since sv_numeq_flags and sv_numne_flags are
similar.
Used a separate test file since putting every sv_num*() variant in the
one file would be ugly
Addresses GH #23918 but isn't a direct fix
Rather than copy-pasted code in two places, define a helper function to
call from both. This also accounts for minor (but currently
inconsequential) differences in behaviour between the two copy-pasted
locations, that seem to have drifted apart over time.
This internal function looks problematic with regard to handling empty
strings, but it isn't ever called with one so far. Change to catch such
calls that might get added in the future.
This internal function can handle empty strings, but it isn't ever
called with one so far, and it is better practice to not call it with an
empty string
These functions take a string argument with beginning and ending
positions. They handle the case of an empty string properly, and the
documentation says they handle empty strings.
This function takes a string with a beginning and ending pointer. It
doesn't dereference if the string is empty, and returns the correct
value when empty, and does get called with empty strings.
These two functions examine their input string without checking if it is
zero length. So, the assertion needs to change. They aren't ever
called with an empty string.
92dcf59a90bfbb545599098d7043c96abb783ee5 changed newly-created macros to
be affected by the apidoc visibility flags. This commit updates the
comments in embed.fnc to reflect that.
This file was originally written to handle functions and the short name
macros that call them.
But its contents have gradually been expanded over the years, without
fully updating the comments to reflect that.
This commit rewords things so that text that refers to more than just
functions is generalized.
An enum constant isn't a macro; it can't be #undef-ined. This
distinction will matter in a future commit, so create a separate flag
for elements like this. I suspect this would also apply to other types
of elements, such as struct members, should we eventually need to deal
with those.
This is required for the next few commits that start automatically
creating long Perl_name functions for the elements in embed.fnc that are
macros and don't already have them in the source.
Only macros can take a parameter that has to be a literal string, so
don't fit with the next few commits. This is the only case in embed.fnc
like that, so I'm deferring dealing with it for now.
These keywords all need another word to indicate the parameter type.
Previously only 'struct' was considered to have.
This changed showed an error in one entry embed.fnc, which is also
corrected in this commit.
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?
