However, if in File|Preferences you set compiler warnings to "all" you will get this:
C:\Users\Peter\AppData\Local\Temp\arduino_modified_sketch_311944\sketch_sep07b.ino: In function 'void loop()':
C:\Users\Peter\AppData\Local\Temp\arduino_modified_sketch_311944\sketch_sep07b.ino:19:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (millis() > Timer[0])
^
C:\Users\Peter\AppData\Local\Temp\arduino_modified_sketch_311944\sketch_sep07b.ino:30:14: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (millis() > Timer[1]); // This semicolon should not be here but code compiles ok....
^
C:\Users\Peter\AppData\Local\Temp\arduino_modified_sketch_311944\sketch_sep07b.ino:30:25: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
if (millis() > Timer[1]); // This semicolon should not be here but code compiles ok....
^
which apart from warning you about the signed/unsigned comparison, also points out that your if statement has an empty body.
Other compilers, such as MSVC, also give a warning, but not an error, for this type of statement.
Yes, unless there is a side-effect hidden in the condition such as:
if((inchar = Serial.read()) == 'a');
The test doesn't do anything but the side-effect is that inchar is set to the character read from serial input.
The associated curly braces have no function.
Yup. They just group the statements within them but when they aren't associated correctly with the if statement it doesn't really matter what happens with them.
I agree that in this case an if statement with nothing following it, even if it has side-effects, is really an error but the compiler writers have at least warned you of the problem.
It is actually a very good idea to have all warnings enabled and hunt them down just as diligently as you would any errors.
Here's a couple of examples why:
warning: array subscript is above array bounds [-Warray-bounds]
This one is fairly obvious. If you have an array, foo, declared to have 10 elements and you try to access foo[10] you'll run into problems which can be really hard to find.
In this code:
if (IsDead && DomeOpen)
the error message was:
warning: the address of 'boolean IsDead()' will always evaluate as 'true'
Even out of context, the warning actually tells you precisely what is wrong. IsDead is a function (not a variable) which is why it refers to 'boolean IsDead()' and what is required is that you use isDead() in the if statement so that the function is called. Even reasonably experienced programmers would have fun debugging this problem if they ignored warnings and this statement was buried in among a thousand other lines of code.
I try, especially after the first few compilations of new code, to make a habit of going through all the warnings to make sure that none of them are actually bugs in disguise like the two examples above.
JohnSan:
What's the point in making an assignment in a comparison statement unless it's an unintentional error?
char c;
while(someStreamObject.available()){
if(c = someStreamObject.read()){
// c is a good character, do something with it
}
else {
// c is a null character. Maybe that marks the end of a packet or something
}
}
JohnSan:
I can't see the point in that so to me it's 'an error'.
But the definition of an error is something the compiler can't understand, not the programmer. It's a good thing too. IF the compiler puked on every single line that the programmer didn't understand then the noobies would never stand a chance. Every single line would get marked error and someone else would have to compile their code for them.