Fixes initialization of ISAAC PRNG without explicit seed

[konovod]

#4789 introduced a problem - there is no spec ensuring that PRNG can be actually created without seed. So "seeding" it added for ISAAC was a piece of code that don't even compiles.

This PR fixes it and adds spec that ensures that initialization at least compiles. I don't know what else can be checked in spec (i think we can compare that next_u of two created instances aren't equal, but this means that there will be 1/2^32 chance that they will match and spec fails).

[RX14]

Would unsafe_as(StaticArray(UInt8, 32)).to_slice work?

[konovod]

Yeah, this way it looks cleaner 😄 . Is StaticArray(UInt8, sizeof(Seeds)) ok?

[RX14]

If it complies it's great.

[RX14]

If it complies it's great.

[RX14]

Please extract result.unsafe_as(StaticArray(UInt8, sizeof(Seeds))).to_slice to a result_slice variable. The line's getting quite messy.

[konovod]

Done.

[ysbaddaden]

Why requiring SecureRandom when Crystal::Random::System can be used directly in stdlib?

[konovod]

I don't understand what is the difference (I thought that SecureRandom was renamed to Random::System but then discovered that it's still here).
SecureRandom is a safe random source, while Crystal::Random::System is it's platform independent implementation?

[luislavena]

I don't understand what is the difference (I thought that SecureRandom was renamed to Random::System but then discovered that it's still here).

That definitely is worth a blogpost or similar that describes what the stdlib should look like moving forward. /cc @mverzilli @matiasgarciaisaia @bcardiff

[luislavena]

@konovod a bit more of background (until someone can produce a condensed and concise response here):

• [RFC] per-platform low-level abstractions #4406
• Crystal::System::Random namespace #4450

Cheers

[konovod]

@luislavena i think i already read them (maybe not thoroughly). But when reading i thought that it was replacing secure_random and i was confused to see it's still here (and just calls Crystal::Random::System). What to use in any particular case - Crystal::Random::System.random_bytes or SecureRandom.random_bytes?

So, if I understand correctly, the difference is that SecureRandom is an interface exposed to end users, while Crystal::Random::System is a low-level and internal part of stdlib, so former should be used in external shards, while latter should be used inside stdlib?

I've updated PR.

[RX14]

This weird phobia against including SecureRandom in the prelude is just crazy.

The system random situation in crystal is also just crazy. There should be one class in crystal which uses Crystal::System::Random: Random::System. And it should provide a random_bytes method.

And you know how I feel about SecureRandom, it should be unified with Random.

All the current mess just serves to confuse people, as this thread continues to prove.

[luislavena]

All the current mess just serves to confuse people, as this thread continues to prove.

I have no personal position on that, so I will suggest a RFC for that be reviewed by core and other contributors.

Please do, so the RFC can be used as guidance and modifications be introduced to simply current approach.

[mverzilli]

Thank you @konovod! I was about to say you're steadily becoming "Crystal's Random Guy" but realized it didn't sound so positive :P.