Incidently lint was invented exactly because of improving the way C was, they decided it was better in the UNIX tradition to add yet another tool, which those millions rather not use.

Note that gcc and clang will warn you about fallthrough statements i you use -Wextra and that you have to either have insert a /fallthrough/ comment to make your intent clear.

Pity the (wo)man who does not use -Wall -Wextra for (s)he is truly mistaken

Clang actually doesn't warn in -Wextra:

https://www.godbolt.org/z/99ejvY9Pc

It requires the separate option -Wimplicit-fallthrough:

https://www.godbolt.org/z/GP576zG9h

(which tbh sounds like a bug, because usually Clang tries to emulate GCC behaviour)

C++17 now has standardized the [[fallthrough]] attribute:

https://en.cppreference.com/w/cpp/language/attributes/fallth...

(For backwards compatibility, it still must fallthrough with or without the attribute; the attribute just signals programmer intention and silences the warning.)

That (also) came from BCPL. (BCPL had a separate `endcase` statement; `break` applied only to loops. It also had `docase ‹expr›`, which is the equivalent of a loop `continue`, re-entering the `swtichon`.)

As I recall, B was modelled on an early BCPL compiler that didn't have an ENDCASE statement, hence the overloading of break for exiting a switch block.

You don't really need a linter. It's just a warning setting, see:

  -Wimplicit-fallthrough

From the compiler docs. It's just not a problem. If you waste time once and learn about warning options in the compiler you will be better off anyway. It's like with assignment being an expression panic - something that maybe bites you once and then you learn to read the compiler warnings and it never causes problems again. If you don't want to read then there is:

  -Werror 

Available.

No separate linters needed, but details differ between compilers.

GCC has a warning in the '-Wextra' warning set, Clang requires the explicit option `-Wimplicit-fallthrough', MSVC is completely silent (apparently it's in the CppCoreCheck rules though).

This should really be in the default warning set with an annotation that the fallthrough is intended (unless the case-branch is completely empty).

> The worst offender is the quasi-obligatory "break" statement in "case" blocks.

This was (almost certainly) done to simplify the compiler. CASE in C is not actually a structured control construct despite its syntactic appearance, it's just a computed GOTO. This is what makes things like Duff's device [1] possible.

[1] https://en.wikipedia.org/wiki/Duff%27s_device

I didn't know about Duff's device, which looks pretty interesting! Thanks for sharing

Sure, but just for the record IMHO duffs device is an abomination and an illustration of how badly broken C is. No one should ever actually use it.

I think I've come across Duff's device in Go internals for zero-ing memory.

Yeah, I remember having my mind blown when I first discovered Duff's Device.

My mental picture of what C-compilers are up to turned out to be a lot more sophisticated than reality.

But having written a few Forth-interpreters, it makes total sense to me. Treating the input as a mostly unstructured stream of tokens is very convenient.

I think computed-GOTO is easier to understand and more flexible than Duff's device, but computed-GOTO is not part of the C standard. It is sometimes available as a non-portable extension, e.g. https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html. Anyone know why it is not included in C?

Computed go to was not quite an accurate description. I probably should have said “dispatch table” instead.

What I find inconvenient is that a case body can be made with or without curly brackets. I'd rather have they were mandatory, like when an if statement aplies to more than one statement. The downside is that you need more indentation to have a logical curly brackets structure.

Choices/options for the same result, tend to make code less readable.

break; has a special color value in my IDE’s. Just so it’s loud. Strictly because of what you describe.

That's not a bad idea, but it still leaves you having to notice when the loudness is silently missing. (It's easier when it's loud, but still...)

In D, if there are no intervening statements:

    case 1:
    case 2:
       ... code ...

the fallthrough is allowed.

    case 1:
        ... code ...
    case 2:
        ... code ...

Is an error. But `goto case` can be used:

    case 1:
        ... code ...
        goto case;
    case 2:
        ... code ...

which makes it clear. No new keywords are needed. C could adopt this easily.