|
|
Subscribe / Log in / New account

An end to implicit fall-throughs in the kernel

An end to implicit fall-throughs in the kernel

Posted Aug 5, 2019 14:16 UTC (Mon) by rweikusat2 (subscriber, #117920)
In reply to: An end to implicit fall-throughs in the kernel by mpr22
Parent article: An end to implicit fall-throughs in the kernel

Try reading the C language definition. The relevant part would seem to be

A switch statement causes control to jump to, into, or past the statement that is the switch body, depending on the value of a controlling expression, and on the presence of a default label and the values of any case labels on or in the switch body. A case or default label is accessible only within the closest enclosing switch statement.
It's just nonsense to refer to the sequential execution of sequence of statemens as "implicit fallthrough" when thinking of C control structures.


to post comments

An end to implicit fall-throughs in the kernel

Posted Aug 5, 2019 14:53 UTC (Mon) by karkhaz (subscriber, #99844) [Link] (3 responses)

Nobody learns C by reading the standard. People instead use the same mental model for switch statements that they do for if statements, i.e., they are two different ways of writing a conditional expression.

Since you only ever take (at most) one branch of an if statement, it makes sense that programmers expect the same behaviour from the cases of a switch statement. Unlearning this mental model is difficult because people rarely use goto statements and commonly use if statements. So for most people, switch statements are a syntactic sugar for if statements (removing the need to explicitly test the value of the expression for each branch), rather than being sugar for goto statements.

An end to implicit fall-throughs in the kernel

Posted Aug 5, 2019 15:50 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

I would suspect assumptions based on how multiway conditionals work in other languages, eg, Pascal or the Bourne shell language, here. Such a construct can be emulated in C by combining switch and break but it doesn't have one. OTOH, a C switch can be used to do things which can't be done with a multiway conditional, eg,
switch ((uintptr_t)p & 3) {
case 3:
    *p++ = c;

case 2:
    *p++ = c;

case 1:
    *p++ = c;
}
to align a pointer while storing some values (I'm aware that this is not standardized C). One could argue that such cases are rare and that a proper multiway conditional had been a better idea.

An end to implicit fall-throughs in the kernel

Posted Aug 5, 2019 18:40 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link]

The pseudo-C-example has the case 3 and case 1 cases inverted :-).

An end to implicit fall-throughs in the kernel

Posted Aug 8, 2019 3:03 UTC (Thu) by Paf (subscriber, #91811) [Link]

In C (not the generated assembly, which isn’t the same thing) a switch statement isn’t *just* a series of jumps. What’s the “break” for if it’s just a set of gotos? It’s a *switch* or *case* statement, and it does indeed have fall through from one condition to the next. It gets to conditions using labels in a manner basically the same as goto, but that’s an implementation detail. Switch/case have a higher level meaning, independent of the generated assembly or the use of labels.

What behavior would constitute “fall through” in your view? Fall through simply means proceeding from one case to the next instead of breaking out. C does so unless told otherwise, so it’s implicit. The fact that the generated assembly is just a set of jumps to labels has no bearing on this higher level language observation, which is comparing C to other languages on the behavior of the switch statement.

Basically you’re saying C doesn’t have fall through at all, because a switch statement is just a set of gotos so we should stop talking about this. That’s certainly *a* perspective. It’s not an interesting or useful one and those of us who want to have a name for this behavior that refers to the higher level language are just going to keep talking about falling through cases.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds