Compiler asleep on the job?
Rick Murray (539) 13870 posts |
As part of copy-pasting some code from an earlier function, I didn’t need all the stuff that the earlier function snippet did, so I wanted to strip the outer
“which” is -1 on entry, and if it is something else on exit, the value supplied in R1 on entry to the SWI is legit. Otherwise choke and throw an error. Problem is, the code works fine for legitimate values, but locks up the machine (as dodgy code in SVC mode is prone to do) for invalid values. Thing is… why didn’t the compiler fault this? The code is gibberish and all I can imagine is that the compiler saw it as basically:
Shouldn’t this be a case of “warning: did you mean to create an infinite loop” or something? I just find it amusing that it’ll whinge about a pointer being passed to a SWI (signed int) or about stuff not in header files, but it’ll let this through without so much as a raised eyebrow… And yay! for C for having the same keyword work in two different senses. |
Tony Noble (1579) 62 posts |
Is that actually gibberish? The formatting is obviously out, but I’d have thought that:
is functionally equivalent to:
Having just tested with gcc on linux, it appears that’s the case. Both the following happily compile:
and:
Both also give the same result when run – both loop infinitely. |
Dave Higton (1515) 3555 posts |
It’s quite normal, especially in the embedded world, to have infinite loops. |
Chris Evans (457) 1614 posts |
Intrigued. Do you mean a loop that can never be broken out of? |
Jeff Doggett (257) 234 posts |
In the embedded world main() is always an infinite loop.
(I write code for fire alarm systems, and the last thing that anyone wants is for the smoke sensor or alarm panel code to ‘exit’!). Most critical hardware will also have a watchdog chip that will reset the device if the software fails. So to test it we can use a while (1) loop. |
Tony Noble (1579) 62 posts |
Similarly with some parallel processing languages (Occam springs to mind) – each process is effectively a piece of code sat on its own processor in an infinite loop, waiting for input, doing something with it and then passing the result on to the next process… |
Chris Evans (457) 1614 posts |
Thanks Jeff & Tony I am duly enlightened! |
David Gee (1833) 268 posts |
Some compilers will issue a warning in the specific circumstance of having an “empty” loop (this can depend on the exact compiler settings). For example, Microsoft Visual C++ will say “Empty controlled statement. Are you sure this is the intent?” If using GCC you could try adding the comiler flag -wall (I.e. “All” warnings). |