Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Perl 5.8.1 RC3 is Out

posted by hfb on 2003.07.31 3:32   Printer-friendly

jhi writes "The Release Candidate Three of Perl 5.8.1 (RC3) has been released.

Please test extensively, even if you had no problems with RC1 or RC2. In RC3 we turned on by default the new "hash randomisation" feature which means that the "order" of hash elements is now even more random. If an application mistakenly assumes a repeatable ordering of hash elements, you will find it out now.

See the perldelta for the news, or the dev.perl.org announcement. Go to the CPAN for the RC3 itself."

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If an application mistakenly assumes a repeatable ordering of hash elements, you will find it out now.

    This is going to expose a lot of latent bugs. Not perl bugs - bugs in people's perl code. IIRC it's already found 4 in the core (wake up - time to die) and now a happy customer [stason.org] reports that RC3 helped him find a hash bug [mpe.mpg.de]

    Soooo, I feel that the moral of this story is use RC3 to test your modules before your users get 5.8.1 and hence find (+fix) your bugs before your users are aware of them. It's much less embarassing this way.

    • Not perl bugs - bugs in people's perl code.

      Whenever I hear things like "the internal hash ordering has changed - so this should catch hash order dependency bugs" I am always really puzzled. I have always been told that hashes have no order as such, and I always either retrieve specific keys or use keys to retrieve all the keys. Am I missing the point? How have so many people managed to introduce bugs to their code in this way? I honestly am intrigued...

      • Sometimes the bugs are nastier. See for example the one that has been corrected by change #19964 (corresponding to this post [mpe.mpg.de]) : one of the elements of a hash has a specific property (and you don't have paid attention to it), you're selecting one of the elements of the hash at random, and you wonder why this begins to fail sometimes.
      • The point is that the internal hash order was constant at some time (or maybe people thought it was), so "reading off of the stack" gave you the same order every time - if you haven't changed the hash. Some people [perlmonks.org] count on this.

        "First of all, the hash is ALWAYS retrieved in a specific order, so we don't need to worry about that."

        One of the monks even notes the change to 5.8.1 later in the thread.

        I don't know why/how people do this, or how common it is. But if we assume that this hash-order mistake

        • In fact, as of 5.8.1, the hash keys are always returned in the same order, for one specific execution of your program : it changes only across executions. -- But you're right, nobody should count on this. This property is not guaranteed, it's only a side-effect of the current implementation.
  • It seems that the recently added support for cryptographically signed modules, by CPAN.pm using Module::Signature, is a bit too untested (too many assumptions about the environment). For 5.8.1 I will use a version of CPAN.pm that does not bother with Module::Signature. Yes, this is a setback for security. But the current implementation of PKI checking just doesn't cut it, especially for a maintenance release. Autrijus is working on better integration and testing, so hopefully in the future we will have both better Module::Signature and better CPAN.pm.