Hacker News new | past | comments | ask | show | jobs | submit login

You misunderstand me. I think random(3) should have been omitted from the C standard.



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).)


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.


I thought NaCl was something related to browser plugins. What is the connection with crypto?


Name collisions: http://nacl.cr.yp.to/

Although, I've never actually seen it used in the wild.


Threema use it. (I don’t know if they use it in a sane way though.)


They do. There's an audit that confirms it, and you can use Validation Logging to verify it yourself: https://threema.ch/validation/


I think they understand what you're saying. I agree with the other two that not having a clean, working standard means you get people rolling their own or digging out libraries. Quality varies wildly cuz we're talking random numbers with many issues resulting. People would still want a standard, in C or C++, that lets them do this correctly without problems.

So, it leads me to guess there's two ways the the C++ situation would've been made unnecessary:

1. Leave it out of C itself but pro's build and maintain a de facto standard in form of a library as easy to use as random and widely available. Can even be OS random facilities cleanly wrapped.

2. Put a good one in C standard. Becomes the standard de facto and officially.

Preconditions didn't exist or convenience prevailed. So, now there's a new attempt at dealing with the mess. That's my guess as a person looking on from the outside rather than a user of all these tools. Just to be clear on that part.


Ah well. I could see where that'd not have been an entirely bad thing.

However, eventually you need to provide something that works. There is some value in having a portable way to generate random numbers. I can't think of a language that doesn't define one, and I don't think that is by accident.


I think that would have been a real bummer for coders back before the Internet was really a thing. It's a pretty common thing to need and hard to implement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: