| ??? 08/19/09 14:45 Read: times |
#168397 - Way easier to analyse non-goto code Responding to: ???'s previous message |
Richard Erlacher said:
I've never encountered a memory leak in my ASM programming, and, with my preference for table-driven dispatch processes, I have little trouble tracking where things go under which circumstances. HLL's can, but don't necessarily, generate memory leaks because they use dynamic memory allocation which students are taught to use and otherwise essentially ignore, as an automatic feature. Without it, you don't see memory leaks. Did you not read what I wrote? Let me repeat myself: "if we ignore memory leaks etc that should not be applicable for most embedded systems". I don't expect people to need help tracking normal dynamic memory allocations (malloc() or new) in most embedded systems. If an embedded application do have problem with leaks, it is probably an application with threading and/or TCP or similar, where it may leak messages or TCP buffers or similar. These leaks can't be detected by normal memory allocation trackers, but a number of analysis tools can learn that OpenXX() should have matching CloseXX(). This analysis helps with a number of other situations too, where you have function call pairs that must be matched. Richard said:
In ASM, you don't easily lose track of numeric value range, since you have to provide a place for each value, into which it fits. Same thing with C. But the problem isn't really that you have a big enough variable to store a value. You have more issues. May you add two numbers and get a sum that overflows - possibly becoming negative? May a multiplication overflow? The analysis tools may track min-max values for multiple input parameters and perform full range checking of intermediate results. A mixup of unsigned/signed may be catched - this is extremely hard to catch in assembler. Richard said:
Unreachable code could be a problem, but I've never encountered it. I doubt HLL helps much with that. The problem is that you do not know if you have unreachable code until you finds and fixes it. And then it isn't unreachable anymore. C helps a lot when looking for unreachable code. Next thing is that when developing non-trivial code, you may have code looking like:
state = <complex evaluation>;
switch (state) {
case 0:
...
break;
case 1:
...
break;
...
case 15:
...
break;
default:
...
}
A good analyzer may figure out that state 13 and 15 may never be reached, because your <complex evaluation> may never produce the values 13 and 15. When just looking at the code, this will be impossible to notice. You will have to set up special tests with the full parameter range to find that the code coverage analysis shows that state 13 and 15 haven't been reached. Having a code analyzer find this using static analysis can save a lot of time. You may either save code space by being allowed to remove the two unreachable states. Or this may represent an error in <complex evaluation>. Richard said:
Type conversions aren't helped by 'C' any more than by ASM. You can stub your toe in either language type. Any language that doesn't allow you to stub your toe is unsuitable for general embedded programming. But the type declarations in C allows orders of magnitude better static analysis of the code. The normal C compiler can catch a huge number of problems that an assembler can't know anything about. An assembler thinks a byte is good for 0..255, while a C compiler can note that an enumerator only has values between 0 and 93. |
