(perl #133706) remove exploit code from Storable

[perl5.git] / pod / perlfunc.pod

diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 89e44da..664e2a3 100644 (file)
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -522,6 +522,10 @@ argument is omitted, tests L<C<$_>|perlvar/$_>, except for C<-t>, which
 tests STDIN.  Unless otherwise documented, it returns C<1> for true and
 C<''> for false.  If the file doesn't exist or can't be examined, it
 returns L<C<undef>|/undef EXPR> and sets L<C<$!>|perlvar/$!> (errno).
 tests STDIN.  Unless otherwise documented, it returns C<1> for true and
 C<''> for false.  If the file doesn't exist or can't be examined, it
 returns L<C<undef>|/undef EXPR> and sets L<C<$!>|perlvar/$!> (errno).

+With the exception of the C<-l> test they all follow symbolic links
+because they use C<stat()> and not C<lstat()> (so dangling symlinks can't
+be examined and will therefore report failure).
+

 Despite the funny names, precedence is the same as any other named unary
 operator.  The operator may be any of:
 
 Despite the funny names, precedence is the same as any other named unary
 operator.  The operator may be any of:
 


@@ -1595,10 +1599,13 @@ so that L<C<exists>|/exists EXPR> on that element no longer returns
 true.  Setting a hash element to the undefined value does not remove its
 key, but deleting it does; see L<C<exists>|/exists EXPR>.
 
 true.  Setting a hash element to the undefined value does not remove its
 key, but deleting it does; see L<C<exists>|/exists EXPR>.
 

-In list context, returns the value or values deleted, or the last such
-element in scalar context.  The return list's length always matches that of
+In list context, usually returns the value or values deleted, or the last such
+element in scalar context.  The return list's length corresponds to that of

 the argument list: deleting non-existent elements returns the undefined value
 the argument list: deleting non-existent elements returns the undefined value

-in their corresponding positions.
+in their corresponding positions. When a
+L<keyE<sol>value hash slice|perldata/KeyE<sol>Value Hash Slices> is passed to
+C<delete>, the return value is a list of key/value pairs (two elements for each
+item deleted from the hash).

 
 L<C<delete>|/delete EXPR> may also be used on arrays and array slices,
 but its behavior is less straightforward.  Although
 
 L<C<delete>|/delete EXPR> may also be used on arrays and array slices,
 but its behavior is less straightforward.  Although


@@ -1741,7 +1748,7 @@ exception objects.  See L<overload> for details about that.
 The stringified message should be non-empty, and should end in a newline,
 in order to fit in with the treatment of string exceptions.
 Also, because an exception object reference cannot be stringified
 The stringified message should be non-empty, and should end in a newline,
 in order to fit in with the treatment of string exceptions.
 Also, because an exception object reference cannot be stringified

-without detroying it, Perl doesn't attempt to append location or other
+without destroying it, Perl doesn't attempt to append location or other

 information to a reference exception.  If you want location information
 with a complex exception object, you'll have to arrange to put the
 location information into the object yourself.
 information to a reference exception.  If you want location information
 with a complex exception object, you'll have to arrange to put the
 location information into the object yourself.


@@ -1918,9 +1925,8 @@ be open any more when the program is reincarnated, with possible
 resulting confusion by Perl.
 
 This function is now largely obsolete, mostly because it's very hard to
 resulting confusion by Perl.
 
 This function is now largely obsolete, mostly because it's very hard to

-convert a core file into an executable.  That's why you should now invoke
-it as C<CORE::dump()> if you don't want to be warned against a possible
-typo.
+convert a core file into an executable.  As of Perl 5.30, it must be invoked
+as C<CORE::dump()>.

 
 Unlike most named operators, this has the same precedence as assignment.
 It is also exempt from the looks-like-a-function rule, so
 
 Unlike most named operators, this has the same precedence as assignment.
 It is also exempt from the looks-like-a-function rule, so


@@ -1966,7 +1972,8 @@ its own internal iterator, accessed by L<C<each>|/each HASH>,
 L<C<keys>|/keys HASH>, and L<C<values>|/values HASH>.  The iterator is
 implicitly reset when L<C<each>|/each HASH> has reached the end as just
 described; it can be explicitly reset by calling L<C<keys>|/keys HASH>
 L<C<keys>|/keys HASH>, and L<C<values>|/values HASH>.  The iterator is
 implicitly reset when L<C<each>|/each HASH> has reached the end as just
 described; it can be explicitly reset by calling L<C<keys>|/keys HASH>

-or L<C<values>|/values HASH> on the hash or array.  If you add or delete
+or L<C<values>|/values HASH> on the hash or array, or by referencing
+the hash (but not array) in list context.  If you add or delete

 a hash's elements while iterating over it, the effect on the iterator is
 unspecified; for example, entries may be skipped or duplicated--so don't
 do that.  Exception: It is always safe to delete the item most recently
 a hash's elements while iterating over it, the effect on the iterator is
 unspecified; for example, entries may be skipped or duplicated--so don't
 do that.  Exception: It is always safe to delete the item most recently


@@ -1980,6 +1987,21 @@ returned by L<C<each>|/each HASH>, so the following code works properly:
 Tied hashes may have a different ordering behaviour to perl's hash
 implementation.
 
 Tied hashes may have a different ordering behaviour to perl's hash
 implementation.
 

+The iterator used by C<each> is attached to the hash or array, and is
+shared between all iteration operations applied to the same hash or array.
+Thus all uses of C<each> on a single hash or array advance the same
+iterator location.  All uses of C<each> are also subject to having the
+iterator reset by any use of C<keys> or C<values> on the same hash or
+array, or by the hash (but not array) being referenced in list context.
+This makes C<each>-based loops quite fragile: it is easy to arrive at
+such a loop with the iterator already part way through the object, or to
+accidentally clobber the iterator state during execution of the loop body.
+It's easy enough to explicitly reset the iterator before starting a loop,
+but there is no way to insulate the iterator state used by a loop from
+the iterator state used by anything else that might execute during the
+loop body.  To avoid these problems, use a C<foreach> loop rather than
+C<while>-C<each>.
+

 This prints out your environment like the L<printenv(1)> program,
 but in a different order:
 
 This prints out your environment like the L<printenv(1)> program,
 but in a different order:
 


@@ -1993,6 +2015,10 @@ been deemed unsuccessful, and was removed as of Perl 5.24.
 
 As of Perl 5.18 you can use a bare L<C<each>|/each HASH> in a C<while>
 loop, which will set L<C<$_>|perlvar/$_> on every iteration.
 
 As of Perl 5.18 you can use a bare L<C<each>|/each HASH> in a C<while>
 loop, which will set L<C<$_>|perlvar/$_> on every iteration.

+If either an C<each> expression or an explicit assignment of an C<each>
+expression to a scalar is used as a C<while>/C<for> condition, then
+the condition actually tests for definedness of the expression's value,
+not for its regular truth value.

 
     while (each %ENV) {
        print "$_=$ENV{$_}\n";
 
     while (each %ENV) {
        print "$_=$ENV{$_}\n";


@@ -3370,6 +3396,13 @@ See L<File::Glob> for details, including
 L<C<bsd_glob>|File::Glob/C<bsd_glob>>, which does not treat whitespace
 as a pattern separator.
 
 L<C<bsd_glob>|File::Glob/C<bsd_glob>>, which does not treat whitespace
 as a pattern separator.
 

+If a C<glob> expression is used as the condition of a C<while> or C<for>
+loop, then it will be implicitly assigned to C<$_>.  If either a C<glob>
+expression or an explicit assignment of a C<glob> expression to a scalar
+is used as a C<while>/C<for> condition, then the condition actually
+tests for definedness of the expression's value, not for its regular
+truth value.
+

 Portability issues: L<perlport/glob>.
 
 =item gmtime EXPR
 Portability issues: L<perlport/glob>.
 
 =item gmtime EXPR


@@ -3430,7 +3463,11 @@ Use of C<goto LABEL> or C<goto EXPR> to jump into a construct is
 deprecated and will issue a warning.  Even then, it may not be used to
 go into any construct that requires initialization, such as a
 subroutine, a C<foreach> loop, or a C<given>
 deprecated and will issue a warning.  Even then, it may not be used to
 go into any construct that requires initialization, such as a
 subroutine, a C<foreach> loop, or a C<given>

-block.  It also can't be used to go into a
+block.  In general, it may not be used to jump into the parameter
+of a binary or list operator, but it may be used to jump into the
+I<first> parameter of a binary operator.  (The C<=>
+assignment operator's "first" operand is its right-hand
+operand.)  It also can't be used to go into a

 construct that is optimized away.
 
 The C<goto &NAME> form is quite different from the other forms of
 construct that is optimized away.
 
 The C<goto &NAME> form is quite different from the other forms of


@@ -3649,7 +3686,8 @@ may behave differently to Perl's hashes with respect to changes in order on
 insertion and deletion of items.
 
 As a side effect, calling L<C<keys>|/keys HASH> resets the internal
 insertion and deletion of items.
 
 As a side effect, calling L<C<keys>|/keys HASH> resets the internal

-iterator of the HASH or ARRAY (see L<C<each>|/each HASH>).  In
+iterator of the HASH or ARRAY (see L<C<each>|/each HASH>) before
+yielding the keys.  In

 particular, calling L<C<keys>|/keys HASH> in void context resets the
 iterator with no other overhead.
 
 particular, calling L<C<keys>|/keys HASH> in void context resets the
 iterator with no other overhead.
 


@@ -3797,9 +3835,10 @@ L<C<continue>|/continue BLOCK> block, if any, is not executed:
         #...
     }
 
         #...
     }
 

-L<C<last>|/last LABEL> cannot be used to exit a block that returns a
-value such as C<eval {}>, C<sub {}>, or C<do {}>, and should not be used
-to exit a L<C<grep>|/grep BLOCK LIST> or L<C<map>|/map BLOCK LIST>
+L<C<last>|/last LABEL> cannot return a value from a block that typically
+returns a value, such as C<eval {}>, C<sub {}>, or C<do {}>. It will perform
+its flow control behavior, which precludes any return value. It should not be
+used to exit a L<C<grep>|/grep BLOCK LIST> or L<C<map>|/map BLOCK LIST>

 operation.
 
 Note that a block by itself is semantically identical to a loop
 operation.
 
 Note that a block by itself is semantically identical to a loop


@@ -4327,9 +4366,10 @@ refers to the innermost enclosing loop.  The C<next EXPR> form, available
 as of Perl 5.18.0, allows a label name to be computed at run time, being
 otherwise identical to C<next LABEL>.
 
 as of Perl 5.18.0, allows a label name to be computed at run time, being
 otherwise identical to C<next LABEL>.
 

-L<C<next>|/next LABEL> cannot be used to exit a block which returns a
-value such as C<eval {}>, C<sub {}>, or C<do {}>, and should not be used
-to exit a L<C<grep>|/grep BLOCK LIST> or L<C<map>|/map BLOCK LIST>
+L<C<next>|/next LABEL> cannot return a value from a block that typically
+returns a value, such as C<eval {}>, C<sub {}>, or C<do {}>. It will perform
+its flow control behavior, which precludes any return value. It should not be
+used to exit a L<C<grep>|/grep BLOCK LIST> or L<C<map>|/map BLOCK LIST>

 operation.
 
 Note that a block by itself is semantically identical to a loop
 operation.
 
 Note that a block by itself is semantically identical to a loop


@@ -6121,6 +6161,10 @@ it would have been testing the wrong file.
 
 As of Perl 5.12 you can use a bare L<C<readdir>|/readdir DIRHANDLE> in a
 C<while> loop, which will set L<C<$_>|perlvar/$_> on every iteration.
 
 As of Perl 5.12 you can use a bare L<C<readdir>|/readdir DIRHANDLE> in a
 C<while> loop, which will set L<C<$_>|perlvar/$_> on every iteration.

+If either a C<readdir> expression or an explicit assignment of a
+C<readdir> expression to a scalar is used as a C<while>/C<for> condition,
+then the condition actually tests for definedness of the expression's
+value, not for its regular truth value.

 
     opendir(my $dh, $some_dir) || die "Can't open $some_dir: $!";
     while (readdir $dh) {
 
     opendir(my $dh, $some_dir) || die "Can't open $some_dir: $!";
     while (readdir $dh) {


@@ -6190,6 +6234,13 @@ L<C<eof>|/eof FILEHANDLE> handles C<ARGV> differently.
         }
     }
 
         }
     }
 

+Like the C<< <EXPR> >> operator, if a C<readline> expression is
+used as the condition of a C<while> or C<for> loop, then it will be
+implicitly assigned to C<$_>.  If either a C<readline> expression or
+an explicit assignment of a C<readline> expression to a scalar is used
+as a C<while>/C<for> condition, then the condition actually tests for
+definedness of the expression's value, not for its regular truth value.
+

 =item readlink EXPR
 X<readlink>
 
 =item readlink EXPR
 X<readlink>
 


@@ -6236,14 +6287,9 @@ string otherwise.  If there's an error, returns the undefined value.
 This call is actually implemented in terms of the L<recvfrom(2)> system call.
 See L<perlipc/"UDP: Message Passing"> for examples.
 
 This call is actually implemented in terms of the L<recvfrom(2)> system call.
 See L<perlipc/"UDP: Message Passing"> for examples.
 

-Note the I<characters>: depending on the status of the socket, either
-(8-bit) bytes or characters are received.  By default all sockets
-operate on bytes, but for example if the socket has been changed using
-L<C<binmode>|/binmode FILEHANDLE, LAYER> to operate with the
-C<:encoding(UTF-8)> I/O layer (see the L<open> pragma), the I/O will
-operate on UTF8-encoded Unicode
-characters, not bytes.  Similarly for the C<:encoding> layer: in that
-case pretty much any characters can be read.
+Note that if the socket has been marked as C<:utf8>, C<recv> will
+throw an exception.  The C<:encoding(...)> layer implicitly introduces
+the C<:utf8> layer.  See L<C<binmode>|/binmode FILEHANDLE, LAYER>.

 
 =item redo LABEL
 X<redo>
 
 =item redo LABEL
 X<redo>


