Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The bell has tolled for rand()

cpp.indi.frih.net

Post reply on HN
Print view View original

11–20 of 44 posts

Re: The bell has tolled for rand()

#11

Post by leni536 »

Why is a specific random generator should be in the standard at all? Random generators are quite a dangerous area.

Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure?

It could become obsolete in less time than expected. It's mostly true for CSPRNGs. Maybe that's why they are considering Mersenne Twister which is "good enough" for many use cases but not meant to be cryptographically secure. Sure, I'm using it right now for physics simulation and it's certainly good enough for that and it's hard to imagine a case where a 623-dimansionally equidistributed PRNG could fail. But it most certainly can if it can't be used for cryptography. It is much better than rand() though and one could argue that it will be good enough 99% of the time. The problem that you can't replace it if it ever becomes obsolete since some software depends on the predictability and still random like features of PRNGs (like game map generators, digital art, etc...).

I think the one boost library they should standardize is boost's random device. PRNGs could become obsolete but "truly random" will always mean the same. However it's not trivial that one has access to a truly random source and in that case it should fall back to fail. At least it could kill the practice of seeding with time.

Re: The bell has tolled for rand()

#12

Post by StephanTLavavej »

leni536 wrote: post #11

Why is a specific random generator should be in the standard at all? Random generators are quite a dangerous area. Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure? It could become obsolete in less time than expected. It's mostly true for CSPRNGs. Maybe that's why they are considering Mersenne Twister which is "good enough" for many use cases but not meant…

std::random_device is part of C++11, and VC's implementation guarantees that it's crypto-secure.

Re: The bell has tolled for rand()

#13

Post by justincormack »

lloeki wrote: post #9
DonHopkins wrote: post #5

"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…

If I were to use C, what should I be using instead of rand(3)? A cursory look at rand(3) SEE ALSO hints at candidates but random(3) seems to hardly fare better†, arc4random(3) isn't available on glibc. † A few notes about rand as the parent suggests, but nothing regarding mod bias, srandom initial state, or threads: > It returns successive pseudo-random numbers in the range from 0 to (2 31)-1. The period of this rand…

arc4random (under a different name as the name is misleading) will be standardised, and Linux now has a random() syscall that is a necessary building block, so it doesnt fail.

In the meantime, use arc4random on openbsd and netbsd 7 and read from /dev/urandom on all other platforms (FreeBSD is in process of fixing arc4random, currently still uses rc4 and may have problems with state being same in multiple threads; I guess OSX is the same version).

Android does have arc4random, although it can fall back to weaker random sources if it does not manage to open /dev/urandom https://code.google.com/p/android-source-browsing/source/bro...

Re: The bell has tolled for rand()

#14

Post by tedunangst »

lloeki wrote: post #9
DonHopkins wrote: post #5

"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…

If I were to use C, what should I be using instead of rand(3)? A cursory look at rand(3) SEE ALSO hints at candidates but random(3) seems to hardly fare better†, arc4random(3) isn't available on glibc. † A few notes about rand as the parent suggests, but nothing regarding mod bias, srandom initial state, or threads: > It returns successive pseudo-random numbers in the range from 0 to (2 31)-1. The period of this rand…

There are several paths to getting arc4random or something like it.

You can just use it and optionally tell people to link with e.g. libcrypto from libressl.

You can include the portable code yourself, though that's yucky. Aging software that includes never updated very early versions of arc4random is actually kind of a problem because that code still gets used when better versions are available.

You can link with https://github.com/nmathewson/libottery-lite which is approximately arc4random with a different name.

Some combination of the above.

For example, sqlite3 includes an arc4random workalike (rc4 rng), but doesn't discard the early stream (critical because it leaks the key) nor include any degree of fork safety. Nor does it check if the host provides a better version. sqlite3 shipped with OpenBSD is patched to use libc arc4random instead, but building from source means you're back to square one. Not a big deal in the case of sqlite3, but try not to build something that doesn't improve as the world around it improves.

Re: The bell has tolled for rand()

#15

Post by fafner »

jlebar wrote: post #2

Not to focus on a question unrelated to this blog post's point, but * "auto main() -> int" could be just "int main()". * "auto v = vector (20);" could be just "vector v(20)". * "auto print_value = [](auto&& v)" could be (I'd argue should be) "auto print_value = [](const auto& v)". "auto" is useful, "auto" is great. But "auto" is not an end in and of itself. (Bring on the C++(11) haters, blah blah.)

