|
|
|
|
|
by DCKing
3367 days ago
|
|
We've gone from arguing "the security issues for C are overrated" to now arguing either "security issues don't have solutions I like" or "real programmers should be able to deal with these things" (I'm not sure which). In addition, you're arguing a strawman. Nobody says that direct memory access should be taken away permanently. Many 'safe' languages allow you to directly access memory when you need it. > A computer is a tool for computation not an adult diaper designed to prevent leaks. This attitude is why we can't have nice things. It would be great if you cared more about the security and safety of the things you make than whether you look cool while making them. |
|
I don't think anyone was arguing any of those points. What was being explained is that C/C++ is designed to be flexible and simple and it was know from its inception that that flexibility lets the programmer 'shoot them selves in the foot'. Building out tooling to address any error patters in usage and keeping that basic simplicity and flexibility is desirable. More desirable then moving to a more complicated less flexible language that may eliminate some possible errors.
There are literally millions of C/C++ programmers and projects writing secure reliable code. Picking out a few open source projects and turning there bug reports into an internet drama is not going to convince anyone the sky is falling.
> In addition, you're arguing a strawman. Nobody says that direct memory access should be taken away permanently.
I think its fairly clear that the sentiment was.
"putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it."
This has been the justification for every misguided attempt to 'make things better' for a very long time.
A short list of unnecessary things that needed to be stopped thought the years. * Pointers * Manual memory management * Unconditional Jumps * direct access to machine words ie bytes * assembly instructions. etc..
I am fairly skeptical of arguments that suggest 'the programmer does not need that'.