@@ -6280,9 +6326,10 @@ normally use this command:
         print;
     }
 
         print;
     }
 

-L<C<redo>|/redo LABEL> cannot be used to retry a block that returns a
-value such as C<eval {}>, C<sub {}>, or C<do {}>, and should not be used
-to exit a L<C<grep>|/grep BLOCK LIST> or L<C<map>|/map BLOCK LIST>
+L<C<redo>|/redo LABEL> cannot return a value from a block that typically
+returns a value, such as C<eval {}>, C<sub {}>, or C<do {}>. It will perform
+its flow control behavior, which precludes any return value. It should not be
+used to exit a L<C<grep>|/grep BLOCK LIST> or L<C<map>|/map BLOCK LIST>

 operation.
 
 Note that a block by itself is semantically identical to a loop
 operation.
 
 Note that a block by itself is semantically identical to a loop


@@ -6388,7 +6435,7 @@ compile time.
 
 Specifying VERSION as a numeric argument of the form 5.024001 should
 generally be avoided as older less readable syntax compared to
 
 Specifying VERSION as a numeric argument of the form 5.024001 should
 generally be avoided as older less readable syntax compared to

-v5.24.1. Before perl 5.8.0 released in 2002 the more verbose numeric
+v5.24.1. Before perl 5.8.0 (released in 2002), the more verbose numeric

 form was the only supported syntax, which is why you might see it in
 older code.
 
 form was the only supported syntax, which is why you might see it in
 older code.
 


