[GRASS-dev] [GRASS-SVN] r52607 - grass/trunk/raster/r.lake

[Glynn Clements]

Maris Nartiss wrote:

> just to clarify.
> It's not a GCC bug but a valid warning of an exploitable issue:

No it isn't. GCC cannot tell the difference between an exploitable
case and a non-exploitable case unless the format string is a literal,
but internationalisation requires dynamic format strings.

> http://en.wikipedia.org/wiki/Uncontrolled_format_string
> Still for most of GRASS codebase it's harmless as strings are fixed
> and not user provided.
> Those, who don't see any warnings, should try CFLAGS="-Wall -Wformat
> -Wno-format-extra-args -Wformat-security -Wformat-nonliteral
> -Wformat=2" make
> 
> The question now is - why we shouldn't change code to get rid of most
> of compiler warnings?

Because it's more correct to change the compiler options. If you don't
want lots of bogus warnings, don't use warning flags which have a high
proportion of false positives.

> Gazzillion of irrelevant warnings might just
> hide some more important ones thus I personally would be +1 for
> working around most common warnings to make compilation more silent
> and thus more easy to spot any new issues.

If you want to change the code to eliminate warnings, start with the
ones which indicate genuine issues with the code, such as
uninitialised or unused variables, type mismatches, etc.

Actually, on second thoughts, don't. That task should be left to
someone who prefers correctness over hiding warnings. There have been
too many *real* bugs hidden by simplistic "fix warning" changes,
mostly a result of hiding type-mismatch warnings by inserting a type
cast, when in fact the data really did have the wrong type.

-- 
Glynn Clements <glynn at gclements.plus.com>