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.
I thought it would be confusing to have both named zrandom, but I'm not opposed to the idea.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.
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