Re: Question about -Wstrict-overflow=2

[Segher Boessenkool <segher@kernel.crashing.org>]

On Sun, Mar 07, 2021 at 02:56:27PM +0000, Andrew Haley via Gcc-help wrote:
> On 3/7/21 2:04 PM, Alexander Motzkau via Gcc-help wrote:
> > Andrew Haley wrote:
> >> 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.
> 
> Not all warnings indicate things that should be changed. We expect
> higher levels of warnings to cause false positives, many of which
> can't be avoided, which is why such warnings are not included in
> -Wall.

Yes.  If GCC would know something it warns about is an error, it should
report it as an error.  But it doesn't know.

Some warnings are for things that GCC knows (or its developers know,
really) are often wrong.  Other warnings are for things that aren't so
often wrong, but have a high impact.  And some are for problems that are
hard to find.

-Werror ignores all of this, and makes every warning an error.  That can
be handy for people who know they will ignore all warnings otherwise,
and it is not a huge deal for warnings that are part of -Wall (because
one of the conditions for being included there is that the problem is
easy to avoid, with a trivial code change).  But -Werror is only for
people who think life is too boring and they need some extra challenges,
otherwise.

There is no reason to avoid all warnings.  It is easy to avoid all -Wall
warnings, or even -Wall -Wextra (although if you never used that before
it will find a *lot* of questionable constructs in your code), but most
other warnings are not in either of those two categories precisely
because they are *not* easy to avoid.


Segher