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.
I like the opt-in to a warning rather than opt-out as not all warnings are actually that helpful. -Wswitch-enum for example doesn't take into account the default statement and will produce a warning even though all possible cases are taken care of. If I'm migrating a project I don't wan't all of those warnings produced from every switch statement by default.
I specifically mentioned the noreturn and the unused parameter warnings because I use the RTOS and threads can have both. That code is not unsafe but would flagging that the function doesn't return and doesn't use the parameter produce more efficient code than just keeping the warning disabled and ignoring it?
Having only use uVision and the arm compiler in the past I have not had to deal with these warnings before. Having established that not all warnings are that helpful, what would the best practice be in enabling the warnings? Which warnings would be the most helpful? What level of warnings should be a minimum?
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...
I guess "best practice" is, at least somewhat, subjective.
The consensus so far seems to favour enabling as many warnings as possible.
Yes, some compilers can be annoying with their warnings.
"-Wswitch-enum for example doesn't take into account the default statement"
That does sound annoying!
"would flagging that the function doesn't return and doesn't use the parameter produce more efficient code than just keeping the warning disabled and ignoring it?"
Again, warnings don't tend to be about efficiency, and writing the code so that they don't arise doesn't tend to cost anything at runtime.
Although, in these particular cases, I guess knowing that a function doesn't return or that a parameter isn't used might open up some opportunity for optimisation ...
If you're concerned, try it and see.
"Having established that not all warnings are that helpful"
I'm not really sure that we have established that.
As is the case with most things in Engineering, I think you just have to do a cost-benefit analysis to see what makes sense for your particular case.
But I would still start from having everything enabled, and then only disable the ones that don't help your particular case.
Do you have a Coding Standard? What does it say?
My coding standard can allow warnings if there is a proper justification for it being there. This situation is quite rare though. It kind of changes when you can pick and chose which warnings to allow, and there is nothing about specifying warnings.
The consensus so far seems to favour enabling as many warnings as possible. This does seem like the best approach.
Again, warnings don't tend to be about efficiency I should be using the terminology "optimised" rather the "efficient". Is it easier for the compiler to optimise the written code if these attributes (and similar) are added?
I am disappointed that ARM does not have a definitive guide to it's own compiler. Trying to find out what each of the command line options actually do has been really difficult. The reference guide (static.docs.arm.com/.../armclang_reference_guide_100067_0607_00_en.pdf) and user guide (static.docs.arm.com/.../compiler_user_guide_100748_0607_00_en.pdf) sends you to the Clang documentation (clang.llvm.org/.../UsersManual.html) which doesn't actually tell you much. The best guide I found was a GCC guide (www.chiark.greenend.org.uk/.../gcc.html). It is a bit difficult to make informed decisions if the compiler vendor isn't going to tell you how the compiler works.