Hi Colin
1) Since
main() must return a value, but never actually returns this is a catch 22. If the return is removed there is either another waring or an error. Certainly can be ignored.
2) No idea why IAR says that
/**********/ is an illegal nested comment (
?) In any case I can't imaging that it is dangerous in any way.
3) This warning is because 2 (or more) volatile registers are being read and operated on. It doesn't matter in which order the code does the reads, the warning will always be given. The registers are declared valatile since their content can change (at any moment) but the bits of interest won't. If the volatile is removed there will be no warning but a new risk of the compiler optimisng something away that it shouldn't (turns a warning into a potentially serious problem). Maybe some reading of volatile registers and placing them into non-volatile storage (with castings) and then the comparison, would quieten the compiler - it probably wouldn't do the code itself any favours though. I don't actually see any risks with the code so I have tended to "thank" the compiler for the indication that there may be a potential problem, check to see whether there could be one and the ignore it if nothing is seen (or ever experienced). I think that this one falls into this category. There are usually pragmas which can be used to disable warning if one is sure that they are nothing serious but these pragmas change between compilers - therefore I tend to accept that there are a certain number of warnings with a particluar build (may also change when new compiler version are installed) and only look again if the number of warnings increases.
4) This one is always flagged. It is due to a slightly wierd use of a case statement in a code area like:
case x:
if (z == 0) {
var abc = 0;
case y:
abc = 1;
}The
if (z == 0) {
}area is being used to declare and initialise a variable.
If the code enters at
case y: it will be able to use the variable
abc (in its context) but it will bypass its initialisation.
However in the code in question the variables that the compiler is warning about are in fact being initialised with different values (appropriate of the code starting at this case) just after the
case y: line. Therefore it is true that the initialisation can be bypassed but there is no risk of the initialisation being missed because this is in fact what is wanted from the (slghtly wierd) construction.
Regards
Mark
