------- Comment #35 from andreas at andreas dot org 2007-01-21 17:29 ------- (In reply to comment #34) > > The range analysis has nothing to do with just assuming integers can't wrap. > Partly wrong, range analysis is helped by the fact assuming integers can't > wrap.
And in those cases then leads to code that does unexpected things, such as breaking existing security checks. > >I don't see why making make_range in fold-const.c > It is already if you use -fwrapv. No, it is not. What happens is that make_range will generate invalid ranges in any case, and then optimizations depending on those ranges will be skipped when -fwrapv is specified. (Please correct me if I'm reading the code wrong, even though I'm maintaining an open source compiler myself, I don't have much experience reading gcc code.) What this means is that in the example you posted above, even though the compiler *could* compute a correct range and properly fold the if statement even given LIA-1 compliant overflow behaviour, gcc will skip the optimization when passed -fwrapv. After reading the code, I can certainly see why making -fwrapv is something you'd rather avoid: it makes a lot of optimizations go down the drain. But: this wouldn't have to happen if you fixed make_range to do something sensible instead. I wonder why this didn't jump right into the face of the person who implemented -fwrapv, it must have been a real pain to track down all the usages. > The problem here is that the people who added these security checks in the > first place did not know C. So either GCC can be changed or these programs > can > be fixed by the way comp.lang.c faq recommends or by using -fwrapv. If we > change GCC, you punish the people who actually write defined C so that is out > of the question. Well, maybe they didn't. I did a non-representative survey with the C programmers I know: everybody assumed overflow of signed ints would behave as it does for the underlying machine representation. Not a single one was aware of the danger. And we're talking of people with 20+ years of professional experience in the field here. And I think people who do know can be expected to read the gcc manual to figure out that there were a -fnowrapv option to make their code go a wee bit faster. Did I mention that I have yet to see a convincing example of a case where undefinedness of signed overflow actually makes code go faster that isn't per definition a security problem? Especially after having learned from reading the gcc code that -fwrapv turns off a whole lot more optimizations than it has to? > I think the real issue that some of the security folks want to check after the > fact that something happened instead of before it happend which is the correct > way to do anything. No, I would call any security expert who refuses to learn that there is a problem with signed overflow and how to check for that correctly an idiot. The issue here is really how to deal with the existing body of code out there that was written in the implicit assumption of LIA-1 compliant behaviour. This is about risk management for all the Linux systems out there. It is not about "whose fault is it". It's about "Houston, we have a problem, and need it fixed". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
