5 ms·

One thing about replacing goto with if's: CODE COVERAGE, specifically: BRANCH COVERAGE. In situations where you have to prove 100% testing of all code, with fu

One thing about replacing goto with if's: CODE COVERAGE, specifically: BRANCH COVERAGE. In situations where you have to prove 100% testing of all code, with full branch coverage and absolutely no dead code, the goto is preferred. This is simply because it is a faster instruction that does not depend on any other values being "valid" in order to function. Why is that important? Bit-rot, folks. Like it or not, but we still have to ensure that the bit that is 1 is a 1 and not a 0, in this day and age - especially for safety-critical/life-dependent systems. The goto gives both full coverage capabilities (good for testing/certification) as well as providing one less path for radiation to be rotting bits. (And before we get into the NAND/ECC discussion, remember: this is for software certification requirements.. it doesn't matter how hard your hardware is, what matters is how hard your software is ..)

jstanley 14y ago
Firstly, I really don't follow your argument about code coverage. If you need to ensure that some unit of code is executed, why can't you make it a function and call it? Secondly, you have misunderstood what bit-rot is. Bit-rot is not cosmic rays flipping bits, it is a humorous term to describe what happens when code that used to work and has not been touched no longer works. EDIT: It seems Wikipedia disagrees with me on the second point. My apologies.
- primitur 14y ago
  Just FYI, I've been working in the safety-critical industry for decades. If I've misunderstood bit-rot, by now some of my colleagues would have .. corrected .. me. ;) Code Coverage means that you have demonstrated, beyond a doubt, that every single path in your code has been tested as functional and per-spec. An if statement requires (minimally) two things to happen (sometimes three, depending on the compiler/architecture): a compare of some values, then a branch. A goto requires one thing: jump. This then, reduces the cyclomatic complexity of your code path, and for coverage purposes is ideal because you're testing a simple jump, not a load, compare, branch. The use of if, in the example given, makes the testing complexity a lot higher - what if the if is broken somehow? (bit-rot: it still happens) In safety-critical, you have to test for that case, or else you don't get full coverage... (edit: s/cycolmetric/cyclomatic/ .. its a european thing..)
  - jacques_chester 14y ago
    Question: are you talking about code written in assembly language, or are we talking about higher level languages?
    - primitur 14y ago
      I'm talking about C code. For every if-branch, a test must be written to exercise the extreme case - the if failing, for some reason (bit-rot, radiation or heat or hardware-failure derived). In SIL4, its not enough to say: if (SAFE == something) {}; //dosomething.. .. and then just test the SAFE condition. You also have to test the condition where the constant SAFE gets bitrot, where the var something gets bitrot, &etc. Adding a test case for every potential bit-rotted branch of the conditional.
      - jacques_chester 14y ago
        So you prefer gotos to reduce the number of tests you have to write by artificially pushing down the number of countable code paths? I guess I see the reason. It seems to be connected to your development economics -- SLOCS required to reach a certified state. I'm glad that works for you. It still scares me.
  - dkhenry 14y ago
    As someone who has also done safety-critical software for a while allow me to interject this, your wrong. That is by far one of the _worse_ excuses for goto's I have ever seen. If anything they make full branch analysis more difficult then using conditionals. I have never sat down at a gap analysis and had someone say I don't know if this branch is tested because it uses an if statement instead of a naked goto. I have had people say does control ever get to this point since its at a label and we need to trace the code to find where the goto for the label is and then check the conditions for reaching the goto then check the validity of those conditionals at some non syntax designated point in the code. Also bit rot as you describe it is not a common occurrence and is something almost no one has to deal with. In fact most safety critical systems I deal with are designed to be replaced before we would ever need to worry about that. The more common use of bit rot is the second definition given in this[0] wikipedia article. Unused code which goto's can be a real headache for. 0. http://en.wikipedia.org/wiki/Bit_rot http://en.wikipedia.org/wiki/Bit_rot
jacques_chester 14y ago
I would prefer to rely on languages which can provably ensure all cases are handled than to rely on gotos to artificially improve a complexity metric. Really.
- primitur 14y ago
  Congratulations. You've just disqualified yourself from working on SIL-4 safety-critical software. There are no such languages that can provably ensure all cases are handled: there are only testing processes. Aversion to a technology is not the same as mastery of that technology. goto has its time, and place. Certifiably, so.
  - jacques_chester 14y ago
    I'm pretty sure we're on different pages here. Some languages can detect that there are unhandled cases in a selection statement (case, if etc). Those languages can enforce the handling of all cases, which to me at least renders the concept of a dangling case moot. I didn't say that you'd leave the cases untested. I'm just saying that in some languages the compiler is more of an ally than in others. I'll write to Galois and Praxis to tell them that they're disqualified from writing SIL-4 software.
  - Yttrill 14y ago
    There certainly are languages that can provably ensure all cases are handled. Have a look at ATS.

