On Sun, Nov 02, 2003 at 12:20:11AM -0600, Andy Lester wrote:
> >>Anything that uses the C<each> operator is a prime candidate for
> >>bugginess. Please keep an eye out for them as you do your testing.
> >>Any function that contains C<each> oughta be heavily checked.
> >>
> >>Ditto anything that uses C<keys> or C<values> without a sort.
>
> Elaborating: Code that uses C<each>, C<keys> or C<values> may have
> worked in the past because the order of elements would be the same
> between runs. For instance, you have one hash, and then another hash
> with the same keys, and the code relies on those keys being in the same
> order between the hashes. This reliance might be explicit or
> accidental. Now, with 5.8.1 randomizing hashes, that code may break.
>
> Also, in .t files, it'd be a good thing to not rely on each/keys/values
> when determining the order of tests, because subsequent test runs might
> not be in the same order. For example:
>
> my %tests = ( test1 => 'foo', test2 => 'bar', etc.... );
>
> while ( my($key,$val) = each %tests ) {
> # do a test
> }
>
> The order in which these tests are done will be different between runs
> of the code...
A separate issue with C<each> is that code using it generally assumes
that the has itterator is at the start of the hash. If it's not
(because an C<each> loop somewhere terminated early, for example)
then some items of the hash will be skipped. A very hard to find bug.
Its cheap to reset an itterator, just do
keys %foo;
before the C<each> loop.
But rather than post emails with such guidelines, only for them to
be lost in the sands of time, wouldn't it be better to update the
web site?
Tim.