@@ -6462,14 +6509,16 @@ statements.
 If EXPR is a bareword, L<C<require>|/require VERSION> assumes a F<.pm>
 extension and replaces C<::> with C</> in the filename for you,
 to make it easy to load standard modules.  This form of loading of
 If EXPR is a bareword, L<C<require>|/require VERSION> assumes a F<.pm>
 extension and replaces C<::> with C</> in the filename for you,
 to make it easy to load standard modules.  This form of loading of

-modules does not risk altering your namespace.
+modules does not risk altering your namespace, however it will autovivify
+the stash for the required module.

 
 In other words, if you try this:
 
         require Foo::Bar;     # a splendid bareword
 
 The require function will actually look for the F<Foo/Bar.pm> file in the
 
 In other words, if you try this:
 
         require Foo::Bar;     # a splendid bareword
 
 The require function will actually look for the F<Foo/Bar.pm> file in the

-directories specified in the L<C<@INC>|perlvar/@INC> array.
+directories specified in the L<C<@INC>|perlvar/@INC> array, and it will
+autovivify the C<Foo::Bar::> stash at compile time.

 
 But if you try this:
 
 
 But if you try this:
 


@@ -6484,12 +6533,20 @@ will complain about not finding F<Foo::Bar> there.  In this case you can do:
 
         eval "require $class";
 
 
         eval "require $class";
 

