3 ms·

I'm not sure whether it makes sense for C++ to be deprecating common C standard library functions, before they've been deprecated and replaced in C. `rand(3)` i

I'm not sure whether it makes sense for C++ to be deprecating common C standard library functions, before they've been deprecated and replaced in C. `rand(3)` is certainly very outdated and poorly-specified, but not inherently buggy regardless of usage scenario like `gets(3)` or C++ `std::auto_ptr`. And anyone using `rand(3)` for cryptographic purposes is much too far gone to be helped.

saurik 9y ago
I see no reason not to deprecate things... removing them is another matter entirely.
- deleted 9y ago
  [deleted]
kazinator 9y ago
It doesn't make sense at all. std::<c-lib-function> is supposed to just be a way of accessing the C library from C++. C++ shouldn't even be specifying it; just citing it as a normative reference. (That said, C++ does a few things with some of the functions, like useful polymorphism on char versus unsigned char in some of the string ones and such.)
tonmoy 9y ago
Someone converted our codebase into a multi threaded version, didn't realize that rand() is not thread safe as multiple threads were generating same random number from time to time. PS: that someone was me
- slavik81 9y ago
  It's an easy mistake to make. rand() is built around hidden, global mutable state. It's fundamentally a bad design, and it's the same reason I dislike the std::randint proposal.
  - xyz6633 9y ago
    std::randint is supposed to use thread-local storage for its state. At least according to cppreference: http://en.cppreference.com/w/cpp/experimental/randint http://en.cppreference.com/w/cpp/experimental/randint
    - slavik81 9y ago
      It's not the thread-safety itself that's the issue. The thing is that when you can see the state, it's obvious what can influence what. When you hide the state, there's more documentation to read and interactions are less obvious. "Show me your tables..."
GuB-42 9y ago
Some rand() implementation are really really bad for pretty much anything. Obviously, it is not cryptographically secure but these RNGs are a class of their own and are typically much slower than needed for other applications. The problem with rand() is that it may be unseeded (same result each time you run the program), have a very short period, very short range, and fail even basic randomness tests. Fill an image with rand() results and it may not look random at all. It may not be good enough for monte-carlo simulations, fuzz testing, probabilistic algorithms and structures, etc... Some rand() implementations are too poor even for casual games. A good example of a terrible RNG causing trouble is in the Monster Hunter 3 Ultimate game. There are some randomly generated items in it that cannot be accessed because of the RNG. Players call it "charm tables" but it is just a result of a really poor RNG.
unscaled 9y ago
The point that rand() detractors are trying to make, is that rand() is also bad for non-cryptographic purposes as well. Its badness vary with the implementation, but with the implicit seeding, thread-safety issues and bad distribution on many implementations it should be generally avoided for all usage scenarios that want random numbers. If you don't really want random numbers, but just "some numbers, I don't care if they're random or not", rand() is fine, but using "int myNumber = 42" is faster and safer.

saurik 9y ago

I see no reason not to deprecate things... removing them is another matter entirely.

deleted 9y ago
[deleted]

kazinator 9y ago

It doesn't make sense at all. std::<c-lib-function> is supposed to just be a way of accessing the C library from C++. C++ shouldn't even be specifying it; just citing it as a normative reference. (That said, C++ does a few things with some of the functions, like useful polymorphism on char versus unsigned char in some of the string ones and such.)

tonmoy 9y ago

Someone converted our codebase into a multi threaded version, didn't realize that rand() is not thread safe as multiple threads were generating same random number from time to time. PS: that someone was me

slavik81 9y ago
It's an easy mistake to make. rand() is built around hidden, global mutable state. It's fundamentally a bad design, and it's the same reason I dislike the std::randint proposal.
- xyz6633 9y ago
  std::randint is supposed to use thread-local storage for its state. At least according to cppreference: http://en.cppreference.com/w/cpp/experimental/randint http://en.cppreference.com/w/cpp/experimental/randint
  - slavik81 9y ago
    It's not the thread-safety itself that's the issue. The thing is that when you can see the state, it's obvious what can influence what. When you hide the state, there's more documentation to read and interactions are less obvious. "Show me your tables..."

GuB-42 9y ago

Some rand() implementation are really really bad for pretty much anything. Obviously, it is not cryptographically secure but these RNGs are a class of their own and are typically much slower than needed for other applications. The problem with rand() is that it may be unseeded (same result each time you run the program), have a very short period, very short range, and fail even basic randomness tests. Fill an image with rand() results and it may not look random at all. It may not be good enough for monte-carlo simulations, fuzz testing, probabilistic algorithms and structures, etc... Some rand() implementations are too poor even for casual games. A good example of a terrible RNG causing trouble is in the Monster Hunter 3 Ultimate game. There are some randomly generated items in it that cannot be accessed because of the RNG. Players call it "charm tables" but it is just a result of a really poor RNG.

unscaled 9y ago

The point that rand() detractors are trying to make, is that rand() is also bad for non-cryptographic purposes as well. Its badness vary with the implementation, but with the implicit seeding, thread-safety issues and bad distribution on many implementations it should be generally avoided for all usage scenarios that want random numbers. If you don't really want random numbers, but just "some numbers, I don't care if they're random or not", rand() is fine, but using "int myNumber = 42" is faster and safer.