1. The new declaration style might look a bit strange to people used to the old style. But one could argue that using it will make it more consistent for the cases when you really do need to use it. Anyway it's just a matter of style. Not really a need to discuss it IMO.

2. Some people argue that

  auto v = T{x};
should be the new way of defining variables with types. The use of {}-initialization should prevent unnecessary narrowing. In this case () has to be used because a specific ctor is to be called. But using that style would make it more consistent with the rest.

Re: The bell has tolled for rand()

#16

Post by tedunangst »

StephanTLavavej wrote: post #12
leni536 wrote: post #11

Why is a specific random generator should be in the standard at all? Random generators are quite a dangerous area. Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure? It could become obsolete in less time than expected. It's mostly true for CSPRNGs. Maybe that's why they are considering Mersenne Twister which is "good enough" for many use cases but not meant…

std::random_device is part of C++11, and VC's implementation guarantees that it's crypto-secure.

The problem is the standard doesn't guarantee that, so people will inevitably read the standard, decide that they can't actually trust random_device, and then build their own, much worse version.

Re: The bell has tolled for rand()

#17

Post by fafner »

forrestthewoods wrote: post #7
jlebar wrote: post #2

Not to focus on a question unrelated to this blog post's point, but * "auto main() -> int" could be just "int main()". * "auto v = vector (20);" could be just "vector v(20)". * "auto print_value = [](auto&& v)" could be (I'd argue should be) "auto print_value = [](const auto& v)". "auto" is useful, "auto" is great. But "auto" is not an end in and of itself. (Bring on the C++(11) haters, blah blah.)

I'm not convinced auto should ever be used for anything other than iterators and anonymous types. There are other instances where it's relatively fine to use. Perhaps a few where it's even slightly better to use. But in C++11 I think it's by far best to limit it to there be explicit cases I mentioned. In C++14 I'll extend support to lambdas in some cases but will need to experiment to say for sure.

Sorry, but your comment lacks substance because you don't provide any argument for the way you think. Why should it only be used for iterators and anonymous types?

There is a pretty good argument for using the

  auto var = T{val};
style of defining variables. The {}-initialization won't narrow literals. You can find more discussion about this in GotW.

Maybe you have a good reason for not liking the style and there certainly can be arguments against it. But from experience I find that many people opposing more use of auto simply oppose it because it is different to their old ways. Therefore I'd like to see a proper argument for your comment.

Re: The bell has tolled for rand()

#18

Post by noselasd »

lloeki wrote: post #9
DonHopkins wrote: post #5

"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…

If I were to use C, what should I be using instead of rand(3)? A cursory look at rand(3) SEE ALSO hints at candidates but random(3) seems to hardly fare better†, arc4random(3) isn't available on glibc. † A few notes about rand as the parent suggests, but nothing regarding mod bias, srandom initial state, or threads: > It returns successive pseudo-random numbers in the range from 0 to (2 31)-1. The period of this rand…

How well does the rand48 family of functions fare ? http://pubs.opengroup.org/onlinepubs/7908799/xsh/drand48.htm...

Re: The bell has tolled for rand()

#19

Post by fulafel »

DonHopkins wrote: post #5

"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…

The claim that the C standard suggests not using it is disingenuous: The footnote in question just says that there aren't implementation quality guarantees and specific requirements can be met with application specific RNGs. This applies to most of the standard library...

Also the anecdote about bad rand() in a 1983 BSD libc says little about current rand() implementations!

These look ok, for example:

https://github.com/lattera/glibc/blob/master/stdlib/random_r...

https://www.opensource.apple.com/source/Libc/Libc-320/stdlib...

Of course it's true that relying on libc implementation quality is always risky for maximally portable programs. Same can be said for stdio, malloc, etc etc.

Re: The bell has tolled for rand()

#20

Post by [deleted] »

AceJohnny2 wrote: post #6
DonHopkins wrote: post #5

"The C random library has always been… to put it politely… less than ideal. Okay, it’s pretty fucking horrible. It’s so bad that the C standard itself suggests you’d be better off not using it." Back in the days 4.2 BSD or so, the BUGS section of the manual entry for rand understatedly mansplained that it had "bad spectral characteristics". In fact, it was so bad that the lower bit alternated between 0 and 1 every ti…

> manual entry for rand understatedly mansplained Heh, I see what you did there, but the downvotes imply others didn't.

[deleted]
Post reply on HN