Using C string functions on Perl strings doesn't work properly if they
contain embedded NULs. This can happen with Perl program text, for
example, and even if the NUL is illegal, the generated diagnostics are
likely to be misleading as the parsing would have terminated
prematurely.
I have done an audit on core for cases where C string functions are used
in contexts where a Perl string is being processed. This came down to
uses of strchr() and strrchr(). This branch changes many of them to
memchr() and memrchr() respectively. Not all uses of these functions
need change, as there are places where C strings are what is being
processed, such as dealing with OS strings that are NUL terminated.
File paths and environ are two examples.
Also, memchr and memrchr tend to be faster than their str equivalents,
as they only need to look for one termination condition, and there may
be hardware assistance on some platforms. Further, memrchr knows
exactly where to start looking, instead of having to find the NUL ending
the string (strrchr is likely to be implemented as iterating over the
string using strchr from the left, over and over until it fails).
I may have converted some str functions to mem ones unnecessarily, as I
didn't check in full detail if some were operating only on C strings, but
given that the mem ones are faster, this is OK