3 ms·

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

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

by dkhenry 14y ago

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.