Hi Christian, On 12/27/22 14:07, Cristian Rodríguez wrote:
On Mon, Dec 26, 2022 at 7:29 PM Alejandro Colomar via Libc-alpha <libc-alpha@xxxxxxxxxxxxxx> wrote:Hi Jonny,l it several times per second, you'llfind that it only changes the seed every second. There are better ways to produce a good seed. However, I prefer suggesting arc4random() rather than workarounding rand(3) to get good results. Florian, did you already merge arc4random() to glibc?arc4random is already on libc.. now to make it a replacement for everything random one has to hope for https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/log/?h=vdso to be merged into the mainline kernel. That will make it as fast as possible and really,really cheap to call.
Great! When that is merged, please ping me.If someone wants to contribute a manual page for the arc4random family of functions, please speak; otherwise I can start writing something.
Now it is just a wrapper that calls getrandom syscall. WRT the rand() example suggestion..it is bad.. The only addition I will make to this man page is strongly discouraging its use. Suggesting to use ar4random if available or one of https://prng.di.unimi.it/ PRNG if not for crypto.
The only problem with arc4random() is the lack of repeatability. When testing a program with random data, you'll need repeatable results. For that, rand(3) Just Works. When you want unpredictable results, you just seed it with some really random value, and you're fine. You need to be careful to not introduce bias, but there's nothing better in libc. It would be nice if libc provided a rand_uniform(3) variant of rand(3), BTW.
So, rand(3) is not to be deprecated, although it must be used with care. I would recommend the following, per Jonny's report:
if (repeatable)
srand(seed)
else
srand(arc4random());
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