+or you could do
+
+        require "Foo/Bar.pm";
+
+Neither of these forms will autovivify any stashes at compile time and
+only have run time effects.
+

 Now that you understand how L<C<require>|/require VERSION> looks for
 files with a bareword argument, there is a little extra functionality
 going on behind the scenes.  Before L<C<require>|/require VERSION> looks
 for a F<.pm> extension, it will first look for a similar filename with a
 F<.pmc> extension.  If this file is found, it will be loaded in place of
 Now that you understand how L<C<require>|/require VERSION> looks for
 files with a bareword argument, there is a little extra functionality
 going on behind the scenes.  Before L<C<require>|/require VERSION> looks
 for a F<.pm> extension, it will first look for a similar filename with a
 F<.pmc> extension.  If this file is found, it will be loaded in place of

-any file ending in a F<.pm> extension.
+any file ending in a F<.pm> extension. This applies to both the explicit
+C<require "Foo/Bar.pm";> form and the C<require Foo::Bar;> form.

 
 You can also insert hooks into the import facility by putting Perl code
 directly into the L<C<@INC>|perlvar/@INC> array.  There are three forms
 
 You can also insert hooks into the import facility by putting Perl code
 directly into the L<C<@INC>|perlvar/@INC> array.  There are three forms


@@ -6595,7 +6652,8 @@ Generally used in a L<C<continue>|/continue BLOCK> block at the end of a
 loop to clear variables and reset C<m?pattern?> searches so that they
 work again.  The
 expression is interpreted as a list of single characters (hyphens
 loop to clear variables and reset C<m?pattern?> searches so that they
 work again.  The
 expression is interpreted as a list of single characters (hyphens

-allowed for ranges).  All variables and arrays beginning with one of
+allowed for ranges).  All variables (scalars, arrays, and hashes)
+in the current package beginning with one of

 those letters are reset to their pristine state.  If the expression is
 omitted, one-match searches (C<m?pattern?>) are reset to match again.
 Only resets variables or searches in the current package.  Always returns
 those letters are reset to their pristine state.  If the expression is
 omitted, one-match searches (C<m?pattern?>) are reset to match again.
 Only resets variables or searches in the current package.  Always returns


