Hacker News Reader

Comment by primitur | Hacker News Reader

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

View on HN

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.

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

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

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.

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.

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

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.

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.

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

Question: are you talking about code written in assembly language, or are we talking about higher level languages?

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.

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.

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.

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.

There certainly are languages that can provably ensure all cases are handled.

Have a look at ATS.

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.

Reply on news.ycombinator.com