Hacker News Reader

Comment by tralarpa | Hacker News Reader

> the generalized "for" of C was a mistake, because it complicates the frequent use cases in order to simplify seldom encountered use cases

The worst offender is the quasi-obligatory "break" statement in "case" blocks. Fall-through cases are useful for things like lexers but probably not needed in 99.999% of other programs. I wonder how many millions of (wo)man hours have been wasted on debugging missing breaks. (yes, I know that linters exist)

View on HN

> 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.

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. All those /* fallthrough */ comments and warnings and compiler switches will just go away.

Oh, and obviously:

    case 1:
        ... code ...
        goto default;
    default:
        ... code ...

also works!

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 `switchon`.)

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).

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.)

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.

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...)

Reply on news.ycombinator.com