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

[Clinton Bunch <cdb_zsh@zentaur.org>]

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.