Mark Mitchell wrote: > In this specific case, we know there is a significant performance > impact, and we know that performance is very important to both the > existing and potential GCC user base, so I think that making the > compiler more aggressive at -O2 is sensible.
Whether or not that is sensible depends on the outcome of running -Wstrict-overflow over some code, to get an idea of how pervasive the use of post-overflow checking or other vulnerabilities based on the undefinedness of signed integer overflow really is. Making a call here before knowing this is not sensible. In fact, I'm tempted to argue that it is generally a bad idea to do optimizations that lead to the same expression being evaluated to different results without making the user explicitly request them. But if the gcc user base prefers performance over security, and you are willing to go with them, they might get what they deserve. Microsoft has suffered from security problems for so long that they have put an immense effort into Vista to fix it. I'm not saying it will be bug-free, but it will be significantly harder to actually find an exploitable bug in it. Windows got all of the attention from the bad guys for sheer number of installed systems so far, not because Linux is inherently more secure. But if Vista turns out to be infeasible to attack, their attention will wander to the next promising target. And that will be Linux and the BSDs (including the one with the apple). > And, Ian is working on -fno-strict-overflow, so that users have a > choice, which is also very sensible. Perhaps the distribution vendors > will then add value by selectively compiling packages that need it with > -fno-strict-overflow so that security-critical packages are that much > less likely to do bad things, while making the rest of the system go > faster by not using the option. Again, what exactly do you think is a "security-critical package"? In my eyes, any program that ever touches external data, be it from the network or reading some file, or any library that links against such a program is relevant to security, in that a bug in it might be used to launch an attack. This translates into pretty much everything in a distribution, so much that -fstrict-overflow should be the exception, not the norm. I'm curious to see what the vendors will be doing. > I think we've selected a very reasonable path here. I don't agree, unless you have a "performance is more important than security" policy. In that case, however, I will go looking for another C compiler. Andreas