On Thu, 21 Sep 2000, Mark-Jason Dominus wrote:
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.
random numbers after a change to the Perl binary. More
On Thu, 21 Sep 2000 15:37:36 -0400 (EDT), Andy Dougherty wrote:
Still, even for me, I have never encountered a case where I wanted to
maintain the same rand() sequence and also use a one-arg crypt().
I will add a note aboput this to the RFC. If there are no other
comments, I will freeze it
"BL" == Bart Lateur [EMAIL PROTECTED] writes:
BL Therefore, crypt() should have it's own pseudo-random generator. A
BL simple task, really: same code, but a different seed variable.
Should rand be extended to be able to support multiple random number
generators?
=item srand EXPR, RANDGEN_REF
On 16 Sep 2000 22:40:24 -0400, Chaim Frenkel wrote:
BL Therefore, crypt() should have it's own pseudo-random generator. A
BL simple task, really: same code, but a different seed variable.
Should rand be extended to be able to support multiple random number
generators?
Not just srand().
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus [EMAIL PROTECTED]
Date: 11 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 2
Status: Developing
If there are no objections, I will freeze this in
On Thu, 14 Sep 2000 11:58:46 -0400, Mark-Jason Dominus wrote:
If there are no objections, I will freeze this in twenty-four hours.
Oh, I have a small one: I feel that this speudo-random salt should NOT
affect the standard random generator. I'll clarify: by default, if you
feed the pseudo-random
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus [EMAIL PROTECTED]
Date: 11 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 2
Status:
