Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [PATCH] zsh/random module [UPDATED]

On 11/22/2022 7:23 PM, Matthew Martin wrote:

On Sun, Nov 20, 2022 at 08:57:25PM -0600, Clinton Bunch wrote:

On 11/20/2022 8:21 PM, Matthew Martin wrote:

If a uniform random function is desired in zsh, I think it should mirror
the interface of arc4random_uniform: just take an upper_bound and return
a value in the range [0, upper_bound).

The original implementation did exclude the upper bound, inadvertently, but
after discussion it seemed that was counter-intuitive and something easily
missed in a cursory glance at the documentation.  Adding a lower bound was
easy enough and saves extra shell code even if it's not likely to be used as
much.

arc4random_uniform excludes the upper bound so it is a direct
replacement for <random source> % <upper bound>. I think it would be
wise to follow an established API and avoid off by one errors when
refactoring existing code. Similarly it doesn't offer a lower bound
option since that's trivial to implement and difficult to get wrong.
Instead you get off-by-one errors in new code because people assume the specified limit is included unless they read the documentation closely. 


yes, much of getrandom *could* be implemented in shell code, much less
efficiently.  For example my precmd could save the math eval by specifying
getrandom -L 1 -U 7.

Once you've written the code to access the kernel random source, it seems to
make sense to me to make its output as flexible as possible.  I don't get
the concern about backwards compatibility in implementing a new builtin
unless you know of an external command called getrandom that is in common
use, and that's easily fixed by changing it to zgetrandom.

I disagree on making the output as flexible as possible because there
are already features in zsh to get those formats and the API would need
to be maintained into future releases even if seldom used. I think it
would be wise to start with the minimum interface necessary and then
build off it as uses arise.

Interfacing with libc and the kernel to get random numbers is something
that can only be done in C and SRANDOM builds off an existing API, so
I have no opposition to it. I can accept that uniformly distributed
random integers is a useful and non-trivial task, so probably should be
included, but would prefer an existing and proven API like
arc4random_uniform.

I have a patch based off yours that implements just SRANDOM and
a mathfunc for arc4random_uniform, but haven't yet had time to test it
on multipl platforms.
Even if we go this way,  I don't think the function should be called arc4random_uniform.  It only implements the arc4random algorithm on *BSD. 

With just SRANDOM and arc4random_uniform the features of getrandom can
be implemented in a script. I've taken a quick shot at a proof of
concept below.



[snip shell code example]
That's a lot of zsh code, most of which would be difficult for a non-zsh expert to write.  So it would need to be provided as a function and then you're left with the same support problem, but a slower implementation that keeps converting strings to numbers and back again.
getrandom doesn't need advanced zsh programming knowledge to use.  The -U and -L make it easy for a relative novice. arc4random_uniform is a programmer's interface, not a user's interface.
You also ignored the zrandom function which is definitely non-trivial to implement in the shell.  It's not even trivial to implement in C.
Messages sorted by: Reverse Date, Date, Thread, Author