Vincent, Wolfgang, thank you for looking into this.

In the sample implementation, I chose to access /dev/random so that
the implementation won't depend on another SRFI providing
(cryptographically secure) random numbers. The device /dev/random
itself is not portable (not standardised by POSIX as far as I know);
only the Scheme code is portable. I selected /dev/random over
/dev/urandom because the device should block as long as it cannot
deliver a high-quality random number.

An implementation shipped with a Scheme system should almost never be
the sample implementation. There are a lot of use cases where symbols
have to be generated fast and in huge quantities, so doing a lot of
I/O would be out of the question (it could be mitigated somewhat by
increasing the buffer size of the port "rp" in the sample
implementation) but also any generation of random numbers. Thus,
high-quality implementations of this SRFI will only generate textual
names lazily on demand. I cannot do this in a portable sample
implementation but it could be demonstrated in an open-source
implementation like, say, Chibi.

I would be glad to link to a native implementation of this SRFI in the
implementation section!

Am Di., 28. Jan. 2025 um 02:33 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2025-01-27 17:27 -0800, Vincent Manis (he/him) wrote:
> > On 2025-01-27 16:57, Wolfgang Corcoran-Mathe wrote
> >
> > > I believe /dev/urandom should be used in the sample implementation,
> > > since reads from /dev/random may block.
> >
> > On modern kernels, /dev/random doesn't block after system
> > initialization, so behaves the same as /dev/random. That said, I
> > read somewhere that /dev/random will be going away eventually. So
> > let's use /dev/urandom.
>
> That's (post-2020?) Linux behavior. On other *nix systems /dev/random
> may indeed block after RNG init. (See https://man.netbsd.org/rnd.4,
> for example.)
>
> Either way, /dev/urandom seems like the right choice.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>