4 ms·

OpenBSD decided to violate the standard and return non-deterministic results: http://man.openbsd.org/rand.3 http://man.openbsd.org/rand.3

windsurfer 9y ago
Doing the safer and slower thing seems better on the surface than just giving up and not compiling, and the article doesn't talk about this option. Could anyone chime in with some problems with OpenBSD's decision?
- avar 9y ago
  There's lots of uses for random but predictable numbers, e.g. adding random fuzz to a test suite run that you'd like to be able to repeat. A weak random number generator that usually powers rand() is also usually faster and takes less CPU to run. Both of these things were thought to be more important in more innocent times when C was standardized. OpenBSD's decision makes sense on balance, it gives some security to otherwise insecure programs by default, the trade-off is breaking programs written against the C standard which make assumptions about the documented rand() behavior.
  - problems 9y ago
    > There's lots of uses for random but predictable numbers, e.g. adding random fuzz to a test suite run that you'd like to be able to repeat. One thing to note though, different platforms don't necessarily implement the rand() function the same way, the standard does not define an algorithm for it, so unless you want your tests to run differently on every different C library it might not be the best idea to begin with.
    - int_19h 9y ago
      Running the test randomly is fine - indeed, desirable for fuzz tests (some eventual run might uncover a new issue). The requirement here is to have reproducibility - i.e. if the test fails, it should be able to log some kind of state, like a seed, that allows you to reproduce that same failure exactly. Obviously you'd need to also use the same environment, but that's usually not a problem.
- IcePic 9y ago
  For portable code you will not know if rand() will give you good or bad random though. A new name or no rand() at all would allow you to not get crap at least.

windsurfer 9y ago

Doing the safer and slower thing seems better on the surface than just giving up and not compiling, and the article doesn't talk about this option. Could anyone chime in with some problems with OpenBSD's decision?

avar 9y ago
There's lots of uses for random but predictable numbers, e.g. adding random fuzz to a test suite run that you'd like to be able to repeat. A weak random number generator that usually powers rand() is also usually faster and takes less CPU to run. Both of these things were thought to be more important in more innocent times when C was standardized. OpenBSD's decision makes sense on balance, it gives some security to otherwise insecure programs by default, the trade-off is breaking programs written against the C standard which make assumptions about the documented rand() behavior.
- problems 9y ago
  > There's lots of uses for random but predictable numbers, e.g. adding random fuzz to a test suite run that you'd like to be able to repeat. One thing to note though, different platforms don't necessarily implement the rand() function the same way, the standard does not define an algorithm for it, so unless you want your tests to run differently on every different C library it might not be the best idea to begin with.
  - int_19h 9y ago
    Running the test randomly is fine - indeed, desirable for fuzz tests (some eventual run might uncover a new issue). The requirement here is to have reproducibility - i.e. if the test fails, it should be able to log some kind of state, like a seed, that allows you to reproduce that same failure exactly. Obviously you'd need to also use the same environment, but that's usually not a problem.
IcePic 9y ago
For portable code you will not know if rand() will give you good or bad random though. A new name or no rand() at all would allow you to not get crap at least.