4 ms·

I posted something three days ago about memory safety that I feel like basically could be echoed here: https://news.ycombinator.com/item?id=39542875 https://new

by jerf 3y ago

I posted something three days ago about memory safety that I feel like basically could be echoed here: https://news.ycombinator.com/item?id=39542875 https://news.ycombinator.com/item?id=39542875 Albeit modulated since I'm sure lcamtuf is not actively advocating for memory unsafety the way I'm sure some people are. But I don't understand why anyone is bothering to state any objections to memory safety. Modulo the issue of old code bases in memory unsafe languages that can not be simply discarded or rewritten... I personally have done translation projects between languages, I am well aware of the costs involved and freely acknowledge them... there simply isn't any argument in favor of memory unsafety. There's no benefit to having memory unsafety around. If anything memory safety is a positive benefit, or to put it another way, programming in a memory unsafe language is positively harder than a memory safe language. The proof of this is the existence of the "unsafe" package/module/library/whatever that exists in your language, meaning that you can selectively call out to it whenever you do in fact need to. That means the rest of the time you don't. So why give any cover to memory unsafe languages? There's simply no argument for them. You do not need a language that lets you access outside of array bounds. You do not need a language that lets you run a pointer everywhere without regard for bounds. Even if you need bounds check removed or something, you only need it in a particular tight loop, not pervasively throughout your language. There is nothing, no positive advantage they offer that overcomes the overwhelming, massive costs they've concretely imposed on society as a whole. And I'm Mr. Everything Has Costs And Benefits. But the benefits are so, so wispy here and the costs so large and concrete.

kbolino 3y ago
I don't think you're wrong but I do think putting all the burden and emphasis on the last mile (high-level software libraries and application software) will not be enough. Memory safety needs better support from operating systems and hardware, both of which have improved but have been much slower to change than application programming. Systems programming, sitting in the middle of the two, is caught between a rock and a hard place.
skywhopper 3y ago
The point is that rewrites are costly and introduce new bugs. New software written in safe languages to replace old software will inevitably introduce new bugs and repeat old ones. That’s not a reason against using memory safe languages, but the danger is that a too-keen focus on memory safety risks devaluing other, far cheaper means of improving security. Yes, use memory-safe languages for new projects. But don’t lie to yourself and everyone else and say that they will come anywhere close to making a significant dent in the rate of security bugs.
tsegratis 3y ago
Allow me to be contrarian Hard to count, but, excluding webapps, maybe 98% (or more) of generally used software has a basis in c/c++. Your fridge, watch, computer, car, phone. clang, gcc, photoshop, your browser, almost any desktop app, your 3d games. The remaining 2% (or less), is maybe even majority written in assembly, forth, etc, in your calculator and toaster So to agree with you, I would need an explanation of why such wispy benefits led to such a large effect Oberon existed, pascal, ada, they are excellent and safe, why then were they not popular? Note: Easy to disagree with that percentage, but the effect is enormous, and as far as I understand, not explained by the current bandwagon
- Jtsummers 3y ago
  Politics and price. C and Unix were free, other options were not. Oberon is also unsuitable for most use-cases if taken to Wirth's extreme, though the other variations are better they were still very niche (also it was never exactly well-known or well-distributed). With Pascal, which Pascal? The early Pascal's needed extensions (leading to the Modula line and Delphi ultimately). They also tended to cost, people like free. Politics are why Ada lost, along with costs. Ada, as a mandatory language for a time in DOD, had a compelled audience with "deep" (not always that deep) pockets who could afford $10k/seat licenses (or more), that didn't make it a suitable language for the *nix hackers of the 90s and Linux (in particular) has eaten the world. So C and C++ won out as the systems languages. Not because of quality, but price and politics. EDIT: I mean Unix broadly, there were obviously non-free commercial Unixes.
- jerf 3y ago
  That's not a contrarian take, because it's just not relevant. "C and C++ seem to work" is not the question at issue. Moreover, C and C++ are the world we live in in which CVEs flow like water, where our systems crash routinely, where we have the problems that are making us have this discussion in the first place. If you think this is all just fantastic, that there isn't any option of doing better, we just have to live with the effects of memory unsafety, and there's no point even trying to improve the quality of our base level tools, then honestly all I can say to such a battered spouse syndrome sufferer is that we're going to have to agree to disagree.

by jerf 3y ago

kbolino 3y ago

I don't think you're wrong but I do think putting all the burden and emphasis on the last mile (high-level software libraries and application software) will not be enough. Memory safety needs better support from operating systems and hardware, both of which have improved but have been much slower to change than application programming. Systems programming, sitting in the middle of the two, is caught between a rock and a hard place.

skywhopper 3y ago

The point is that rewrites are costly and introduce new bugs. New software written in safe languages to replace old software will inevitably introduce new bugs and repeat old ones. That’s not a reason against using memory safe languages, but the danger is that a too-keen focus on memory safety risks devaluing other, far cheaper means of improving security. Yes, use memory-safe languages for new projects. But don’t lie to yourself and everyone else and say that they will come anywhere close to making a significant dent in the rate of security bugs.

tsegratis 3y ago

Allow me to be contrarian Hard to count, but, excluding webapps, maybe 98% (or more) of generally used software has a basis in c/c++. Your fridge, watch, computer, car, phone. clang, gcc, photoshop, your browser, almost any desktop app, your 3d games. The remaining 2% (or less), is maybe even majority written in assembly, forth, etc, in your calculator and toaster So to agree with you, I would need an explanation of why such wispy benefits led to such a large effect Oberon existed, pascal, ada, they are excellent and safe, why then were they not popular? Note: Easy to disagree with that percentage, but the effect is enormous, and as far as I understand, not explained by the current bandwagon

Jtsummers 3y ago
Politics and price. C and Unix were free, other options were not. Oberon is also unsuitable for most use-cases if taken to Wirth's extreme, though the other variations are better they were still very niche (also it was never exactly well-known or well-distributed). With Pascal, which Pascal? The early Pascal's needed extensions (leading to the Modula line and Delphi ultimately). They also tended to cost, people like free. Politics are why Ada lost, along with costs. Ada, as a mandatory language for a time in DOD, had a compelled audience with "deep" (not always that deep) pockets who could afford $10k/seat licenses (or more), that didn't make it a suitable language for the *nix hackers of the 90s and Linux (in particular) has eaten the world. So C and C++ won out as the systems languages. Not because of quality, but price and politics. EDIT: I mean Unix broadly, there were obviously non-free commercial Unixes.
jerf 3y ago
That's not a contrarian take, because it's just not relevant. "C and C++ seem to work" is not the question at issue. Moreover, C and C++ are the world we live in in which CVEs flow like water, where our systems crash routinely, where we have the problems that are making us have this discussion in the first place. If you think this is all just fantastic, that there isn't any option of doing better, we just have to live with the effects of memory unsafety, and there's no point even trying to improve the quality of our base level tools, then honestly all I can say to such a battered spouse syndrome sufferer is that we're going to have to agree to disagree.