Newsgroups: perl.perl5.porters
Path: csiph.com!weretis.net!feeder8.news.weretis.net!fu-berlin.de!bofh.it!nntp.perl.org
Xref: csiph.com perl.perl5.porters:99821
Mailing-List: contact perl5-porters-help@perl.org; run by ezmlm
Received-SPF: pass (dmarc-service-6ccc8c884f-h7wbd: domain of darrenduncan.net designates 67.223.102.125 as permitted sender) client-ip=67.223.102.125; envelope-from=darren@darrenduncan.net; helo=four.baremetal.com;
Message-ID: <2b77a5db-96c1-4f28-82e8-a19f86ffe41f@darrenduncan.net>
Date: Fri, 23 Jan 2026 19:30:39 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Should we upgrade to a new PRNG in core?
To: Perl5 Porters <perl5-porters@perl.org>
References: <e1f40576-0937-4dc3-908c-4c02e44e35a5@perturb.org>
Content-Language: en-CA
In-Reply-To: <e1f40576-0937-4dc3-908c-4c02e44e35a5@perturb.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Approved: news@nntp.perl.org
From: darren@darrenduncan.net (Darren Duncan)

Assuming that the reason to change the PRNG is better security or similar 
benefits, I feel that it would be good for Perl to have the most secure option 
by default so users who don't know better get the benefits. The main reason I 
would see to not make the change is if it would be a breaking change where it 
should not be breaking. -- Darren Duncan

On 2026-01-23 2:02 p.m., Scott Baker wrote:
> Esteemed p5p:
> 
> Almost two years ago I brought up <https://www.nntp.perl.org/group/ 
> perl.perl5.porters/2024/11/msg269037.html> upgrading *rand()* in core to use a 
> more modern PRNG. There was much lively discussion and many opinions were 
> shared. Ultimately it resulted in me writing Random::Simple <https:// 
> metacpan.org/pod/Random::Simple> as a drop in replacement to upgrade *rand()* 
> and *srand()*. At the time there were questions about whether we could or should 
> upgrade the PRNG. After much hacking and learning Perl core I have a working PR 
> <https://github.com/Perl/perl5/pull/24105> that proves it's actually pretty easy 
> to upgrade the PRNG. Whoever designed things back in the day made the PRNG 
> configurable in Configure, so really all it took was some new functions and to 
> point Configure at them instead of drand48(). This PR includes two PRNGs as 
> options to show how simple it is to switch between them using Configure.
> 
> This PR *is not merge ready* yet, it's more proof-of-concept that we *could 
> *upgrade the PRNG without any major breakage.
> 
> Ultimately the question becomes: Knowing the limitations of drand48() do we want 
> to upgrade the PRNG in core? Or is it "good enough" and users that want 
> something better are free to use CPAN.
> 
> 
>       Completed items
> 
>   * Modern PRNG implementation (PCG64)
>   * Detailed instructions for future devs on how to change/upgrade the PRNG
>   * Updated unit tests
>   * Verify |srand()| functionality works as expected
>   * Verify the new |rand()| outputs the full 53 bit state capable from a double
>     (drand48 could only do 48 bits)
>       o |./perl -I lib -E 'for (1..5) { printf("%064b\n", rand() * 2**64-1); }'|
> 
> 
>       TODO
> 
>   * |prng.h| does not seem to be rebuilt consistently after changes. Do I need
>     to add this new file to build system?
>   * Bikeshed on what the best PRNG is in 2026
>   * |make regen| puts the functions prototypes in a weird location "Used in
>     locale.c and perl.c"
>   * Add an option to get a random integer? |rand64()|?
> 
> 
>       Alternate options
> 
>   * We don't do anything. |rand()| is "good enough"
>   * Point users at CPAN. |Random::Simple| is a drop-in replacement for |rand()|
>     and |srand()| already
> 
> -- Scottchiefbaker
>