------- Comment #35 from veksler at il dot ibm dot com 2010-02-21 13:33 ------- (In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #32) > > > If this hazard is so prevalent shouldn't it deserve a separate PR? > > > If a method or function depend on a flag or macro then it can be handled > > > by overloading and specialization without ODR violation. > > > > It would be closed immediately as WONTFIX, to be clear. There is nothing we > > can > > do in the foreseeable future, it's **everywhere** and totally unfixable > > without > > breaking ABI and much more than that.
Yes, it is a big task which is probably not worth it, but is it unfixable? Is it possible that these ODR violations will ever be translated to security issues? For example, the data structure is updated in one translation unit in a way that causes memory corruption when accessed by a different definition in a different translation unit? This is all theoretic but as history has shown, theoretic security threats become real - eventually. > > I see that I'm not going to work on it. Actually, I'll wait one month or so, > > and then if I will not get at least one concrete proposal, I will close this > > one as WONTFIX. > > Or suspend it. I think this warrants a defect report anyway since I think > is_modulo was intended to describe CPU behavior as otherwise defining > signed integer overflow as undefined in one piece of the standard and > then requiring a sane answer for is_modulo in another part sounds > like a conflict of interest. > Maybe it is better to make things clear, but I am not so sure of the outcome. I think that is_modulo is meaningful only if it is true, otherwise, when false user's code can't rely on any specific behavior. Maybe is_modulo=false is the right answer even for -fwrapv after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
