There might be a situation when you may require or want to get the same result for the two or may be more cases then you dont need a break. Something like this:
switch (x)
{
case 1:
case 2:
case 3:
some task
break;
deafult:
do some other task
break;
}
The above code is eventually the same as:
switch (x) {
case 0: // The case 1 code is shared here
case 1:
// code
goto case 2;
case 2:
//some code here
goto default;
default:
//some other code
break;
}
From the K&R
Falling through from one case to another is not robust, being prone to
disintegration when the program is modified. With the exception of
multiple labels for a single computation, fall-throughs should be used
sparingly, and commented.
As a matter of good form, put a break after the last case (the default
here) even though it's logically unnecessary. Some day when another
case gets added at the end, this bit of defensive programming will
save you.
As puppy has mentioned the bahaviour was inherent from the C language, so a quote from the book Expert C Programming
We analyzed the Sun C compiler sources
to see how often the default fall
through was used. The Sun ANSI C
compiler front end has 244 switch
statements, each of which has an
average of seven cases. Fall through
occurs in just 3% of all these cases.
In other words, the normal switch
behavior is wrong 97% of the time.
It's not just in a compiler - on the
contrary, where fall through was used
in this analysis it was often for
situations that occur more frequently
in a compiler than in other software,
for instance, when compiling operators
that can have either one or two
operands:
switch (operator->num_of_operands) {
case 2: process_operand( operator->operand_2);
/* FALLTHRU */
case 1: process_operand( operator->operand_1);
break;
}
Case fall through is so widely
recognized as a defect that there's
even a special comment convention,
shown above, that tells lint "this is
really one of those 3% of cases where
fall through was desired."