Quotes of the week

Posted Feb 7, 2013 13:08 UTC (Thu) by khim (subscriber, #9252) [Link]

The big question is: since when it became fashionable to use Google-found links related to the phrase torn out of context without ever reading the articles which are pointed to by links?

Note that the link you've shown includes the following sentence: I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs; but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way.

Not only Dijkstra notices that some additional clauses can be needed to write better programs (besides the usual if and while) - he offers one example where they may be needed (e.g. abortion clauses)!

C does not have such abortion clauses and they are emulated in kernel code with a goto statements, so... what's your problem?

P.S. I really, really hate anti-goto fanatics who entirely forget about the reason behind the infamous Go To Statement Considered Harmful article and start mindless crusade against goto without ever trying to understand just why Dijkstra felt that unbridled use of the go to is problematic and what he tried to achieve by trying to reduce it's use.

Posted Feb 8, 2013 3:07 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Before going off in just another anti-GOTO rant, read Knuth's classic "Structured programming with goto statements". There are very, very few absolutes. There are cases (like most of the uses in the kernel) where a goto makes for more readable, easier to debug, and moreover more efficient, code than any "structured alternatives".

Posted Feb 11, 2013 17:58 UTC (Mon) by dgm (subscriber, #49227) [Link]

As the article where the quote comes from points, there are alternatives to the use of goto. I too was told to avoid using it, just to later rediscover that it was useful sometimes.

But what I wished to point out is that nesting if statements (the alternative pointed out by John Regehr) is not the only way to avoid using goto. Let me show you a couple of additional ones:

First we should make a canonical example of the accepted use of goto in kernel code:

int do_init()
{
  if (!init_step_1())
    goto out1;
  if (!init_step_2())
    goto out2;
  if (!init_step_3())
    goto out3;
  return 0;
out3:
  undo_step_2();
out2:
  undo_step_1();
out1:
  return -1;
}

And the if-ladder alternative would be:

if (init_step_1()) 
  if (init_step_2())
    if (init_step_3())
      return 0;
    undo_step_2();
  undo_step_1();
return -1;     

This looks shorter, but remember we are talking about nesting 12 levels deep here.

Now, the first alternative would be to use a separate function to perform each step, like this:

int do_init()
{
  if (init_step_1())
    if (try_init_2())
      return 0;
    else
      undo_step_1();
  return -1;
}

int try_init_2()
{
  if (init_step_2())
    if (init_step_3())
      return 1;
    else
      undo_step_2();
  return 0;
}

In that scheme, each function takes responsibility for doing/undoing some step (except the last one). That keeps set-up and cleanup code close together, making it more readable. The downside is that the code is now a bit longer, pollute the namespace, use more stack and are a bit slower. All this, though can be solved by inlining the functions or using static.

And the final option is to use expression statements:

int do_init()
{
  return (init_step_1() &&
    (init_step_2() &&
    (init_step_3()
    || (undo_step_2(), 0))
    || (undo_step_1(), 0))) ? 0 : -1;
}

Isn't it pretty?