@@ -6608,6 +6666,7 @@ Only resets variables or searches in the current package.  Always returns
 Resetting C<"A-Z"> is not recommended because you'll wipe out your
 L<C<@ARGV>|perlvar/@ARGV> and L<C<@INC>|perlvar/@INC> arrays and your
 L<C<%ENV>|perlvar/%ENV> hash.
 Resetting C<"A-Z"> is not recommended because you'll wipe out your
 L<C<@ARGV>|perlvar/@ARGV> and L<C<@INC>|perlvar/@INC> arrays and your
 L<C<%ENV>|perlvar/%ENV> hash.

+

 Resets only package variables; lexical variables are unaffected, but
 they clean themselves up on scope exit anyway, so you'll probably want
 to use them instead.  See L<C<my>|/my VARLIST>.
 Resets only package variables; lexical variables are unaffected, but
 they clean themselves up on scope exit anyway, so you'll probably want
 to use them instead.  See L<C<my>|/my VARLIST>.


@@ -7024,14 +7083,9 @@ case it does a L<sendto(2)> syscall.  Returns the number of characters sent,
 or the undefined value on error.  The L<sendmsg(2)> syscall is currently
 unimplemented.  See L<perlipc/"UDP: Message Passing"> for examples.
 
 or the undefined value on error.  The L<sendmsg(2)> syscall is currently
 unimplemented.  See L<perlipc/"UDP: Message Passing"> for examples.
 

-Note the I<characters>: depending on the status of the socket, either
-(8-bit) bytes or characters are sent.  By default all sockets operate
-on bytes, but for example if the socket has been changed using
-L<C<binmode>|/binmode FILEHANDLE, LAYER> to operate with the
-C<:encoding(UTF-8)> I/O layer (see L<C<open>|/open FILEHANDLE,EXPR>, or
-the L<open> pragma), the I/O will operate on UTF-8
-encoded Unicode characters, not bytes.  Similarly for the C<:encoding>
-layer: in that case pretty much any characters can be sent.
+Note that if the socket has been marked as C<:utf8>, C<send> will
+throw an exception.  The C<:encoding(...)> layer implicitly introduces
+the C<:utf8> layer.  See L<C<binmode>|/binmode FILEHANDLE, LAYER>.

 
 =item setpgrp PID,PGRP
 X<setpgrp> X<group>
 
 =item setpgrp PID,PGRP
 X<setpgrp> X<group>


@@ -7483,7 +7537,7 @@ With proper care you may mix package and my (or state) C<$a> and/or C<$b>:
 
    # prints tinysmallnormalbighuge
 
 
    # prints tinysmallnormalbighuge
 

-C<$a> and C<$b> are implicitely local to the sort() execution and regain their
+C<$a> and C<$b> are implicitly local to the sort() execution and regain their

 former values upon completing the sort.
 
 Sort subroutines written using C<$a> and C<$b> are bound to their calling
 former values upon completing the sort.
 
 Sort subroutines written using C<$a> and C<$b> are bound to their calling


@@ -8662,12 +8716,10 @@ bytes before the result of the read is appended.
 There is no syseof() function, which is ok, since
 L<C<eof>|/eof FILEHANDLE> doesn't work well on device files (like ttys)
 anyway.  Use L<C<sysread>|/sysread FILEHANDLE,SCALAR,LENGTH,OFFSET> and
 There is no syseof() function, which is ok, since
 L<C<eof>|/eof FILEHANDLE> doesn't work well on device files (like ttys)
 anyway.  Use L<C<sysread>|/sysread FILEHANDLE,SCALAR,LENGTH,OFFSET> and

-check for a return value for 0 to decide whether you're done.
+check for a return value of 0 to decide whether you're done.

 
 

