On Wednesday 12 August 2009 07:26:18 Sergei Golubchik wrote:
[...] There are certain warnings and classes of warnings that I don't want to see in the code, right. But there are many others - fixing them only obfuscates the code, adds ugly hacks (and long comments /* we have to do it this way bla-bla-bla otherwise gcc complains that bla-bla-bla */). And, true, fixing warnings may also uncover bugs behind them - but if I'll have time to waste I'd better go to Vegas, I'll have better chances there anyway.
Again, to avoid misunderstandings, I'm not against fixing warnings :) I just don't like absolute rules. "Joins are slow", "no mutexes in the code", "zero warnings when all -W* are enabled", and so on.
To me, the cost of warnings isn't only about the problem they might tell something about. It is that we miss the new ones that tell about real problems. When I have worked on projects that have many warnings, it's impossible to find new ones I introduce. So noone cares about warnings at all. After working many years on code to be compiled by many different compilers, it's always been my completely firm rule never to allow compiler warnings. There are indeed places where I have had to introduce the "shut-up-silly- compiler-warnings-code", but it's maybe one or two places per project. And in my experience, most compiler warnings either point to real potential problems in the code (possibly maintenance problems instead of errors) or something that other compilers will treat as errors. -Wall -pedantic -Werror are good gcc flags. Some projects can add -Weffc++ for c++ code, but I have had mixed results with that - too many bad warnings for my taste. Bo.