Not just your C; C sucks in general. As a case in point, the C case statement is next-to-worthless, because fallthrough is not usually what you want. There are cases for it, but they're the exception rather than the rule. As a result, you end up needing to insert break statements at nearly every case, at which point you have barely less typing to do than with a nested if structure. Perl's elsif is actually an improvement on this.

The case statement in Inform (and even SELECT CASE in BASIC) is much more useful. If Perl ever gets a case, I hope the breaks are implied; otherwise I'll end up never using it.

Most of the cases where you want the fallthrough, it's because what you want is actually not a case statement, but some other structure. This is a perfect example. What it's doing is not really unique to each case; there are some minor variations, but what you really want is a loop.

Others have done efficient things (and I particularly like the pack solution), but I'll add my own translation, on the grounds that it is straightforward and legible...

{ my @shiftby = (0, 8, 16, 24, 0, 8, 16, 24, 8, 16, 24); 
  my $l;
  foreach $l (reverse 1 .. $len) {
     if    ($l>8) {   $c += $k[$l-1]<<$shiftby[$l]; }
     elsif ($l>4) {   $b += $k[$l-1]<<$shiftby[$l]; }
     else         {   $a += $k[$l-1]<<$shiftby[$l]; }
  }
}
[download]

I've reduced the number of += operations to three, and it is easy to see where the similarities and the differences are. The if/elsif/else makes it stand out when you are incrementing a different variable. (When I first looked at the thing, I thought the same variable was being incremented ten times.) Even better, it is clear how @k is being used; before, you had to look at each line and compare the index to @k with the case number, if you wanted to know if there were any deviations from the pattern; here it's clear there are none; $l-1 is always $l-1.

@shiftby could probably also be replaced with an arithmetic expression, but I'm not sure that would improve clarity.

 --jonadab

"Not just your C; C sucks in general. As a case in point, the C case statement is next-to-worthless, because fallthrough is not usually what you want. There are cases for it, but they're the exception rather than the rule. "

I have to disagree here, currently I'm writing quite a bit of C(C++ really) code and I have switches all over the place. I choose the switch construct BECAUSE I can have multiple values that should map to a block of code, so the fall-through is exactly why I use the switch statement. Just because the projects you have written code that does not use a construct does not say that no one uses it. If your code calls for a if/else tree then write one, when you find someplace that could use a switch, then go ahead and use it.

If I have only a few possible values, or it makes more sense then I use a if-else ladder.

I have hit quite a few places where I wished Perl had a case/switch statement.
That all being said I believe that you have to pick a language for the situation, right now we need high performance (simulation) software so we use C/C++. When we have non-speed critical code that can be more easily written in Perl, then that is the language we use. Remember, Perl was written in C, I'm not saying that makes it better, just useful. :)

I can handle people's opinions, but coming out and saying "Language X sucks" is a little harsh.

I choose the switch construct BECAUSE I can have multiple values that should map to a block of code

Other languages implement that by means other than fallthrough. If you were familiar with the way Inform (or even BASIC) does this, you would understand. Here is an oversimplified short example...

Object fireplace "fireplace" livingroom
  with name 'fireplace' 'fire' 'place',
       ! Really I would use a stock idiom parse_name
       ! routine to only accept fire as a modifier for
       ! place, but for the sake of this example we'll
       ! simplify.
       before [;
      Receive:
        if (self has lit) {
             switch (noun)
                 {
                       water_baloon:  "The baloon pops, and the fire
                             hisses and crackles, but the
                            blaze continues.";
            deed, certificate:
              remove noun;
              "The paper darkens, curls, and finally is
                consumed.  I hope you don't need ",
               (The) noun, " any more.";
            ! Cases for other objects here...
                       default:
              remove noun;
              print_ret (The) noun, " bursts into flame.";
             }
        } else { rfalse; }
      ! Rules for other actions here...
       ],
       ! other properties here...
   has scenery;
[download]

Comma-separated lists are just one way to allow multiple values. BASIC has case conditions like IS < and IS >. If Perl had switch/case, I would expect it to allow a wide variety of syntax for complete flexibility, so that for example you could switch on a variable that contains a reference, and have one case for any object that inherits from a particular class, for example, or a case for any number evenly divisible by two. Because stuff in Perl is flexible like that. With sufficient flexibility, the only reason you would ever want fallthrough would be if you wanted multiple cases to apply (potentially) in the same case, in which case the switch/case statement isn't really what you want, but a series of conditionals.

"Language X sucks" is a little harsh.

It is harsh, but it is a harsh reality that thirty-year-old problems which should have been resolved once and for all fifteen years ago (such as memory leaks and segmentation faults and buffer overruns) are still being found (and constantly) in production code of all sorts, precisely because the code is written in languages that don't protect the programmer from such basic and easy-to-make mistakes. The continued widespread use of such languages is absolutely throttling progress.

Yes, of course, at some point a lowlevel language (whether C, assembly, or whatever) has to be used to implement the basic building blocks upon which everything else is built, but I am firmly of the belief that way too much stuff is written in those lowlevel languages that does not need to be.

 --jonadab