From: Ronald J. Kimball <rjk@linguist.dartmouth.edu>
Date: Wed, 2 Jul 2003 11:43:05 +0000 (-0400)
Subject: Re: maint @ 19923
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=d6df3700e9fd7f8b471288012f05c37f69c233f6;p=p5sagit%2Fp5-mst-13.2.git

Re: maint @ 19923
Message-ID: <20030702154304.GD206089@linguist.thayer.dartmouth.edu>

p4raw-id: //depot/perl@19933
---

diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 539d43c..41c44b0 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1271,8 +1271,7 @@ order is subject to change in future versions of perl, but it is
 guaranteed to be in the same order as either the C<keys> or C<values>
 function would produce on the same (unmodified) hash.  Since Perl
 5.8.1 the ordering is different even between different runs of Perl
-because of security reasons (see L<perlsec/"Algorithmic Complexity
-Attacks">)
+for security reasons (see L<perlsec/"Algorithmic Complexity Attacks">).
 
 When the hash is entirely read, a null array is returned in list context
 (which when assigned produces a false (C<0>) value), and C<undef> in
@@ -2320,10 +2319,10 @@ Returns a list consisting of all the keys of the named hash.
 The keys are returned in an apparently random order.  The actual
 random order is subject to change in future versions of perl, but it
 is guaranteed to be the same order as either the C<values> or C<each>
-function produces (given that the hash has not been modified).
-Since Perl 5.8.1 the ordering is different even between different
-runs of Perl because of security reasons (see L<perlsec/"Algorithmic
-Complexity Attacks">)
+function produces (given that the hash has not been modified).  Since
+Perl 5.8.1 the ordering is different even between different runs of
+Perl for security reasons (see L<perlsec/"Algorithmic Complexity
+Attacks">).
 
 As a side effect, calling keys() resets the HASH's internal iterator,
 see L</each>.
@@ -6222,8 +6221,7 @@ random order is subject to change in future versions of perl, but it
 is guaranteed to be the same order as either the C<keys> or C<each>
 function would produce on the same (unmodified) hash.  Since Perl
 5.8.1 the ordering is different even between different runs of Perl
-because of security reasons (see L<perlsec/"Algorithmic Complexity
-Attacks">)
+for security reasons (see L<perlsec/"Algorithmic Complexity Attacks">).
 
 As a side effect, calling values() resets the HASH's internal iterator,
 see L</each>.