Yeah, I was quite underwhelmed by these complaints. Several I don't even think are correct:

#9:

    #define DEVICE_COUNT 4 
    uint8 *szDevNames[DEVICE_COUNT] = {
        "SelectSet 5000",
        "SelectSet 7000"}; /* table has two entries of junk */

"junk" is incorrect. It has 2 entries of zeros, and that is something that you can count on. If you really don't like that (and I generally do like that) you can turn on gcc's -Wextra which will warn about it.

#17 complains about char's being signed but really it should be complaining about chars' signedness not being spec-ed (really--it's implementation dependent whether plain "char" is signed or unsigned. If you really care, use the "signed" keyword. But really, complaining about overflow? Strange.

I think the problem is that a lot of languages encourage you to do something clever, whereas C actively and relentlessly punishes you for being clever.

My favorite example is from #19, which is something that javascript programmers do all of the time.

  int value = a && b && fn(a->x,b->x);

(The author goes on to complain about how value you obviously be whatever fn(a->x, b->x) returns).

In javascript, that's actually good practice (I guess, I had a mentor once who encouraged it, but I never really bought into it). To a C programmer though, that just looks gross. (Or at least to me, and I like to pretend to be a C programmer).

(the author goes on to complain about how the value ought to be whatever fn(a->x,b->x) returns)*

That was bad.

Funny that you mention it. JavaScript "the bad parts" is a serious contender in the bad language arena.

Agreed. Most of these are beginner traps, raise compiler warnings, are very obscure, and/or are simple to avoid if simple conventions are followed.