From: Jim Cromie <jcromie@cpan.org>
Date: Wed, 2 Jul 2003 05:35:06 +0000 (-0600)
Subject: Re: maint @ 19923
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=d1936a9ec2c90a9e6d37362d24d7c9263cd1f0bf;p=p5sagit%2Fp5-mst-13.2.git

Re: maint @ 19923
Message-ID: <3F02C36A.9030704@divsol.com>

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

diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 1000fc9..539d43c 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1272,7 +1272,7 @@ 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".)
+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
@@ -2323,7 +2323,7 @@ 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".)
+Complexity Attacks">)
 
 As a side effect, calling keys() resets the HASH's internal iterator,
 see L</each>.
@@ -6223,7 +6223,7 @@ 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".)
+Attacks">)
 
 As a side effect, calling values() resets the HASH's internal iterator,
 see L</each>.