S
Shao Miller
(snip)(snip)for (i = 0; i < sizeof arr / sizeof arr[0]; i += 10)
Let's assume that we really want to deal only with every 10th element
rather than second-guessing the intent.That is just what I've been trying to suggest: The diagnostic can be
considered useful for second-guessing the intention. I cannot argue
that if I begin by agreeing that it's false.![]()
Yes, but so can a few million other things.
It doesn't help much to put on each statement:
"Warning: this statement could be wrong"
If you find the statement:
i += 3;
You could have the warning: "Are you sure you meant 3, and not 4?"
and once in about 1e12 times you might be right.
Warnings have a cost, if nothing else than in the time the programmer
has to read them and ignore them. But even more, too many warnings will
make it more likely to miss the ones that are actually important.
The programmer will just give up and turn them off.
So, really really think about how useful a warning will be before
suggesting that it should be added.
Sure. Let me try to provide some of the missing context:
Once upon a time, I saw a warning about a 'for' loop. It turned out
that there was nothing wrong with the 'for' loop, behaviour-wise, but
the loop could've been reworked so as to avoid the warning, and to look
more sensible besides that. We were using -Werror, so the warning
actually stopped the build process, which was undesirable. It was
especially undesirable since it was a false positive for out-of-bounds.
It was, however, still useful for drawing attention to the weird loop,
and for understanding that behind the scenes, the array index and a
pointer arithmetic alternative happened to be translating the same way.
It turns out that we didn't desire such false positives, so we removed
this ambitious form of warning and left the loop as-is.
So I wouldn't be surprised if mudflap did the same thing, even though
the program is fine.