Re:“C is how the computer works” is a dangerous mindset for ...
by shadowgovt on Tuesday March 31, 2020 @12:54PM
(#22739557)
Every language has some expression weaknesses, and C/C++'s are such that the languages make static analysis tools mandatory for correct code (much like Python makes every-line-is-executed unit tests mandatory for correct code).
Re:“C is how the computer works” is a dangerous mindset for ...
by enhray on Tuesday March 31, 2020 @12:33PM
(#22739300)
I don’t think that this bugginess is an inherent property of these languages, because there are other practices that could lead to reduction in total bug count and severity, apart from integrating additional tooling.
Out of curiosity, how many bugs you found by using these tools could have been avoided by using a “watertight” memory management system [0], with strong decoupling of pointer and object lifetimes?
[0] https://floooh.github.io/2018/06/17/handles-vs-pointers.html
Re:“C is how the computer works” is a dangerous mindset for ...
by AaronFriel on Tuesday March 31, 2020 @12:51PM
(#22739517)
I'm curious who the target demographic is for this, people who think they need bare metal performance in a language that gives them access to bare pointers, know that most humans aren't capable of following Uncle Ben's adage[1], and then voluntarily give it up while insisting they need it?
I think almost any JITed memory safe language will be faster than using handles for all object access. At least Java, .NET, JS, etc under the hood can avoid "double dispatch" of memory access. And you can use things like arenas to ensure same objects are allocated adjacently, etc.
[1] With great power comes great responsibility
Re:“C is how the computer works” is a dangerous mindset for ...
by saagarjha on Tuesday March 31, 2020 @01:59PM
(#22740390)
The solution presented solves "memory corruption" from the point of not having undefined behavior, but it doesn't really protect against "I accidentally created an index that has nothing to do with memory I manage, but is still 'in bounds' to the code that handles lookup".
I’ve mentioned before here, but when I found a reasonable number of bugs in critical library used throughout one of the FAANGs written by their most senior and brilliant engineers by running a fizzier on it for a few hours, my opinion of those languages changed.
Integrating Valgrind and Clang’s checker, and running AFL for many CPU years was critical in unearthing some really funky crashes, hangs, overflows. Without those tools it’s not clear that those bugs would have been fixed. In fact, one of them affected me a few months prior and AFL helped uncover the codepath that was failing.