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

[Clinton Bunch <cdb_zsh@zentaur.org>]

I

On 11/22/2022 11:44 AM, Oliver Kiddle wrote:
> Firstly, thanks for your work on this Clinton and for being patient with us.
>
> Bart Schaefer wrote:
>> Actually this could be done with -ap for SRANDOM and -af for zrandom,
>> as well, but they're much simpler and the only reasonable quibble
>> might be with the name "zrandom".
> Bash appears to have an SRANDOM and if this is compatible with that then
> I'd see no issue with having that feature autoload the module.
>
> The builtin's option letter API looks good to me.

based on feedback, more and more I'm thinking the default action, 
instead of returning a hex-string of 8 bytes should return the 
equivalent of echo $SRANDOM. -c would always default to 1 even when 
using -r, and -i would be removed and become the default functionality 
as saving an array of decimal byte values could be achieved with -U 255 
and -c.


>
> If we're going to quibble about naming, many of our modules use 'z'
> prefixes on their builtins so I'd favour zrandom for the builtin too.
> The use of "get" and "set" in naming is often superfluous and "get"
> implies the fetching of something that already exists rather than
> of something that needs to be created.
I thought it would be confusing to have both named zrandom, but I'm not 
opposed to the idea.
> What issue do you see with "zrandom" on the math function? Most of the
> existing math functions correspond fairly closely to libc counterparts.
> Distinguishing it from those seems reasonable.
>
> The question of why $RANDOM isn't backed by some secure modern and fancy
> implementation seems to come up roughly yearly. It's not a feature I use
> especially often and I certainly don't care, either about stability or
> security, on the rare occasion I use *(oe:REPLY=\$RANDOM:) to shuffle
> a few mp3 files when playing them. Neither would I have any special
> attachment to the existing $RANDOM implementation if it was changed in a
> compatible way.
>
> Given that it can be autoloaded, could we move $RANDOM to the module
> too?

I suppose we could move RANDOM and use rand_r to try to keep the 
documented behavior, though currently the behavior is not consistent.

I tried changing the other places zsh uses rand to use rand_r and found 
that on at least EL8 the use of rand48 screwed up the sequence even when 
using rand_r for RANDOM.  I'm guessing glibc uses the same engine for 
rand_r and erand48 and doesn't reset the upper 16 bits when rand_r is 
called after erand48, but I haven't dug into the code.

I'd rather make RANDOM a 15-bit integer sampled from the same source as 
SRANDOM, but it would mean completely breaking an only partially broken 
documented behavior.

>
> Oliver
>