Some suggested minor tweaks... On Thu, Jun 26, 2003 at 12:00:05AM -0700, Jarkko Hietaniemi wrote: > > +=head2 Algorithmic Complexity Attacks on Hashes > + > +In Perls 5.8.0 and earlier it was easy to create degenerate hashes. > +Processing such hashes would consume large amounts of CPU time, > +causing a "Denial of Service" attack against Perl. Such hashes may be
s/causing/enabling/ > +Because of this feature the keys(), values(), and each() functions > +will return the hash elements in different order between different s/will/may/ > +runs of Perl even with the same data. One can still revert to the old > +predictable order by setting the environment variable PERL_HASH_SEED, s/predictable/repeatable/ > +see L<perlrun>. Another option is to add -DUSE_HASH_SEED_EXPLICIT to > +the compilation flags, in which case one has to explicitly set the > +PERL_HASH_SEED environment variable to enable the security feature, > +or -DNO_HASH_SEED to completely disable the feature. > + > +B<Perl does not guarantee any ordering of the hash keys>, and the s/does not guarantee/has never guaranteed/ > +ordering has already changed several times during the lifetime of > +Perl 5. Also, the ordering of hash keys already (in Perl 5.8.0 and > +earlier) depends on the insertion order. s/depends on/has always been, and continues to be, affected by/ > +Note that because of this randomisation for example the Data::Dumper > +results will be different between different runs of Perl since > +Data::Dumper by default dumps hashes "unordered". The use of the > +Data::Dumper C<Sortkeys> filter is recommended. s/filter/option/ ? Tim.
