problems/risks due to programming language

[Richard O'keefe]

There's been a lot of discussion about the "switch" statement.
What people seem to have missed is that there are TWO debatable
features about C's "break" statement, one of which was NOT
present in C's grandfather BCPL.

One debatable feature about "break" is that it is not automatically
implied at the end of every case.  That means that you can leave it
out when you didn't mean to.  There are several ways of dealing
with the problem.  One would be to use an editor macro which does
	insert "case :"
	create new line indented one more step
	insert "break;"
	move back to just before the ":"
That would make it easy to terminate your cases properly.
Another approach would be to add an option to "lint" to warn about
missing "breaks;", the warning would be produced whenever one case
fell through into the next and could be suppressed by a /*FALLTHROUGH*/
comment.  (Never mind GCC, what _I_ want is a GLINT.)

But from the rather garbled problem description which triggered off
this thread, that wasn't the problem.  The problem is that C uses
"break" for two very different things:  finishing a case in a switch,
and exiting from a loop.  I've lost count of the number of times I have
had to add a label, use a 'return', or restructure my program simply
because the place where I wanted to put a loop 'break' was inside a
switch.  The real pity of it is that BCPL used two different keywords
for these two different operations.  The one for finishing a case was
ENDCASE.  C inherited most of its control structures from BCPL.  I
have long wondered why C's (or B's, whichever) designers went out of
their way to introduce this problem.