4 ms·

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 ..

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
- primitur 14y ago
  You've misunderstood my point in order to make your argument, I think. I didn't say that someone won't "know if this branch is tested because it uses an if" - obviously, they won't get certification if they don't know. But the point is, they will have to write MORE tests to prove this knowledge. In other words, BREAK the conditions of the if statement in order to test - so simulate a full bitrot scenario on the conditional-branch. We've actually had to write tests to do this, but then been able to rewrite the code to use goto, effectively and without any of the disadvantages you mention - in fact, reducing the cyclomatic complexity of the entire system. This is a good thing. Bit rot, not common? Well, if you're really safety-critical trained, you would simply never say that, in my opinion. FYI, my software is running the trains in 38 countries around the world, track-side in thousands of locations. Replace the hardware? Forget it: that hardware will be there, in torturous environments, for years upon years and therefore: must be SIL4 rated. There is no exchange of hardware after a crash.
  - dkhenry 14y ago
    All hardware gets replaced. If your not establishing a planned maintenance schedule for your hardware then your asking for failures. That's why companies give MTBF. The PLC's I have worked with have shelf life's of 30+ years , but we still have planned maintenance periods where we examine and replace and worn components and we have a tech refresh period designed to prevent anything from ever reaching a point of failure. In addition every type of media I know of to store computer programs will physically degrade before suffering "bit rot". Most of the industrial controllers I have used ( everything aside from the most basic of uControllers ) have refresh cycles for their programs preventing this supposed bit rot by refreshing the signal on the media on a very regular basis. FYI trains stations aren't torturous at all. I have put stuff on weather decks of naval warships now thats torturous.
jstanley 14y ago
Regardless of whether an if statement or a goto is better, why is a goto preferable to a function call?
- DeepDuh 14y ago
  1) putting pure cleanup code into different functions is unwieldy. It doesn't make code readability, thus maintainability, better in any way, so why use it? 2) speed. sometimes, when it comes to optimizing hot loops, there is a point where one needs to manually inline code, in order to avoid potentially unnecessary scope cleanups. Ever looked at assembler? Seen how many instructions a typical function call causes? Of course, (1) is usually only relevant in systems programming and (2) is only relevant in HPC, where going that extra mile can actually save more than a few 100k$. Nothing the average programmer needs to worry about - however that's also one huge problem of that field: Lack of people with said know how.
  - jstanley 14y ago
    I accept both of those points. I was asking in the context of safety-critical systems. I see no advantages of goto over a function call.
    - primitur 14y ago
      A function call necessitates setting up the stack for the call, and returning from the call by popping values of the stack. To get 100% coverage, you'll have to test the call, test the broken call, test the stack being corrupted, and so on. This adds to the cyclomatic complexity of the TESTING required to certify that your software doesn't have/take any unknown paths during its lifetime while installed in highly hostile environments (heat, radiation, water, desert conditions, Antarctica, etc.)

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

primitur 14y ago
You've misunderstood my point in order to make your argument, I think. I didn't say that someone won't "know if this branch is tested because it uses an if" - obviously, they won't get certification if they don't know. But the point is, they will have to write MORE tests to prove this knowledge. In other words, BREAK the conditions of the if statement in order to test - so simulate a full bitrot scenario on the conditional-branch. We've actually had to write tests to do this, but then been able to rewrite the code to use goto, effectively and without any of the disadvantages you mention - in fact, reducing the cyclomatic complexity of the entire system. This is a good thing. Bit rot, not common? Well, if you're really safety-critical trained, you would simply never say that, in my opinion. FYI, my software is running the trains in 38 countries around the world, track-side in thousands of locations. Replace the hardware? Forget it: that hardware will be there, in torturous environments, for years upon years and therefore: must be SIL4 rated. There is no exchange of hardware after a crash.
- dkhenry 14y ago
  All hardware gets replaced. If your not establishing a planned maintenance schedule for your hardware then your asking for failures. That's why companies give MTBF. The PLC's I have worked with have shelf life's of 30+ years , but we still have planned maintenance periods where we examine and replace and worn components and we have a tech refresh period designed to prevent anything from ever reaching a point of failure. In addition every type of media I know of to store computer programs will physically degrade before suffering "bit rot". Most of the industrial controllers I have used ( everything aside from the most basic of uControllers ) have refresh cycles for their programs preventing this supposed bit rot by refreshing the signal on the media on a very regular basis. FYI trains stations aren't torturous at all. I have put stuff on weather decks of naval warships now thats torturous.

jstanley 14y ago

Regardless of whether an if statement or a goto is better, why is a goto preferable to a function call?

DeepDuh 14y ago
1) putting pure cleanup code into different functions is unwieldy. It doesn't make code readability, thus maintainability, better in any way, so why use it? 2) speed. sometimes, when it comes to optimizing hot loops, there is a point where one needs to manually inline code, in order to avoid potentially unnecessary scope cleanups. Ever looked at assembler? Seen how many instructions a typical function call causes? Of course, (1) is usually only relevant in systems programming and (2) is only relevant in HPC, where going that extra mile can actually save more than a few 100k$. Nothing the average programmer needs to worry about - however that's also one huge problem of that field: Lack of people with said know how.
- jstanley 14y ago
  I accept both of those points. I was asking in the context of safety-critical systems. I see no advantages of goto over a function call.
  - primitur 14y ago
    A function call necessitates setting up the stack for the call, and returning from the call by popping values of the stack. To get 100% coverage, you'll have to test the call, test the broken call, test the stack being corrupted, and so on. This adds to the cyclomatic complexity of the TESTING required to certify that your software doesn't have/take any unknown paths during its lifetime while installed in highly hostile environments (heat, radiation, water, desert conditions, Antarctica, etc.)