jstanley 14y ago

Firstly, I really don't follow your argument about code coverage. If you need to ensure that some unit of code is executed, why can't you make it a function and call it? Secondly, you have misunderstood what bit-rot is. Bit-rot is not cosmic rays flipping bits, it is a humorous term to describe what happens when code that used to work and has not been touched no longer works. EDIT: It seems Wikipedia disagrees with me on the second point. My apologies.

primitur 14y ago
Just FYI, I've been working in the safety-critical industry for decades. If I've misunderstood bit-rot, by now some of my colleagues would have .. corrected .. me. ;) Code Coverage means that you have demonstrated, beyond a doubt, that every single path in your code has been tested as functional and per-spec. An if statement requires (minimally) two things to happen (sometimes three, depending on the compiler/architecture): a compare of some values, then a branch. A goto requires one thing: jump. This then, reduces the cyclomatic complexity of your code path, and for coverage purposes is ideal because you're testing a simple jump, not a load, compare, branch. The use of if, in the example given, makes the testing complexity a lot higher - what if the if is broken somehow? (bit-rot: it still happens) In safety-critical, you have to test for that case, or else you don't get full coverage... (edit: s/cycolmetric/cyclomatic/ .. its a european thing..)
- jacques_chester 14y ago
  Question: are you talking about code written in assembly language, or are we talking about higher level languages?
  - primitur 14y ago
    I'm talking about C code. For every if-branch, a test must be written to exercise the extreme case - the if failing, for some reason (bit-rot, radiation or heat or hardware-failure derived). In SIL4, its not enough to say: if (SAFE == something) {}; //dosomething.. .. and then just test the SAFE condition. You also have to test the condition where the constant SAFE gets bitrot, where the var something gets bitrot, &etc. Adding a test case for every potential bit-rotted branch of the conditional.
    - jacques_chester 14y ago
      So you prefer gotos to reduce the number of tests you have to write by artificially pushing down the number of countable code paths? I guess I see the reason. It seems to be connected to your development economics -- SLOCS required to reach a certified state. I'm glad that works for you. It still scares me.
- dkhenry 14y ago
  As someone who has also done safety-critical software for a while allow me to interject this, your wrong. That is by far one of the _worse_ excuses for goto's I have ever seen. If anything they make full branch analysis more difficult then using conditionals. I have never sat down at a gap analysis and had someone say I don't know if this branch is tested because it uses an if statement instead of a naked goto. I have had people say does control ever get to this point since its at a label and we need to trace the code to find where the goto for the label is and then check the conditions for reaching the goto then check the validity of those conditionals at some non syntax designated point in the code. Also bit rot as you describe it is not a common occurrence and is something almost no one has to deal with. In fact most safety critical systems I deal with are designed to be replaced before we would ever need to worry about that. The more common use of bit rot is the second definition given in this[0] wikipedia article. Unused code which goto's can be a real headache for. 0. http://en.wikipedia.org/wiki/Bit_rot http://en.wikipedia.org/wiki/Bit_rot

jacques_chester 14y ago

I would prefer to rely on languages which can provably ensure all cases are handled than to rely on gotos to artificially improve a complexity metric. Really.

primitur 14y ago
Congratulations. You've just disqualified yourself from working on SIL-4 safety-critical software. There are no such languages that can provably ensure all cases are handled: there are only testing processes. Aversion to a technology is not the same as mastery of that technology. goto has its time, and place. Certifiably, so.
- jacques_chester 14y ago
  I'm pretty sure we're on different pages here. Some languages can detect that there are unhandled cases in a selection statement (case, if etc). Those languages can enforce the handling of all cases, which to me at least renders the concept of a dangling case moot. I didn't say that you'd leave the cases untested. I'm just saying that in some languages the compiler is more of an ally than in others. I'll write to Galois and Praxis to tell them that they're disqualified from writing SIL-4 software.
- Yttrill 14y ago
  There certainly are languages that can provably ensure all cases are handled. Have a look at ATS.