Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Taming The Switch-Statement Date: Tue, 13 Oct 2026 06:55:06 -0700 Organization: A noiseless patient Spider Lines: 72 Message-ID: <864iepiu2t.fsf@linuxsc.com> References: <119qf6l$2rmg3$1@dont-email.me> <20261010220212.000063fd@yahoo.com> <11ae56o$cjlv$4@dont-email.me> <20261010230355.00005189@yahoo.com> <864iesjx6e.fsf@linuxsc.com> <11afvqt$2kloc$1@dont-email.me> <11ag37o$2ln0a$1@dont-email.me> <11agbsh$2pbk7$1@dont-email.me> <11aggaq$2qqh9$1@dont-email.me> <11agils$2s3tg$1@dont-email.me> <11agv1t$30q22$2@kst.eternal-september.org> <20261012220256.00003d07@yahoo.com> <11ajb95$3t8jj$1@dont-email.me> <20261012223144.00000f95@yahoo.com> <11akm9q$29tpl$1@paganini.bofh.team> <11al05t$4o6l$1@dont-email.me> <11al10u$eiet$1@dont-email.me> <11al3jt$fig1$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 13 Oct 2026 13:55:07 +0000 (UTC) Injection-Info: dont-email.me; logging-data="617504"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181SCAcYBxoO4cZuG6CmZg2xsWUhWVakT0="; posting-host="065d2eee2cd7241f5f1e4f229d8fc207" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:bCO3cW2xebd5f3PO28jG7E8g0KU= sha1:Yrjem2Usa2+iOruo0dHicXcnU44= sha256:FzzxQK2bU3pyo9eB3VUllM6p4DkdJvY/h9Sd2TxMoSU= sha1:VH+8yTAm7YTkSGXohmC1zIEaU9k= sha256:8EgtdbsT78vpvJGhO9K4yArLO6QB2z3wrsE/L8QlLUQ= Xref: csiph.com comp.lang.c:403102 Richard Harnden writes: > On 13/10/2026 11:26, bart wrote: > >> On 13/10/2026 11:12, Janis Papanagnou wrote: >> >>> On 2026-10-13 09:23, Waldek Hebisch wrote: >>> >>>> [...] >>>> So what those counts indicate: majority of loops is simple, >>>> that is have no early exit. Vast majority of early exits is >>>> done via 'return'. "Interesting" loop control is relatively >>>> rare. Checking which 'break'-s are within equivalent of >>>> 'switch' would require manual inspection and that would be too >>>> much work. But reasonable guestimate to that there are tens >>>> such uses. In a sense that is common, that is significantly >>>> more than one case. If my guestimate is correct, then this may >>>> be nontrivial fraction of all uses of 'break'. OTOH that is >>>> tiny fraction of all loops. >>> >>> From my (personal) perspective, I commonly have two types of >>> such specific constructs; a very common one is iterating over >>> options >>> >>> while ((opt = getopts (...)) != -1) >>> switch (opt) ... >>> >>> where, of course, and quite naturally, always the whole loop >>> is iterated, with no early leaving. And the second common loop >>> type is those where the switched data comes from the function >>> as well >>> >>> while ((token = parse (...)) != END_TOKEN) >>> switch (token) ... >>> >>> I'm aware that one might wants to pass and process two values >>> from a function (as I interpreted one of bart's recent code >>> fragments), but then, and if it would be "impossible" to avoid >>> that pattern, I'd just add a condition >>> >>> int leaving = 0; >>> while ((token = parse (&token...)) != ERROR && !leaving) >>> switch (token) >>> case END_TOKEN: leaving = 1; ... >>> >>> that's really trivial and straightforward, and it's beyond me >>> why anyone (but bart, of course) would see a problem here. >> >> Because it's a hack. But if this is acceptable, then why does C >> even have loop-break? Since there is always some workaround (or >> 'writing code' as David Brown puts it.) >> >> What would be the consequences of C not having it: would they be >> positive or negative overall? >> >> Now apply the same analysis to a hypothetical loop-break that >> works inside switch. > > You could argue that 'break' is just syntactical sugar for > 'goto label'. > > If you want to break out of multiple levels, then just use a > goto. > > Some people have a pathological hatred of 'goto', sure. > There's alway a way to avoid goto, if that's what you really > want. That the code, and it's intention, is clear is the > important thing. > > I really don't see the issue. It's a style thing at most. Very pragmatic. This pretty much matches my sentiments.