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.
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.
Quote: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.
niall Wrote: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.)