On Tue, 2005-06-28 at 10:02 -0700, Mark Mitchell wrote:
> Joe Buck wrote:
> >
> > int blah(int);
> >
> > int func(int a, int b) {
> > if (b >= 0) {
> > int c = a + b;
> > int count = 0;
> > for (int i = a; i <= c; i++)
> > count++;
> > blah(count);
> > }
> > }
>
> Yes, I understand.
>
> I just didn't imagine that these kinds of opportunities came up very
> often. (Perhaps that's because I routinely write code that can't be
> compiled well, and so don't think about this situation. In particular,
> I often use unsigned types when the underlying quantity really is always
> non-negative, and I'm saddened to learn that doing that would result in
> inferior code.)
The real question is how often anyone is writing a loop (with an
unsigned of signed index) that is designed to wrap....
So maybe at the end of this lengthy discussion, one decision to make is
introduce a flag -floop-index-may-wrap and assume by default that loop
indices never, ever go outside of the range of values allowed by the
underlying type (or the opposite if backward compatibility is judged
more important).
A few months ago, problems with integers that may possibly wrap was
found to be a major penalty for STL vectors because loops over iterators
were never unrolled (because the increment on pointers is 4 and the
unroller was not able to decide the finiteness of a loop in such a
case). Zdenek (I hope my memory does not misattribute the work)
corrected that for increments that are powers of 2 (in which case it is
easier to decide whether the loop is finite or not). The fact remains
that the loop unroller currently must be pessimist in many cases
assuming that the loop induction variable may wrap ending up in an
infinite loop....
