4 ms·
> Just don't magically remove code that I wrote. Compile with O0. > Yes, and it is wrong. Breaking existing programs with magic that simply removes code that
by staticassertion 10y ago
> Just don't magically remove code that I wrote.
Compile with O0.
> Yes, and it is wrong. Breaking existing programs with magic that simply removes code that is clearly there in order to eke out a bit of performance is wrong.
Well welcome to writing C? It's been this way for a long time and that won't change - UB is critical to performance and doesn't always lead to unsafety. If you're programming in C, don't blame the compiler when your UB leads to remote code exec, you should have known what you were getting into.
- mpweiher 10y ago> Well welcome to writing C? I've been writing C for 30 years. > UB is critical to performance Not really, no. See "What every compiler writer should know about programmers or “Optimization” based on undefined behaviour hurts performance" (referenced elsewhere in this thread) http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201...
- staticassertion 10y agoC optimizers have and will optimize around UB. Feel free to call it a bug in C, the compiler, or the programmer, or the code - when you write C, when you use a common compiler, you're asking for vulnerabilities. Thanks for the paper. It's very interesting but I think it has no real impact on my initial statement - these optimizations aren't going away, you can continue to expect problems like this vuln in the future for the same reasons.
- mpweiher 10y agoHaving something wrong be or become reality doesn't change it being wrong.
- staticassertion 10y agoOk... so what? I don't care if you blame the compiler or the spec, and no one else should either - the end result is the same, vulnerable code.