5 ms·
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 vul
by sovande 10y ago
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.
- pjmlp 10y ago> 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.