@@ -941,15 +941,15 @@ S_pad_check_dup(pTHX_ PADNAME *name, U32 flags, const HV *ourstash)
941941 }
942942}
943943
944-
945944/*
946945=for apidoc pad_findmy_pv
947946=for apidoc_item pad_findmy_pvn
948947=for apidoc_item pad_findmy_pvs
949948=for apidoc_item pad_findmy_sv
950949
951- Given the name of a lexical variable, including its leading sigil, find its
952- position in the currently-compiling pad.
950+ Given the name of a lexical variable, including its leading sigil, these find
951+ its position in the currently compiling pad, returning that offset, or
952+ C<NOT_IN_PAD> if no such lexical is in scope.
953953
954954If it is not in the current pad but appears in the pad of any lexically
955955enclosing scope, then a pseudo-entry for it is added in the current pad.
@@ -965,9 +965,10 @@ enclosed in double quotes.
965965In plain C<pad_findmy_pv>, the variable name is a C language NUL-terminated
966966string.
967967
968- In C<pad_findmy_pvn>, C<namelen> gives the length of the variable name in bytes,
969- so it may contain embedded-NUL characters. The caller must make sure C<namepv>
970- contains at least C<namelen> bytes.
968+ In C<pad_findmy_pvn>, C<namepv> points to the first byte of the name (which
969+ better be its sigil), and an additional parameter, C<namelen>, specifies its
970+ length in bytes. Hence, C<namepv> may contain embedded-NUL characters. The
971+ caller must make sure C<namepv> contains at least C<namelen> bytes.
971972
972973In C<pad_findmy_sv>, the variable name is taken from the SV parameter using
973974C<L</SvPVutf8>()>.
0 commit comments