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 <[email protected]>: > > 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 <[email protected]>
