Replace /dev/random with /dev/urandom throughout LALSuite
Description
LALSuite programs often need to get some random data to seed a pseudo-random number generator. This is commonly achieved by reading random data from either the /dev/urandom
or /dev/random
device files.
The problem with using the latter, /dev/random
, is that it can easily block after reading a small amount of data. For example, on my laptop, after reading a few 4-byte integers worth of data, /dev/random
can then block for ~10 seconds on subsequent reads. This can be a significant cost when calling the same code multiple times, e.g. for test suites which need to run in a short amount of time. It can also be difficult to debug, since it only appears when running the same code many times in quick succession.
The difference between /dev/random
and /dev/urandom
is described in man 4 random
:
The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.
and
The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time
I don't think any application in LALSuite needs the level of randomness returned by /dev/random
, particularly since it's only ever used as a seed for a pseudo-random number generator. In any case /dev/urandom
is already more commonly used:
$ git grep '"/dev/random"' | wc -l
6
$ git grep '"/dev/urandom"' | wc -l
21
This MR replaces /dev/random
with /dev/urandom
everywhere in LALSuite. Where that replacement has been made, I've added a comment (copied from lalpulsar/lib/GeneratePulsarSignal.c
) to explain why /dev/urandom
is used instead of /dev/random
.
API Changes and Justification
Backwards Compatible Changes
-
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions -
This change adds new classes/functions/structs/types to a public C header file or Python module
Backwards Incompatible Changes
-
This change modifies an existing class/function/struct/type definition in a public C header file or Python module -
This change removes an existing class/function/struct/type from a public C header file or Python module
Review Status
N/A