I've been playing around with the ARM C compiler 6.6 and 6.7 for cortex m3 and I was wondering what is the best practice for the enabling of compiler warnings? What level of warnings should be a minimum? Would flagging missing noreturn and unused parameters actually help produce more efficient code? It was quite a bit of a change to go from 6.6 that had a lot of warnings on by default to 6.7 that has turned a lot of the warnings off. I prefer having the warnings off by default but it did make me wonder how many of them I should turn back on.
Personally, I like to treat ALL warnings as errors and treat it as an activity in acquiring a level of greater understanding.
Enough of the cow-dung though. My most recent real life scenario was having a project where the bulk of the source modules had to compile cleanly under an older version of Keil, Microsoft Visual Studio and GCC. Different compilers invariably tend to produce different amounts of warnings. When modifying the code such that it compiled cleanly on all platforms, I found a number of potential portability issues. Those issues were found as a direct result of me fixing the warnings.
Any place I have worked the rule has been "no errors no warnings" and were I to make the rules the rule would be the same.
A warning means "something is not right but MAY work". Would you accept "may work"?, remember "successful testing does not prove the absence of errors it only proves the absence of known errors.
Not really.
Many warnings are, "something may be right, but may not work in the way you intended"
for example,
if( x = something() )
is certainly valid - it is not wrong per se - but may not work in the way the programmer intended...