Hypothetical question:
If all these OS software was written in a memory safe language like say rust, would it be possible to get rid of these 'off by two' and 'out of bounds' error completely making the world a better place?
But please don't think of Rust (or anything else) as a silver bullet. If you are doing systems programming you are going to deal with unsafe code somewhat frequently. And, by not being exposed to this kind of programming often enough, it's possible that more errors will slip through the cracks.
Then there's a whole class of errors that cannot be prevented by memory safe languages. They cannot prevent crappy practices.
While true, it is quite different have to worry about lets say 10% of the code easy tracked down by unsafe blocks, or every time a string, array, memory allocation, numeric manipulation is performed.
Hypothetically you could get rid of them in any language. And hypothetically you could introduce new bugs and vulnerabilities by rewriting the code in a new language.
While Rust does solve some of the problems that C++ creates, there's no substitute for good programming and thorough testing.
Yeah but with a language that prevents memory errors wont this be avoided by default? I'm thinking that developer effort would be put into making other features or fixing bugs. Right?
That is naive. Yes, trivial out of bounds memory errors can be prevented, but no language can prevent (accidental) resource leakage which opens up for other vulnerabilities. Besides, most modern languages are written in C/C++ anyway so you have to trust the language implementors to write perfect memory unsafe code which of course they can't.
> Besides, most modern languages are written in C/C++ anyway so you have to trust the language implementors to write perfect memory unsafe code which of course they can't.
That happens to be more a factor of not wanting to rebuild everything from scratch than anything else.
Go reference implementation is fully bootstrapped in Go.
D guys a few months ago ported their frontend to D.
C#, VB.NET and F# compilers are botstrapped nowadays. With .NET Native, maybe some other parts could eventually be re-written.
The OpenJDK gets less C++ with each release and there is the plan that when AOT lands, they will slowly migrate other parts to Java as well.
Of course trying to write an optimizer from scratch that beats LLVM or GCC backends is an herculean task, hence why most projects happen to use them as backends.
