Bart Lateur:
> >If there are no objections, I will freeze this in twenty-four hours.
>
> Oh, I have a small one: I feel that this pseudo-random salt should NOT
> affect the standard random generator. I'll clarify: by default, if you
> feed the pseudo-random generator with a certain number, you'll get the
> same sequence of output numbers, every single time. There are
> applications for this. I think that any call to crypt() should NEVER
> change this sequence of numbers, in particular, it should not skip a
> number every time crypt() is called with one parameter.
>
> Therefore, crypt() should have it's own pseudo-random generator. A
> simple task, really: same code, but a different seed variable.
I had considered this for the original RFC, but I decided against it.
To implement it, Perl would have to have its own built-in random
number generator, because there is no way to save and restore the old
state of rand() (for example). It would substantially complicate the
code.
And the problem you describe is not really a problem. There has never
been any guarantee that a program would produce the same sequence of
random numbers after a change to the Perl binary. More recent
versions of Perl use random() or drand48() if they are available,
instead of rand(). A program run under an old version of Perl and
then a newer version that used random() instead of rand() would
generate a different sequence of random numbers depending on which
version of Perl was running it, even if the seed was the same. This
has never been an issue in the past, so I did not consider it
important.
I will add a note aboput this to the RFC. If there are no other
comments, I will freeze it in 24 hours.
