On 16.01.2024 16:45, David Brown wrote:

Default fallthrough switch behaviour is different in that it is
potentially counter-productive and dangerous. As someone who uses good tools, and knows how to use them, it is not an issue for my own code -
but it can be a source of error in other people's code.

It can also just be a useful code pattern, as in Duff's Device.

I can imagine bugs in real, released code as a result of default
fallthrough in switches. [...]

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/01/2024 06:01, Janis Papanagnou wrote:

On 16.01.2024 16:45, David Brown wrote:

Default fallthrough switch behaviour is different in that it is
potentially counter-productive and dangerous. As someone who uses good
tools, and knows how to use them, it is not an issue for my own code -
but it can be a source of error in other people's code.

It can also just be a useful code pattern, as in Duff's Device.

No.

Fallthrough switch behaviour can be useful (and not in the monstrosity
that is Duff's Device, but mostly when you have multiple switch cases
that are handled by the same code).

/Default/ fallthrough switch behaviour is not good.

If you want fallthrough, label it with "[[fallthrough]]", or a comment
or other technique recognised by your tools and by your fellow programmers.

I can imagine bugs in real, released code as a result of default
fallthrough in switches. [...]

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17.01.2024 11:44, David Brown wrote:

On 17/01/2024 06:01, Janis Papanagnou wrote:

On 16.01.2024 16:45, David Brown wrote:

Default fallthrough switch behaviour is different in that it is
potentially counter-productive and dangerous. As someone who uses good
tools, and knows how to use them, it is not an issue for my own code -
but it can be a source of error in other people's code.

It can also just be a useful code pattern, as in Duff's Device.

No.

Fallthrough switch behaviour can be useful (and not in the monstrosity
that is Duff's Device, but mostly when you have multiple switch cases
that are handled by the same code).

I don't think that multiple case-labels are the interesting part;
they are just a bulky syntactic way to collect items - compare
that [syntactically] with case statements in other languages (e.g.
in Pascal). In many (most? all?) C based language, OTOH, you have
to identify every single value by a 'case' keyword, and you also
_have_ to use an explicit 'break' to not "fall through". The fall
through logic is interesting (sort of) if you want to "re-use"
code from other case labels. - Not that this feature would make
any program easier to maintain. (I would avoid that.)

The use of "code patterns" (like the mentioned Duff's Device) is
often an indication to support features that the language doesn't
natively support; I see them often (for example) in Awk. It's not
something I would strive for in cleanly written software. But it's
usable as an idiomatic expression for a subset of (specific) tasks.
YMMV.

/Default/ fallthrough switch behaviour is not good.

But this is the case with C-based languages; we have to accept it,
and, again _idiomatically_, write an explicit 'break' after every
'case' statement sequence.

(But we're here in a C newsgroup and complaints make no sense.)

If you want fallthrough, label it with "[[fallthrough]]", or a comment
or other technique recognised by your tools and by your fellow programmers.

This is indeed what I do on these rare conditions where I use it.

In other languages it's even more hidden (than a missing 'break');
Kornshell for example uses ;; for a "break" logic and ;& for the
(fall-through) "continue" logic in its 'case' statements. (And
'break [N]' and 'continue [N]' have another logical context (used
only in loops).

I can imagine bugs in real, released code as a result of default
fallthrough in switches. [...]

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/01/2024 12:21, Janis Papanagnou wrote:

On 17.01.2024 11:44, David Brown wrote:

On 17/01/2024 06:01, Janis Papanagnou wrote:

On 16.01.2024 16:45, David Brown wrote:

Default fallthrough switch behaviour is different in that it is
potentially counter-productive and dangerous. As someone who uses good >>>> tools, and knows how to use them, it is not an issue for my own code - >>>> but it can be a source of error in other people's code.

It can also just be a useful code pattern, as in Duff's Device.

No.

Fallthrough switch behaviour can be useful (and not in the monstrosity
that is Duff's Device, but mostly when you have multiple switch cases
that are handled by the same code).

I don't think that multiple case-labels are the interesting part;
they are just a bulky syntactic way to collect items - compare
that [syntactically] with case statements in other languages (e.g.
in Pascal). In many (most? all?) C based language, OTOH, you have
to identify every single value by a 'case' keyword, and you also
_have_ to use an explicit 'break' to not "fall through". The fall
through logic is interesting (sort of) if you want to "re-use"
code from other case labels. - Not that this feature would make
any program easier to maintain. (I would avoid that.)

The use of "code patterns" (like the mentioned Duff's Device) is
often an indication to support features that the language doesn't
natively support; I see them often (for example) in Awk. It's not
something I would strive for in cleanly written software. But it's
usable as an idiomatic expression for a subset of (specific) tasks.
YMMV.

Of course different people have different styles and needs. For my own
use, I vastly prefer to write the code as cleanly as possible and let
the optimiser generate code roughly like Duff's Device if that's the
most efficient. But other people have other requirements and preferences.

/Default/ fallthrough switch behaviour is not good.

But this is the case with C-based languages; we have to accept it,
and, again _idiomatically_, write an explicit 'break' after every
'case' statement sequence.

I accept it, but dislike it and make sure my tools will warn me if there
is unintentional default fallthrough.

(But we're here in a C newsgroup and complaints make no sense.)

Hey - without complaints, this newsgroup would be almost empty :-)

If you want fallthrough, label it with "[[fallthrough]]", or a comment
or other technique recognised by your tools and by your fellow programmers.

This is indeed what I do on these rare conditions where I use it.

In other languages it's even more hidden (than a missing 'break');
Kornshell for example uses ;; for a "break" logic and ;& for the (fall-through) "continue" logic in its 'case' statements. (And
'break [N]' and 'continue [N]' have another logical context (used
only in loops).

I can imagine bugs in real, released code as a result of default
fallthrough in switches. [...]

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17.01.2024 14:10, David Brown wrote:

Of course different people have different styles and needs. For my own
use, I vastly prefer to write the code as cleanly as possible and let
the optimiser generate code roughly like Duff's Device if that's the
most efficient. [...]

Of course. And I agree. My comment might have sounded more positive
than these tricks deserve. I just wanted to emphasize that by using
code patterns we can often circumvent language deficiencies. And
that C can anyway hardly be considered a cleanly designed language.
(*duck* :-)

(But we're here in a C newsgroup and complaints make no sense.)

Hey - without complaints, this newsgroup would be almost empty :-)

Well, here our expectations (maybe) differ. ;-)

Frankly, this thread is pathological! (I've never seen such before.)

I feel really bad about opening that subject (which had already been
answered after a dozen replies!) - and then it became off-topic, and
gigantic, with what, 350 posts?, and a lot of them like tapeworms,
and all the repetitions, and whatnot.

But I'm new in this NG, so I'll better silence for now...

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)