Rationale for no goto, continue but allow break

[niall]

I know this should have been brought up before, but in reviewing MISRA-2 this passed me by.
Being pedantic, why has the rule on break (14.6) been relaxed and not 14.5 (or 14.4)?
A break in a loop is just a goto!
I have no problem with it, it just smacks of inconsistency.

[Gavin McCall]

MISRA C Steering Team - 2/11/2005

In writing MISRA-C:2004, the use of a loop with two exits was considered acceptable.

One is available for normal exit, and the second for exceptional exits, using the \"break\" statement.

This jump is well constrained unlike \"goto\" which can allow jumps anywhere.

[misra-c]

MISRA C Steering Team - 2/11/2005

In writing MISRA-C:2004, the use of a loop with two exits was considered acceptable.

One is available for normal exit, and the second for exceptional exits, using the \"break\" statement.

This jump is well constrained unlike \"goto\" which can allow jumps anywhere.

Re-posted under offical user name only.

[sparker]

I know this should have been brought up before, but in reviewing MISRA-2 this passed me by.
Being pedantic, why has the rule on break (14.6) been relaxed and not 14.5 (or 14.4)?
A break in a loop is just a goto!
I have no problem with it, it just smacks of inconsistency.

I seem to recall griping about this at the first MISRA-C forum thing (many years ago). I thought that disallowing break within a loop was extreme and that the alternatives (largely loop control variables) are ugly and error prone; others (Peter Amey I suspect) pointed out that it was a stronger restriction than that in SPARK Ada (which allows, if I remember correctly, a break from a top level conditional within a loop). This may have influenced the decision.

As an aside, we could, of course, rewrite all control flow in terms of if/goto (compilers do it all the time) -- there isn't anything special about break. (See http://david.tribble.com/text/goto.html for interesting discussion on modern goto thinking.)