News for hackers. Stuff that matters.
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".