[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc

["veksler at il dot ibm dot com" <gcc-bugzilla@gcc.gnu.org>]

------- 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