Re: [PATCH] zsh/random module

[Clinton Bunch <cdb_zsh@xxxxxxxxxxx>]

On 11/4/2022 2:27 AM, dana wrote:
> On Fri 4 Nov 2022, at 01:22, Clinton Bunch wrote:
> > Then why would you use the builtin in preference to the parameter SRANDOM?
> I guess the main reason would be for the bounds functionality
I suppose that's true.  It may be worth looking at making the default 1 
except in raw and hex-string mode, though that would be harder to 
explain in the documentation, I think.
> On Fri 4 Nov 2022, at 01:22, Clinton Bunch wrote:
> > Copied that pattern straight out of Src/Modules/datetime.c
> TIL. I also lied about sysread, it does the same. print/printf, zparseopts,
> and zstyle don't. Can't think of anything else off the top of my head rn
>
> On Fri 4 Nov 2022, at 01:22, Clinton Bunch wrote:
> > Trying to think how to design tests when the output is different every
> > time by design.
> If nothing else it could just make sure it's in the expected format
>
> On Fri 4 Nov 2022, at 01:22, Clinton Bunch wrote:
> > And I can't think what a completion function would
> > complete.  It's not like it's using long options or enumerated arguments.
> Most of zsh's built-ins have no long options but they still have completion
> functions. Some people use completion as a substitute for the documentation.
> Attached _getrandom for your consideration (assumes no further changes, tested
> very minimally)
>
> btw, in writing that function i realised a few things:
>
> * In the documentation, i think the default upper bound should be 4294967295
>    rather than 4294967296
Wanted to put UINT32_MAX, but didn't think Yodl would translate that :)
> * Why is the maximum length 64? Also, should that value be documented?
The getrandom() function itself is only guaranteed to return 256 bytes. 
64 32-bit integers.  And it should definitely be documented, I thought I 
had.
> * If you put -i after -L/-U it overrides their effect. Maybe the
>    `if (integer_out)` in the code should be an `else if` instead?
That definitely isn't intended behavior.  Specifying both is redundant, 
but bounds should definitely take precedence.
> * It appears that -L is inclusive but -U is exclusive. e.g. if you do
>    `getrandom -l1 -L2 -U3` it will only ever return 2. I assume that's not
>    intentional?
When (after I posted, of course), I realized that the algorithm I used 
from arc4random_uniform would never return the upper bound, I began to 
debate whether to try to make it inclusive, handling the pathological 
cases, or documenting it.
> On Fri 4 Nov 2022, at 01:22, Clinton Bunch wrote:
> > It still seems weird that the dev guide specifies mixing the two.
> I agree
>
> dana
>
>
> diff --git a/Completion/Zsh/Command/_getrandom b/Completion/Zsh/Command/_getrandom
> new file mode 100644
> index 000000000..3513e10b7
> --- /dev/null
> +++ b/Completion/Zsh/Command/_getrandom
> @@ -0,0 +1,12 @@
> +#compdef getrandom
> +
> +local min=0 max=$(( 2 ** 32 - 1 ))
> +
> +_arguments -s -S : \
> +  '(-r -s)-a+[assign result to specified array parameter]:array parameter:_parameters -g "*array*~*readonly*"' \
> +  '(-a)-s+[assign result to specified scalar parameter]:scalar parameter:_parameters -g "*(integer|scalar)*~*readonly*"' \
> +  '(-r)-i[produce random data as 32-bit unsigned integers]' \
> +  '-l+[specify length of data]: :_numbers -d8 -l1 -m64 -u "bytes or integer elements" "data length"' \
> +  '(-i -L -U)-r[produce random data as raw bytes]' \
> +  '(-r)-L+[specify integer lower bound (implies -i)]: :_numbers -d$min -l$min -m$max "integer lower bound"' \
> +  '(-r)-U+[specify integer upper bound (implies -i)]: :_numbers -d$max -l$min -m$max "integer upper bound"'