Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: da0069eeb43c24e88dadfd16e89793230ba9e8e7
https://github.com/Perl/perl5/commit/da0069eeb43c24e88dadfd16e89793230ba9e8e7
Author: Karl Williamson <[email protected]>
Date: 2026-01-30 (Fri, 30 Jan 2026)
Changed paths:
M embed.fnc
M proto.h
Log Message:
-----------
embed.fnc: Add ptr args assert for unpack_rec, unpackstring
unpackstring(), which is public API, does some setup and calls
unpack_rec(), which is an internal function.
Each function takes two strings as arguments; each string is denoted by
a beginning and ending pointer. The documentation for unpackstring()
says that the end pointers for both strings should point to one byte
beyond the final byte of the respective string. This is false. The end
pointers can point to the same byte as their respective start pointers.
And the test suite has tests where that gets exercised.
Thus the documentation says that the end pointer must be greater than
the start pointer, but the functions do get tested (and pass) with the
end pointer equal to the start pointer. It turns out that in each case
of that in the test suite, that that byte is NUL. Given the
documentation, I wondered if it being NUL is a requirement for proper
operation. I considered adding an EPTRgt_or_NUL rule for these two
functions.
To that end, I read the code to see if they would work without it being
NUL. In the case of the pattern string, yes, it would work without that
being NUL, so the assertion can be the existing EPTRge.
I gave up checking this for the target string argument. The uses of
this are quite complex, and little documented, with many paths through
the code. Some paths I traced do work without the byte being NUL. But
I don't know about all paths. So I changed this assertion as well to
EPTRge.
I decided to leave the documentation as-is, so callers will try to use a
strictly gt paradigm.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