-Note that if the filehandle has been marked as C<:utf8>, Unicode
-characters are read instead of bytes (the LENGTH, OFFSET, and the
-return value of L<C<sysread>|/sysread FILEHANDLE,SCALAR,LENGTH,OFFSET>
-are in Unicode characters).  The C<:encoding(...)> layer implicitly
+Note that if the filehandle has been marked as C<:utf8>, C<sysread> will
+throw an exception.  The C<:encoding(...)> layer implicitly

 introduces the C<:utf8> layer.  See
 L<C<binmode>|/binmode FILEHANDLE, LAYER>,
 L<C<open>|/open FILEHANDLE,EXPR>, and the L<open> pragma.
 introduces the C<:utf8> layer.  See
 L<C<binmode>|/binmode FILEHANDLE, LAYER>,
 L<C<open>|/open FILEHANDLE,EXPR>, and the L<open> pragma.


@@ -8828,10 +8880,7 @@ string other than the beginning.  A negative OFFSET specifies writing
 that many characters counting backwards from the end of the string.
 If SCALAR is of length zero, you can only use an OFFSET of 0.
 
 that many characters counting backwards from the end of the string.
 If SCALAR is of length zero, you can only use an OFFSET of 0.
 

-B<WARNING>: If the filehandle is marked C<:utf8>, Unicode characters
-encoded in UTF-8 are written instead of bytes, and the LENGTH, OFFSET, and
-return value of L<C<syswrite>|/syswrite FILEHANDLE,SCALAR,LENGTH,OFFSET>
-are in (UTF8-encoded Unicode) characters.
+B<WARNING>: If the filehandle is marked C<:utf8>, C<syswrite> will raise an exception.

 The C<:encoding(...)> layer implicitly introduces the C<:utf8> layer.
 Alternately, if the handle is not marked with an encoding but you
 attempt to write characters with code points over 255, raises an exception.
 The C<:encoding(...)> layer implicitly introduces the C<:utf8> layer.
 Alternately, if the handle is not marked with an encoding but you
 attempt to write characters with code points over 255, raises an exception.


@@ -9342,7 +9391,7 @@ want a version of Perl older than the specified one.
 Specifying VERSION as a numeric argument of the form 5.024001 should
 generally be avoided as older less readable syntax compared to
 v5.24.1. Before perl 5.8.0 released in 2002 the more verbose numeric
 Specifying VERSION as a numeric argument of the form 5.024001 should
 generally be avoided as older less readable syntax compared to
 v5.24.1. Before perl 5.8.0 released in 2002 the more verbose numeric

-orm was the only supported syntax, which is why you might see it in
+form was the only supported syntax, which is why you might see it in

 
     use v5.24.1;    # compile time version check
     use 5.24.1;     # ditto
 
     use v5.24.1;    # compile time version check
     use 5.24.1;     # ditto


@@ -9545,9 +9594,12 @@ may behave differently to Perl's hashes with respect to changes in order on
 insertion and deletion of items.
 
 As a side effect, calling L<C<values>|/values HASH> resets the HASH or
 insertion and deletion of items.
 
 As a side effect, calling L<C<values>|/values HASH> resets the HASH or

-ARRAY's internal iterator, see L<C<each>|/each HASH>.  (In particular,
+ARRAY's internal iterator (see L<C<each>|/each HASH>) before yielding the
+values.  In particular,

 calling L<C<values>|/values HASH> in void context resets the iterator
 calling L<C<values>|/values HASH> in void context resets the iterator

-with no other overhead.  Apart from resetting the iterator,
+with no other overhead.
+
+Apart from resetting the iterator,

 C<values @array> in list context is the same as plain C<@array>.
 (We recommend that you use void context C<keys @array> for this, but
 reasoned that taking C<values @array> out would require more
 C<values @array> in list context is the same as plain C<@array>.
 (We recommend that you use void context C<keys @array> for this, but
 reasoned that taking C<values @array> out would require more