3 ms·

Sigh... Too often that criticism is leveled at C++ without an understanding of the terrain. I don't think C developers should be sitting on a high horse on thi

by cbsmith 11y ago

Sigh... Too often that criticism is leveled at C++ without an understanding of the terrain. I don't think C developers should be sitting on a high horse on this one. C represents a pretty good example of the problem. Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution, so any correct program completely bypasses that infrastructure and/or has a ton of additional code/complexity layered on top of it. That open source basically festered until the C++11 <random> proposal was accepted. The chief proponents of that proposal were, of course, those with the most sophisticated needs & understanding for random functions, and the proposal reflects that. So, the problems with that proposal are arguably a consequence of the flaws in the original C standard. What remains to be done is to harmonize that proposal with something that makes sense to less sophisticated users, who nonetheless have reached the point where their appreciate the problems with C's random functions.

cperciva 11y ago
Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution Right, and that function is a mistake in the C standard. It should have been omitted entirely.
- cbsmith 11y ago
  That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.
  - cperciva 11y ago
    You misunderstand me. I think random(3) should have been omitted from the C standard.
    - pcwalton 11y ago
      What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. See, for example, crypto before NaCl came around. (NB: I'm not defending either this C++ standard or random(3).)
      - cperciva 11y ago
        What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3). Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.
      - marssaxman 11y ago
        I thought NaCl was something related to browser plugins. What is the connection with crypto?
        ori_b 11y ago
        Name collisions: http://nacl.cr.yp.to/ http://nacl.cr.yp.to/ Although, I've never actually seen it used in the wild.
        cpach 11y ago
        Threema use it. (I don’t know if they use it in a sane way though.)
cbsmith 11y ago
> That open source Man, autocorrect killed me there. That should be "That open sore".
JoachimSchipper 11y ago
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.

by cbsmith 11y ago

cperciva 11y ago

Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution Right, and that function is a mistake in the C standard. It should have been omitted entirely.

cbsmith 11y ago
That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.
- cperciva 11y ago
  You misunderstand me. I think random(3) should have been omitted from the C standard.
  - pcwalton 11y ago
    What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. See, for example, crypto before NaCl came around. (NB: I'm not defending either this C++ standard or random(3).)
    - cperciva 11y ago
      What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3). Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.
    - marssaxman 11y ago
      I thought NaCl was something related to browser plugins. What is the connection with crypto?
      - ori_b 11y ago
        Name collisions: http://nacl.cr.yp.to/ http://nacl.cr.yp.to/ Although, I've never actually seen it used in the wild.
        cpach 11y ago
        Threema use it. (I don’t know if they use it in a sane way though.)

cbsmith 11y ago

> That open source Man, autocorrect killed me there. That should be "That open sore".

JoachimSchipper 11y ago

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.