Andrew Haley wrote:
> -Wstrict-overflow=2 triggers when GCC encounters expressions that
> reduce to a constant, where that evaluation depends on overflow not
> occuring. In this case the expression is
>
> expbuf + 120 > get_buf()
If this is the case I can see the merit of the warning, because that can be
reduced to 120 > 0, which is a constant. But my problem ist, that I don't
see where this expression comes from? The condition in question is
argptr >= endbuf
which can be written as
expbuf + i >= expbuf + 120
which can be reduced to
i >= 120
which is not a constant, and therefore not a cause for this warning.
This could get constant if gcc does some loop unrolling, for the first loop
this would result in the expression you quoted. But then I would have hoped
that gcc doesn't warn about constants or dead code when unrolling a loop,
because they naturally happen then. And I can't do anything against it
except unrolling manually and this would make it less readable.
> I doubt that it ever was. -Wstrict-overflow=2 is informative, for the
> programmer. It doesn't suggest that anything is questionable about the
> program, and in this case it's difficult or impossible to avoid.
If an originally non-constant if-expression is reduced to a constant one
that is for me something to worry about, where a warning/error is
appropriate. It means that the following block is always or never executed,
something the programmer usually didn't intend, otherwise he wouldn't have
written the if-condition.
And this reduction to a constant is what differentiates -Wstrict-overflow=2
from -Wstrict-overflow=3 (according to gcc's documentation). For the later
I would accept your description as it being purely informative.
> Re upgrading: over time, GCC gets better and better at diagnosing and
> providing information. This inevitably means that programmers using
> -Werror with high levels of warnings have to change their programs
> when a new GCC is used.
I understand and I welcome better analysis and optimization techniques.
And I changed several parts due to new warnings. But in this case I don't
see any possibility that wouldn't make the code worse except deactivating
the warning. Which is sad and normally beside the point of a warning.
Thank you for your patience and best regards,
Alex
