2 ms·

random(3) is clearly bad; but contrast this proposal with the simplicity (and security) of OpenBSD's arc4random(), arc4random_uniform(), arc4random_buf().

cbsmith 11y ago
arc4random_uniform() is the only one that really addresses the matters in this proposal, and arc4random_uniform() can't handle values larger than 2^32-1 (and, in fact, thanks to the wonders of overflow, might do some unfortunate things in a variety of cases), and won't produce values greater than 2^32-2. So yeah, not exactly addressing the matter. Of course, that whole arc4* library doesn't have the same challenges as a language standard, which is where a lot of the challenge here comes from.
- JoachimSchipper 11y ago
  You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick(). (I don't write code where e.g. std::poisson_distribution would be useful, so I don't feel I have the background to have an opinion on that part of the proposal.) Overflow is something that the programmer always has to keep in mind, unfortunately.
  - cbsmith 11y ago
    Generics and boxed types make overflow a non-concern. The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.
    - JoachimSchipper 11y ago
      FWIW: generics and boxed types allow you to write code without overflow, but there's plenty of real-world C++ that's full of overflows. Good C uses a small number of types and also avoids overflow... Although we have different concerns, it's clear that a lot of thought has been put into the proposal, and it seems to achieve its/your goals pretty well. Don't let my concerns put you off.

cbsmith 11y ago

arc4random_uniform() is the only one that really addresses the matters in this proposal, and arc4random_uniform() can't handle values larger than 2^32-1 (and, in fact, thanks to the wonders of overflow, might do some unfortunate things in a variety of cases), and won't produce values greater than 2^32-2. So yeah, not exactly addressing the matter. Of course, that whole arc4* library doesn't have the same challenges as a language standard, which is where a lot of the challenge here comes from.

JoachimSchipper 11y ago
You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick(). (I don't write code where e.g. std::poisson_distribution would be useful, so I don't feel I have the background to have an opinion on that part of the proposal.) Overflow is something that the programmer always has to keep in mind, unfortunately.
- cbsmith 11y ago
  Generics and boxed types make overflow a non-concern. The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.
  - JoachimSchipper 11y ago
    FWIW: generics and boxed types allow you to write code without overflow, but there's plenty of real-world C++ that's full of overflows. Good C uses a small number of types and also avoids overflow... Although we have different concerns, it's clear that a lot of thought has been put into the proposal, and it seems to achieve its/your goals pretty well. Don't let my concerns put you off.