> better way than "Crash" or worse - silent corruption
My apologies, I could have sworn that your text was 'better way than "Crash" <end>'. And not in fact, 'better way than "Crash" or worse - silent corruption'.
Although, silent corruption is a possible problem in memory safe languages. True, memory safety gives you some sort of protections, but threads and/or setting the wrong value can still give a memory safe corruption.
No, I was talking about the ability for an attacker to craft malicious input such that a memory unsafe program begins executing that input as if it were the program. Something that you generally do not have to worry about in a memory safe language.
I think I edited it within seconds of posting, it was just "Or worse" IIRC, and noticed I'd missed it when rewording it just before posting. I guess you were lucky enough to see it immediately :P It's a bad habit of mine to post then re-read with fresher eyes and notice problems in my comments - exactly like this clarification.
Security of technology is really a process, not a boolean. "Memory Safe" doesn't mean "Safe", and "Not the current crop of Memory Safe" languages doesn't mean "Unsafe". There's so much we can do with the tools we have right now to help with current codebases and apps, too many people seem to have the idea you have to do a ground up rewrite using the latest and greatest language, or you're an idiot and/or lazy.
Honestly, the whole world isn't going to be rewritten in rust tomorrow, imagine the time and effort that would take and all the other errors a ground-up rewrite of well-tested systems would cause. But we can probably rebuild 90% of the existing world in a "Safer" manner right now. We should be promoting that too, and not let perfection be the enemy of better.
> But we can probably rebuild 90% of the existing world in a "Safer" manner right no
I strongly agree with this mindset. The only caveat I would offer is that some architectural structures that c and c++ allow probably don't amend themselves to fixing even if you can detect them.
Although just like you can write any language horribly, I think you can write almost any language well.
It's hard to see how tools that allow you to do that can be a bad thing. I'm certainly not going to be paying to rewrite everything from the ground up in rust or otherwise.
My apologies, I could have sworn that your text was 'better way than "Crash" <end>'. And not in fact, 'better way than "Crash" or worse - silent corruption'.
Although, silent corruption is a possible problem in memory safe languages. True, memory safety gives you some sort of protections, but threads and/or setting the wrong value can still give a memory safe corruption.
No, I was talking about the ability for an attacker to craft malicious input such that a memory unsafe program begins executing that input as if it were the program. Something that you generally do not have to worry about in a memory safe language.