Overeager Compilers Can Open Security Holes In Your Code

jfruh writes: "Creators of compilers are in an arms race to improve performance. But according to a presentation at this week's annual USENIX conference, those performance boosts can undermine your code's security. For instance, a compiler might find a subroutine that checks a huge bound of memory beyond what's allocated to the program, decide it's an error, and eliminate it from the compiled machine code — even though it's a necessary defense against buffer overflow attacks."

Re:old news from decades ago

[itzly]

That's an example of a programmer not understanding the rules of a conforming C/C++ compiler. It should be fixed in the source, not in the compiler.

Re:old news from decades ago

[K. S. Kyosuke]

I'd personally rather work in languages that are safe by default with optional (but available) extra performance/lower safety where explicitly instructed (the way Common Lisp does it, for example), rather than the other way around. I've come to the impression that most codebases would have fewer overrides in the former case rather than the latter. If you think the latter is preferable, what about all those bugs and security vulnerabilities we got "thanks" to that approach? Was it actually worth it?