Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-11 22:12 +0000 |
| Articles | 20 on this page of 187 — 20 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 20:13 -0700 |
| Message-ID | <11aeusp$29hmu$2@kst.eternal-september.org> |
| In reply to | #402936 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-11 00:32, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 2026-10-10 22:03, Michael S wrote:
>>>> The cases where I want to break out of the loop from the switch in
>>>> the
>>>> body of the loop are very common.
>>>
>>> Ah, so you'd have needed something like Kornshell's 'break 2' to leave
>>> more than one level. - I suppose, you needed to used a 'goto' instead
>>> (and avoid the 'break' completely for those cases).
>> Something like that, sure, but please not that.
>> Specifying the *number* of levels to break or continue is IMHO
>> horrible. "break N" makes me count things so the computer doesn't
>> have to.
>
> I agree; that's what I also dislike about it.
>
> The point is the question what choices you have. The 'goto' is IMO
> the worst; because of semantic interdependencies that will regularly
> lead to semantical restrictions about its applicability (or placement
> of labels); various languages have various restrictions, it's just
> a mess! The 'break' is a "cheap" solution, but also very restricted.
> There's yet other variants with their own drawbacks; I won't even
> start with it.
>
>> There are proposals, and precedents in other languages, for *named*
>> loops, and I'd like to see that in a future C.
>
> One of the better possibilities, maybe; but still not satisfying for
> my (very subjective) taste.
>
> (Some language let you organize such things in completely other ways
> with no need for jumps of any sort.)
I find "break NAME;", where "NAME" is the name of an enclosing
construct, unambiguously better than "break N;", where N is the
number of levels to break out of.
The "break N" syntax is specified by POSIX. It's supported by ksh,
bash, dash, zsh, and probably other Bourne-based shells. (My guess
is that it originated in ksh.) My best guess is that because the
Bourne-like shells don't have gotos, they don't have labels, so
named loops would have required inventing those too. And admittedly
I suppose it's not too bad if it's no more than a couple of levels --
but it's still easy to, ahem, *break* if you reorganize the code.
There's a proposal for C2y to use goto labels as loop names, and a
competing one to define a new syntax like "for NAME (;;)" :
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-11 10:36 +0200 |
| Message-ID | <11afhr4$286ml$3@dont-email.me> |
| In reply to | #402938 |
On 2026-10-11 05:13, Keith Thompson wrote: > > I find "break NAME;", where "NAME" is the name of an enclosing > construct, unambiguously better than "break N;", where N is the > number of levels to break out of. Yes, sure. (Reminds me Pascal that supported for 'goto' just integer numbers [in the range 1..9999, IIRC] for jumps. - This is different from 'break N' but still also a bad design, IMO. - Not sure about later Pascal dialects, though. - Numbers for labels or levels, not nice.) > > The "break N" syntax is specified by POSIX. It's supported by ksh, > bash, dash, zsh, and probably other Bourne-based shells. (My guess > is that it originated in ksh.) My best guess is that because the > Bourne-like shells don't have gotos, they don't have labels, so > named loops would have required inventing those too. And admittedly > I suppose it's not too bad if it's no more than a couple of levels -- > but it's still easy to, ahem, *break* if you reorganize the code. Yes. - But while I don't find it (the N) elegant as concept it's in practice not that bad WRT "reorganization of code" since it's (as opposed to the 'goto' in other languages) a local construct. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-11 04:26 -0700 |
| Message-ID | <864iesjx6e.fsf@linuxsc.com> |
| In reply to | #402897 |
Michael S <already5chosen@yahoo.com> writes: > The cases where I want to break out of the loop from the switch in > the body of the loop are very common. That surprises me. Can you post a representative example (and ideally not overly long)?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 13:35 +0100 |
| Message-ID | <11afvqt$2kloc$1@dont-email.me> |
| In reply to | #402975 |
On 11/10/2026 12:26, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> The cases where I want to break out of the loop from the switch in
>> the body of the loop are very common.
>
> That surprises me. Can you post a representative example (and
> ideally not overly long)?
An example shouldn't be necessary. It is enough to know that loop-breaks
exist and are used.
Then, whether break works here:
while (cond) {
....
break;
....
}
shouldn't need to depend on whether that break happens to be inside a
switch statement.
Maybe it is within an if-else chain, but at some point it is refactored
into a switch statement. Now it no long does what is expected, and in
fact using break to quit the loop from inside switch becomes impossible.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-11 06:13 -0700 |
| Message-ID | <86zewkidn4.fsf@linuxsc.com> |
| In reply to | #402976 |
bart <bc@freeuk.com> writes: > On 11/10/2026 12:26, Tim Rentsch wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> The cases where I want to break out of the loop from the switch in >>> the body of the loop are very common. >> >> That surprises me. Can you post a representative example (and >> ideally not overly long)? > > An example shouldn't be necessary. It is enough to know that > loop-breaks exist and are used. It doesn't surprise me that they exist. What surprises me is that they are common, in code written by someone I consider a competent programmer. I don't care about what idiotic things are done by people who aren't competent programmers. You might want to think about the deeper meaning of that last sentence.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 14:51 +0100 |
| Message-ID | <11ag49c$2mal9$1@dont-email.me> |
| In reply to | #402979 |
On 11/10/2026 14:13, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> On 11/10/2026 12:26, Tim Rentsch wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >>>> The cases where I want to break out of the loop from the switch in >>>> the body of the loop are very common. >>> >>> That surprises me. Can you post a representative example (and >>> ideally not overly long)? >> >> An example shouldn't be necessary. It is enough to know that >> loop-breaks exist and are used. > > It doesn't surprise me that they exist. What surprises me is > that they are common, in code written by someone I consider a > competent programmer. I don't care about what idiotic things > are done by people who aren't competent programmers. > > You might want to think about the deeper meaning of that last > sentence. You might also think about the deeper meaning of my comments. You don't take a problem feature of a language design and brush it under the carpet. Then, when questioned, suggest that it's very rarely used. Or when it is used, that they shouldn't using it because everyone should be as clever as you at writing convoluted code: Look how clever I am, I've never needed to use '(loop) break' or 'goto' ever. (See, I even had to qualify that 'break' because 'switch' stupidly uses the same keyword.) And you're ignoring my point: inside a loop is a conditional break. But as the language is now, you must use if-else for that condition and not switch. That is a flaw.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-11 15:33 +0200 |
| Message-ID | <11ag37o$2ln0a$1@dont-email.me> |
| In reply to | #402976 |
On 11/10/2026 14:35, bart wrote:
> On 11/10/2026 12:26, Tim Rentsch wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> The cases where I want to break out of the loop from the switch in
>>> the body of the loop are very common.
>>
>> That surprises me. Can you post a representative example (and
>> ideally not overly long)?
>
>
> An example shouldn't be necessary. It is enough to know that loop-breaks
> exist and are used.
>
> Then, whether break works here:
>
> while (cond) {
> ....
> break;
> ....
> }
>
> shouldn't need to depend on whether that break happens to be inside a
> switch statement.
>
> Maybe it is within an if-else chain, but at some point it is refactored
> into a switch statement. Now it no long does what is expected, and in
> fact using break to quit the loop from inside switch becomes impossible.
>
The question was not about how it is possible to write a loop within a
switch and have a "break" statement inside the loop. The question was
about how often such code was written, and what makes it "very common"
for Michael. I am also curious to know if he finds the use of the same
"break" keyword makes the code more difficult to read, or increases the
risk of errors or misunderstandings.
It is quite obvious that it is easy to write code with loops + break
within a switch. It is equally obvious that it is easy to avoid such
constructs - there are always ways to avoid a "break" in a loop, and if
the code run within a switch case is complex, it is often practical to
refactor it into a separate function. But presumably Michael has
reasons not do do that.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-10-11 09:01 -0700 |
| Message-ID | <11agbsh$2pbk7$1@dont-email.me> |
| In reply to | #402980 |
On Sun 10/11/2026 6:33 AM, David Brown wrote:
>
> It is quite obvious that it is easy to write code with loops + break
> within a switch. It is equally obvious that it is easy to avoid such
> constructs - there are always ways to avoid a "break" in a loop, and if
> the code run within a switch case is complex, it is often practical to
> refactor it into a separate function. But presumably Michael has
> reasons not do do that.
Um... The common pattern for a "search"-style loop looks as follows
for (/* domain condition */)
{
...
if (/* search condition */)
break;
...
}
So, loops that terminate with `break` are the mainstay of every
competently written code. Moving the "early termination" condition into
the loop header (i.e. lumping the search condition with the domain
condition) is a very ugly anti-pattern in most cases. Moreover, majority
of the loops in an average C program are such "search"-style loops,
meaning that they do have an "early termination" condition.
Now, while overwhelming majority of my loops would use `if` to check the
"early termination", I can imagine that there sill be cases where
`switch` is applicable and more appropriate than an `if`. Yes, a
`switch` can always be replaced with an `if` ladder, but being _forced_
to do so by a language limitation doesn't look right.
And writing a separate function just to work around a weird language
limitation... that doesn't look right either.
--
Best regards,
Andrey
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-11 19:17 +0200 |
| Message-ID | <11aggaq$2qqh9$1@dont-email.me> |
| In reply to | #402988 |
On 11/10/2026 18:01, Andrey Tarasevich wrote:
> On Sun 10/11/2026 6:33 AM, David Brown wrote:
>>
>> It is quite obvious that it is easy to write code with loops + break
>> within a switch. It is equally obvious that it is easy to avoid such
>> constructs - there are always ways to avoid a "break" in a loop, and
>> if the code run within a switch case is complex, it is often practical
>> to refactor it into a separate function. But presumably Michael has
>> reasons not do do that.
>
> Um... The common pattern for a "search"-style loop looks as follows
>
> for (/* domain condition */)
> {
> ...
> if (/* search condition */)
> break;
> ...
> }
>
> So, loops that terminate with `break` are the mainstay of every
> competently written code. Moving the "early termination" condition into
> the loop header (i.e. lumping the search condition with the domain
> condition) is a very ugly anti-pattern in most cases. Moreover, majority
> of the loops in an average C program are such "search"-style loops,
> meaning that they do have an "early termination" condition.
>
> Now, while overwhelming majority of my loops would use `if` to check the
> "early termination", I can imagine that there sill be cases where
> `switch` is applicable and more appropriate than an `if`. Yes, a
> `switch` can always be replaced with an `if` ladder, but being _forced_
> to do so by a language limitation doesn't look right.
>
> And writing a separate function just to work around a weird language
> limitation... that doesn't look right either.
>
Certainly plenty of loops have "break" statements, especially as an
early exit.
Sometimes code is written with big switches in a function, and the cases
might include loops, and those loops might have break statements. The
question is why someone might consider this a very common situation, and
why they might consider it a failing that the same keyword is used for a
switch "break" and for a loop "break". There are two possibilities I
can imagine, but Michael may have other things in mind. One is that the
code is less clear than it might otherwise have been - if that is the
case, then I think the code should be considered for re-factoring into
separate functions if the inner loops are too complex. The other
possibility is that the programmer wanted to break out of the switch
from within the middle of the inner loop. I can imagine that happening,
and it would currently need either a bit of extra code to do the
"breaking" in two steps, a "goto", or refactoring into a separate
function. But it seems strange to me that someone would feel that was a
common enough problem to want to have "switch break" and "loop break" be
separate keywords, rather than go straight to a "break <label>" solution
that would be more general.
Only Michael can, if he wants, explain what he was thinking.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 18:57 +0100 |
| Message-ID | <11agils$2s3tg$1@dont-email.me> |
| In reply to | #402990 |
On 11/10/2026 18:17, David Brown wrote:
> On 11/10/2026 18:01, Andrey Tarasevich wrote:
>> On Sun 10/11/2026 6:33 AM, David Brown wrote:
>>>
>>> It is quite obvious that it is easy to write code with loops + break
>>> within a switch. It is equally obvious that it is easy to avoid such
>>> constructs - there are always ways to avoid a "break" in a loop, and
>>> if the code run within a switch case is complex, it is often
>>> practical to refactor it into a separate function. But presumably
>>> Michael has reasons not do do that.
>>
>> Um... The common pattern for a "search"-style loop looks as follows
>>
>> for (/* domain condition */)
>> {
>> ...
>> if (/* search condition */)
>> break;
>> ...
>> }
>>
>> So, loops that terminate with `break` are the mainstay of every
>> competently written code. Moving the "early termination" condition
>> into the loop header (i.e. lumping the search condition with the
>> domain condition) is a very ugly anti-pattern in most cases. Moreover,
>> majority of the loops in an average C program are such "search"-style
>> loops, meaning that they do have an "early termination" condition.
>>
>> Now, while overwhelming majority of my loops would use `if` to check
>> the "early termination", I can imagine that there sill be cases where
>> `switch` is applicable and more appropriate than an `if`. Yes, a
>> `switch` can always be replaced with an `if` ladder, but being
>> _forced_ to do so by a language limitation doesn't look right.
>>
>> And writing a separate function just to work around a weird language
>> limitation... that doesn't look right either.
>>
>
> Certainly plenty of loops have "break" statements, especially as an
> early exit.
>
> Sometimes code is written with big switches in a function, and the cases
> might include loops, and those loops might have break statements. The
> question is why someone might consider this a very common situation, and
> why they might consider it a failing that the same keyword is used for a
> switch "break" and for a loop "break". There are two possibilities I
> can imagine, but Michael may have other things in mind. One is that the
> code is less clear than it might otherwise have been - if that is the
> case, then I think the code should be considered for re-factoring into
> separate functions if the inner loops are too complex. The other
> possibility is that the programmer wanted to break out of the switch
> from within the middle of the inner loop. I can imagine that happening,
> and it would currently need either a bit of extra code to do the
> "breaking" in two steps, a "goto", or refactoring into a separate
> function. But it seems strange to me that someone would feel that was a
> common enough problem to want to have "switch break" and "loop break" be
> separate keywords, rather than go straight to a "break <label>" solution
> that would be more general.
>
> Only Michael can, if he wants, explain what he was thinking.
It sounds like he's pressurised into doing so. Maybe so that he can be
lectured on how to it 'properly'.
'break' to quit a loop early is part of the language, so why shouldn't
someone make use it?
It just its use can be interfered with when 'switch' is involved.
That that happens and needs a workaround, is not satisfactory. The issue
exists 100% because of sharing the 'break' keyword for two different
purposes.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-11 14:28 -0700 |
| Message-ID | <11agv1t$30q22$2@kst.eternal-september.org> |
| In reply to | #402992 |
bart <bc@freeuk.com> writes:
[...]
> 'break' to quit a loop early is part of the language, so why shouldn't
> someone make use it?
Agreed. (There are coding styles that require loops to exit only at the
bottom, but that's not what we're talking about.)
> It just its use can be interfered with when 'switch' is involved.
Yes. Everyone here knows that, and knew it before you started talking
about it.
Michael S wrote above that "The cases where I want to break out of
the loop from the switch in the body of the loop are very common."
Tim Rentsch questioned the "very common" part of that, and asked
for an example. You jumped in and asserted that an example isn't
necessary, because you misunderstood what was being said. *Of
course* there are cases where someone might want to break out of
a loop from a nested switch.
> That that happens and needs a workaround, is not satisfactory. The
> issue exists 100% because of sharing the 'break' keyword for two
> different purposes.
Yes, the overloading of the "break" keyword can be inconvenient.
It makes it difficult to break out of a loop from within a switch
statement. Again, everyone here knows that.
Breaking out of an outer loop from within an inner loop is just
as much of a problem. "break NAME;" proposed for C2y, would solve
both problems. (I just found out that recent versions of gcc and
clang support this as an extension or with "-std=c2y".)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 23:02 +0100 |
| Message-ID | <11ah12b$320sj$1@dont-email.me> |
| In reply to | #403007 |
On 11/10/2026 22:28, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> 'break' to quit a loop early is part of the language, so why shouldn't >> someone make use it? > > Agreed. (There are coding styles that require loops to exit only at the > bottom, but that's not what we're talking about.) > >> It just its use can be interfered with when 'switch' is involved. > > Yes. Everyone here knows that, and knew it before you started talking > about it. > > Michael S wrote above that "The cases where I want to break out of > the loop from the switch in the body of the loop are very common." > Tim Rentsch questioned the "very common" part of that, and asked > for an example. You jumped in and asserted that an example isn't > necessary, because you misunderstood what was being said. *Of > course* there are cases where someone might want to break out of > a loop from a nested switch. You're missing the undercurrent, which is a tone of disapproval and disbelief. But we'll find out if and when examples are ever posted. However you may want to consider that examples are rare, or even non-existent, /because/ it's not possible to do! So using 'switch' is avoided or some other workaround is found. Michael S actually said this: "The cases where I want to break out of the loop from the switch in the body of the loop are very common." This expresses a desire to do so. > Breaking out of an outer loop from within an inner loop is just > as much of a problem. A less common one but when it happens it will be an actual problem and not an artificial one. > "break NAME;" proposed for C2y, would solve > both problems. (I just found out that recent versions of gcc and > clang support this as an extension or with "-std=c2y".) OK. I'd rather have a solution that doesn't involve inventing names. Does this also fix the break-out-of-a-loop-from-inside-switch issue? In that case just 'break for/while' might do! You know, a little bit like using a different keyword for loops/non-loops.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-11 16:29 -0700 |
| Message-ID | <11ah640$329bt$5@kst.eternal-september.org> |
| In reply to | #403009 |
bart <bc@freeuk.com> writes:
> On 11/10/2026 22:28, Keith Thompson wrote:
[...]
> You're missing the undercurrent, which is a tone of disapproval and
> disbelief.
I was responding to what you wrote, not to some "undercurrent".
Missing it? I'm practically drowning in it.
You're missing the fact that the problems you keep complaining
about are things that (essentially) everyone was already aware of.
You seem unable to understand that the rest of aren't as angry about
fallthrough as you are, and that we might have valid reasons for
not being angry about it. You seem to think that anyone who is not
outraged that C hasn't added a version of switch that doesn't have
fallthrough simply doesn't understand what you're saying.
[...]
>> Breaking out of an outer loop from within an inner loop is just
>> as much of a problem.
>
> A less common one but when it happens it will be an actual problem and
> not an artificial one.
>
>> "break NAME;" proposed for C2y, would solve
>> both problems. (I just found out that recent versions of gcc and
>> clang support this as an extension or with "-std=c2y".)
[...]
> Does this also fix the break-out-of-a-loop-from-inside-switch issue?
It fixes it in the sense that both loops and switch statements can be
named, and a break or continue can optionally refer to the name of the
targeted loop or switch statement. Of course it doesn't automatically
fix existing code.
> In that case just 'break for/while' might do!
That would work for a "for" within a "while", or a "while" within
a "for", but not for a "while" within a "while" or a "for" within
a "for".
There is ample precedent for named loops in other languages.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-12 04:03 -0700 |
| Message-ID | <86ik37i3kl.fsf@linuxsc.com> |
| In reply to | #403007 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > bart <bc@freeuk.com> writes: > [...] > >> 'break' to quit a loop early is part of the language, so why shouldn't >> someone make use it? > > Agreed. (There are coding styles that require loops to exit only at the > bottom, but that's not what we're talking about.) > >> It just its use can be interfered with when 'switch' is involved. > > Yes. Everyone here knows that, and knew it before you started talking > about it. > > Michael S wrote above that "The cases where I want to break out of > the loop from the switch in the body of the loop are very common." > Tim Rentsch questioned the "very common" part of that, and asked > for an example. [...] I didn't question it. I just said it surprised me.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 07:05 +0200 |
| Message-ID | <11ahpqi$38ir0$2@dont-email.me> |
| In reply to | #402992 |
On 11/10/2026 19:57, bart wrote: > On 11/10/2026 18:17, David Brown wrote: >> Only Michael can, if he wants, explain what he was thinking. > > It sounds like he's pressurised into doing so. Maybe so that he can be > lectured on how to it 'properly'. The "pressure" is just because people are curious for more detail. Michael is an experienced C programmer, but we all work in slightly different ways on slightly different kinds of code bases. I can't think why breaking out of loops within switch cases would be "very common", but I have no reason to suspect Michael was not writing code "properly". I can't think why such code - common or not - would be problematic, or why having two different "break" keywords or constructs would be better for his code. That's why I would like Michael to give more details - not to tell him his "wrong", but to learn more about his coding. > > 'break' to quit a loop early is part of the language, so why shouldn't > someone make use it? I think most C programmers do, at least occasionally. > > It just its use can be interfered with when 'switch' is involved. > I personally have never found an issue there. "break" breaks out of the innermost loop or switch. If you write switch statements that are intermingled with loops in a non-structured manner, I am sure things get difficult and unclear. Since I do not write code with such intermingling, I have not had any such problems. Other people may choose to intermingle switches and loops, and may then have issues as a result, but I have not seen this in real code. > That that happens and needs a workaround, is not satisfactory. The issue > exists 100% because of sharing the 'break' keyword for two different > purposes. > First, there is no indication that conflicts between switch and loop "break" occurs in real code, or what the nature of such issues are. (Michael's brief comments are not enough information.) Secondly, there is no indication that this "needs a workaround" - especially as there is no definition of what might be called a "workaround". Usually you use the term to mean C code that you want to complain about. Thirdly, the keyword "break" is not being used for two different purposes - it is being used for the same purpose in two different control structures. It is well established that there are occasions where you have nested control structures, where it would be useful to be able to break out of an outer structure. In C, "break" by itself does not handle such cases, and thus additional code is needed (what you call a "workaround", and other people call "writing code") - something people have managed to do for decades. It is well established that at least some programmers would find it convenient to have some kind of multi-level or labelled "break" to let such cases be handled in a neater way, and there are proposals to add such a feature to C. This is a general situation with nested control structures, and not in any way specific to switches or mixes of switches and loops - almost certainly, nested loops are the primary use-case.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 14:37 +0100 |
| Message-ID | <11ainqf$3kkvd$1@dont-email.me> |
| In reply to | #403025 |
On 12/10/2026 06:05, David Brown wrote:
> On 11/10/2026 19:57, bart wrote:
>> On 11/10/2026 18:17, David Brown wrote:
>
>>> Only Michael can, if he wants, explain what he was thinking.
>>
>> It sounds like he's pressurised into doing so. Maybe so that he can be
>> lectured on how to it 'properly'.
>
> The "pressure" is just because people are curious for more detail.
> Michael is an experienced C programmer, but we all work in slightly
> different ways on slightly different kinds of code bases. I can't think
> why breaking out of loops within switch cases would be "very common",
> but I have no reason to suspect Michael was not writing code "properly".
> I can't think why such code - common or not - would be problematic, or
> why having two different "break" keywords or constructs would be better
> for his code. That's why I would like Michael to give more details -
> not to tell him his "wrong", but to learn more about his coding.
>
>>
>> 'break' to quit a loop early is part of the language, so why shouldn't
>> someone make use it?
>
> I think most C programmers do, at least occasionally.
>
>>
>> It just its use can be interfered with when 'switch' is involved.
>>
>
> I personally have never found an issue there. "break" breaks out of the
> innermost loop or switch. If you write switch statements that are
> intermingled with loops in a non-structured manner, I am sure things get
> difficult and unclear. Since I do not write code with such
> intermingling, I have not had any such problems.
What do mean by 'intermingled' - nested? That's how structured
programming works!
Otherwise there is no intermingling in this example:
for (i=0; i < N; ++i) {
x = A[i];
if (x == 5 || x == 6 || x == 10 || x == 11) break;
switch (A[i]) {
case 5: case 6: case 10: case 11: break; // ??
}
}
The loop body shows two ways of aborting the loop when an exit condition
is detected:
* Using an if-statement and 'break'
* Using a switch-statement and ... break?
The second doesn't work because 'break' now shadows its outer meaning.
Both would otherwise be reasonable choices for this logic.
Here's another example:
for (i=0; i < N; ++i) {
if (A[i] == 1)
if (!f()) break;
else if (A[i] == 2)
if (!g()) break;
else
if (!h()) break;
}
Here, someone might notice that 'switch' suits this pattern better than
an if-else chain. So they try this:
for (i=0; i < N; ++i) {
switch (A[i]) {
case 1:
if (!f()) break;
case 2:
if (!g()) break;
default:
if (!h()) break;
}
}
This is valid C still, but it doesn't have the same behaviour.
Maybe, some compilers with certain options may point out something about
fall-through, so you're aware something's amiss, but it doesn't get
around the problem: you can't simply swap if-else chains with switch
even when the latter is a better fit.
This is a definite flaw in the language.
>> That that happens and needs a workaround, is not satisfactory. The
>> issue exists 100% because of sharing the 'break' keyword for two
>> different purposes.
>>
> First, there is no indication that conflicts between switch and loop
> "break" occurs in real code, or what the nature of such issues are.
As I said, they CAN'T occur in finished code, since some other approach
has had to be used. You won't know if the conflicts have occurred!
> (Michael's brief comments are not enough information.) Secondly, there
> is no indication that this "needs a workaround" - especially as there is
> no definition of what might be called a "workaround". Usually you use
> the term to mean C code that you want to complain about. Thirdly, the
> keyword "break" is not being used for two different purposes - it is
> being used for the same purpose in two different control structures.
One is for loops to stop iteration, it is optional, and tends to be used
sparingly.
The other is for switch, it is nearly always necessary for the common
pattern of switch, and is needed because otherwise the language leaves
you stranded in the middle of a switch statement. There is no iteration
involved.
Does that sound about the same?
> It is well established that there are occasions where you have nested
> control structures, where it would be useful to be able to break out of
> an outer structure. In C, "break" by itself does not handle such cases,
> and thus additional code is needed (what you call a "workaround", and
> other people call "writing code")
People keep bringing this up. Yes, that's an annoyance too, but it is
genuinely rare.
BTW I looked at the sources for one of my projects (in my language) to
see whether breaking a loop from switch ever occurred. I found it the
very first instance! Then I kept finding more.
This is the outline of the first example:
while pmtype := nextcmdparam(paramno, name, value, "m") do
case pmtype
when pm_option then
when pm_sourcefile then
if passlevel in [run_pass, runpcl_pass] then
exit
'case' is a sister statement to 'switch' and has the same syntax. It's
used for more general cases usually with a small number of branches.
My 'break' statement is called 'exit'. Number two:
do
lex() !first symbol on line
case lx.symbol
when eofsym then
when kendsym then
exit
There are loads more. This next is an example of breaking out of two
loop levels:
while wt do
while w do
if ... then
exit all
It is nearly always all the loops, so I simply write 'all' (an alias for
0 which denotes the outermost loop without needing to count). There are
two such 'exit all' in this 35Kloc project; all other exits are for one
level only.
Here's one more loop/switch example, but with a twist:
docase flags^
when 'S' then
when 'U' then
else
exit
end
'docase' and 'doswitch' are looping forms, which are very common in my
programs. This one is the equivalent of this in C:
while (1) {
switch (*flags) {
case 'S': ...
case 'U': ...
default:
.... // NOW WHAT?
}
}
You can't express it. Sure you can get around it, but that is just
pandering to the issue, and it means you can't use what might be the
most natural and clearest way to do it.
In my language and in my programs, breaking out of a loop from within a
multi-way case/switch selection is a very, very common idiom which is
denied to C users.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 16:12 +0200 |
| Message-ID | <11aipsc$3kr94$1@dont-email.me> |
| In reply to | #403032 |
On 12/10/2026 15:37, bart wrote:
> On 12/10/2026 06:05, David Brown wrote:
>> On 11/10/2026 19:57, bart wrote:
>>> On 11/10/2026 18:17, David Brown wrote:
>>
>>>> Only Michael can, if he wants, explain what he was thinking.
>>>
>>> It sounds like he's pressurised into doing so. Maybe so that he can
>>> be lectured on how to it 'properly'.
>>
>> The "pressure" is just because people are curious for more detail.
>> Michael is an experienced C programmer, but we all work in slightly
>> different ways on slightly different kinds of code bases. I can't
>> think why breaking out of loops within switch cases would be "very
>> common", but I have no reason to suspect Michael was not writing code
>> "properly". I can't think why such code - common or not - would be
>> problematic, or why having two different "break" keywords or
>> constructs would be better for his code. That's why I would like
>> Michael to give more details - not to tell him his "wrong", but to
>> learn more about his coding.
>>
>>>
>>> 'break' to quit a loop early is part of the language, so why
>>> shouldn't someone make use it?
>>
>> I think most C programmers do, at least occasionally.
>>
>>>
>>> It just its use can be interfered with when 'switch' is involved.
>>>
>>
>> I personally have never found an issue there. "break" breaks out of
>> the innermost loop or switch. If you write switch statements that are
>> intermingled with loops in a non-structured manner, I am sure things
>> get difficult and unclear. Since I do not write code with such
>> intermingling, I have not had any such problems.
>
> What do mean by 'intermingled' - nested? That's how structured
> programming works!
>
No - if I had meant "nested", I would have written "nested". In C,
switch statements are not fully structured. That's why I wrote
"intermingled". I had assumed the meaning was clear, but there is no
standard definition of "intermingled" code.
You can write things like :
int foo(int x) {
int y = x;
switch (x) {
case 0 :
y++;
break;
case 1 :
for (y = 0; y < x; y++) {
case 2:
x++;
}
}
return y;
}
That is obviously a silly, invented example. But it is possible to jump
into loops with an outer switch. Such things may be of use to some
people - just as "goto" jumping around might be of use. It is of no
interest to me, and I don't write code that intermingles switches and
loops (or conditionals). I limit my switch statements to having clear
structure - using braces to create blocks within cases if I have local
variables.
In the hypothetical example above, if there was a "break" after "x++;",
it could easily be unclear to the reader if it applied to the loop, or
to the switch. Having separate "break_switch" and "break_for" keywords
or constructs would make that difference clear - but I cannot think of a
real example where it would not be clearer to have the entire loop
within one case and avoid the issue altogether.
> Otherwise there is no intermingling in this example:
>
> for (i=0; i < N; ++i) {
> x = A[i];
> if (x == 5 || x == 6 || x == 10 || x == 11) break;
>
> switch (A[i]) {
> case 5: case 6: case 10: case 11: break; // ??
> }
> }
That is not "intermingling", as I used the word - it is just a switch
nested inside a loop.
>
> The loop body shows two ways of aborting the loop when an exit condition
> is detected:
>
> * Using an if-statement and 'break'
>
> * Using a switch-statement and ... break?
>
> The second doesn't work because 'break' now shadows its outer meaning.
> Both would otherwise be reasonable choices for this logic.
No, they would not be reasonable choices. It is very, /very/ simple, as
long as your code is written in a structured manner - nesting the
constructs as you did above. "break" applies to the innermost loop or
switch. That's the rule.
>
> Here's another example:
>
> for (i=0; i < N; ++i) {
> if (A[i] == 1)
> if (!f()) break;
> else if (A[i] == 2)
> if (!g()) break;
> else
> if (!h()) break;
> }
>
> Here, someone might notice that 'switch' suits this pattern better than
> an if-else chain. So they try this:
>
> for (i=0; i < N; ++i) {
> switch (A[i]) {
> case 1:
> if (!f()) break;
> case 2:
> if (!g()) break;
> default:
> if (!h()) break;
> }
> }
>
> This is valid C still, but it doesn't have the same behaviour.
Surprise! Someone changed the code, and the behaviour changed! Who
could have imagined that might happen?
> In my language and in my programs,
No one else cares. Your language is your own, and not relevant outside
of your bubble. You keep thinking it somehow "proves" your points, or
that it shows how "wrong" C is - it does not. There is no need to waste
your time or other readers' time by writing about it. Stick to writing
about C here.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 16:38 -0700 |
| Message-ID | <11aei9t$24k8m$4@kst.eternal-september.org> |
| In reply to | #402890 |
Michael S <already5chosen@yahoo.com> writes:
> On Sat, 10 Oct 2026 20:08:20 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-10-10 15:11, bart wrote:
>> >
>> > Well, Algol 68 doesn't even have 'break'. For unusual control-flow
>> > it needs goto.
>>
>> Yes. - And while "C" has 'goto' as well it also supports 'break' for
>> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
>> keyword for other purposes as in 'switch' where it's been useful.
>
> After practicing C programming for more than 35 years I am deeply
> convinced that reuse of the same 'break' keyword for loops and for
> switch was a mistake. But then again, DRM did not have a benefit
> of hindsight.
Actually he (DMR) did. C's parent language, BCPL, had distinct BREAK
and ENDCASE keywords.
I agree that combining them both into "break" was a mistake. At this
point, I think the best solution is named loops and "break loop_name;".
There are proposals for C2y.
A distinct "endcase" keyword would have been cleaner IMHO, but code
using the existing case/break will continue to exist approximately
forever.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-10 21:09 +0100 |
| Message-ID | <11ae62d$221po$1@dont-email.me> |
| In reply to | #402887 |
On 10/10/2026 19:08, Janis Papanagnou wrote:
> On 2026-10-10 15:11, bart wrote:
>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>> [...]
>> If you look at actual C codebases, fall-through is incredibly rare.
>> Nearly always, it will use break, or sometimes other control-flow such
>> as return or goto, so that fall-through doesn't happen.
>
> I have no representative statistics, but my impression also matches
> that; fall-through is certainly much rarer than the 'break' case.
>
> In 6 C-sources in some of my directories I have 30 'switch' statements
> (some nested on more than one level), and in two cases fall-throughs.
> In another (non-C) place I find 40+ fall-throughs. - Not predominantly,
> but it's certainly not only an exotic corner-case! - So there's reason
> to support it, best without clumsy surrogate-constructs (workarounds).
This is difficult for me to survey as it take some effort in a compiler,
and I no long have many C codebases around. But here is one attempt:
Program Case Labels Break/Goto/Return
Piet 6 6
SQLite3 793 805
Lua 555 472
Nano 9 9
TinyPas 160 118
STB 69 62
MiniGMP 13 13
Middle column is total case labels which not followed by another case label.
Right column is total number of switch-breaks, plus return/goto IF they
are the first and only statement in the case-block. (Being unstructured
makes it tricky.)
So Return/Goto following other code is not counted. In some cases I have
verified that some been missed for that reason.
This is not foolproof: one case may have 2 breaks, and the following
none so falls through. But from visual inspections failed to show
significant fall-through in use.
>>
>> Note that if-statement blocks don't have fall-through either when
>> there is an else branch.
>>
>> Imagine having to write this: [...]
>
> (Slow down, cool down your brain! - It makes no sense to speak about
> fall-throughs in contexts of 'if' constructs. Making up inappropriate
> comparisons never lead you anywhere;
If it is probably the most relevant comparison that you can make.
A statement like this:
if (cond) {A} else {B}
can be always be expressed as:
switch (!!cond)
case 1: {A}; break;
default: {B}
}
Notice that 'break' the switch needs, that 'if' doesn't.
>> I guess everyone would still defend that choice (because for one
>> person in a million it will be valuable feature). But it is CLEARLY
>> wrong.
>
> Sadly you show again and confirm that it's just *you* who speaks about
> "right" or "wrong" (even "clearly"), and again fall into the habit to
> speak for or at least make wild guesses about "everyone".
> I've shown above that I'm obviously regularly using it
You haven't given an example, which would be interesting. But this is
the curious fact about C, that after 50 years, every misfeature and
quirk is an invaluable feature to somebody!
- and before my
> post I didn't even know that fact, so it's nothing about "defending"
> anything. And I've got not yet any indication - i.e. before your own
> personal complaints about it - that only "one person / million" would
Well, that was about fall-through in an IF statement.
> make good use of that feature; that's also completely implausible, and
> there's many facts that support this opinion (e.g. people talking about
> it, being part of coding standards, reading various explanations about
> it as being a "*concept* in programming", etc.).
>
> (Your opinions don't reflect the world, but rather just your personal
> vicinity - which I fear isn't even more than the personal small bubble
> you reside in.)
No. Look at how 'switch' implemented in pretty much every other language
other C (and C++ which inherited it).
How many have default fall-through?
I suggest most people have the same opinion as I do on this.
>>
>>> Just imagine if some C-programmers wanted a fall-through semantics
>>> but all they got would be the Pascal or Algol 68 'case' construct.
>>
>> Well, Algol 68 doesn't even have 'break'. For unusual control-flow it
>> needs goto.
>
> Yes. - And while "C" has 'goto' as well it also supports 'break' for
> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
> keyword for other purposes as in 'switch' where it's been useful.
No, it makes no sense at all, because their use-cases overlap.
It means that, inside a SWITCH statement, you can't do an early break
out of a case-block from inside a loop.
And if inside a loop, you can't break out of that loop from inside a
switch statement:
while (1) {
if (x == 3)
break;
switch (x) {
case 3: break;
}
}
The first break works within IF. But if you choose to use SWITCH, if
doesn't work.
You still think it makes sense?
> (Somewhere you thematized whether fall-through should be the default
> behavior of 'switch'; for me it would make as much sense to switch
> roles of the defaults in C's 'switch' to make the more common case
> terser, or have explicit statements for both branch-behaviors types.
> Actually I don't care much; there's more important things here that
> I'd find noteworthy; see below.)
>
>>
>> I don't have fall-through either; it is just so rare. But I do have a
>> 'recase' statement to pass control to an /arbitrary/ block, not just
>> the one that happens to follow.
>
> (I'm not interested in your language.)
Why not? You don't have to use it; it just needs to exist.
A 'structured switch' has been discussed. And I have a 'structured
switch' implemented in a equally low level language, so Ask Me Anything.
>> This way, BLOCKS CAN BE REORDERED without changing behaviour.
>
> Fine for you.
It's fine for everyone.
>> But C's switch is just /too/ low-level. For example, a structured
>> switch could be easily transformed into an if-else chain.
>>
>> You can't do that in general with C switch because there IS no
>> structure; it can be totally chaotic.
>
> I recall, the disappointment I had with C's 'switch' was that it didn't
> support "strings" as tags.[*] - But so what? Noting that as impossible
> and carrying on, either with workarounds ('if' cascades) or switching
> the language (if appropriate, possible, and worthwhile).
>
> [*] In the GNU version of Awk - a much simpler but higher abstracted
> language - you can nicely compare strings, and even regexps.
I have a narrow view of SWITCH, which is specifically for use with
integer values. That allows comparison of N unique possibilities
simultaneously, or in O(1) time.
So if you're comparing strings, then it is not SWITCH IMO, unless those
strings are perhaps interned.
(I use a different feature when it needs to be more flexible, and in
that case, any type for which equality, or sometimes 'in', is defined,
will work.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-10 23:14 +0200 |
| Message-ID | <11ae9r3$cjlv$7@dont-email.me> |
| In reply to | #402899 |
[ I skip most of what you wrote because it's not adding anything new
and I basically still just disagree with all you presented; if you
re-read my previous post you have my comments on your "new" text. ]
On 2026-10-10 22:09, bart wrote:
> On 10/10/2026 19:08, Janis Papanagnou wrote:
>> On 2026-10-10 15:11, bart wrote:
>>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>>>
>>>> Just imagine if some C-programmers wanted a fall-through semantics
>>>> but all they got would be the Pascal or Algol 68 'case' construct.
>>>
>>> Well, Algol 68 doesn't even have 'break'. For unusual control-flow it
>>> needs goto.
>>
>> Yes. - And while "C" has 'goto' as well it also supports 'break' for
>> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
>> keyword for other purposes as in 'switch' where it's been useful.
>
> No, it makes no sense at all, because their use-cases overlap.
>
> It means that, inside a SWITCH statement, you can't do an early break
> out of a case-block from inside a loop.
>
> And if inside a loop, you can't break out of that loop from inside a
> switch statement:
>
> while (1) {
> if (x == 3)
> break;
>
> switch (x) {
> case 3: break;
> }
> }
>
> The first break works within IF. But if you choose to use SWITCH, if
> doesn't work.
It also doesn't work in nested loops. (That's a restriction of C's
'break'.)
I don't think it makes sense to introduce another distinct keyword
to address a special case like that; that's very short-sighted. You
could still not address, e.g., a "for() for() switch()" structure.
Other languages provide more universal, thus more sensible features
to support out-of-band conditions, or more universal "local exits"
(that support more than one nested level).
> You still think it makes sense?
Yes, because it works as intended for the other common cases.
If you need a "flexible jump" just use 'goto'. The point of 'break'
is to "tame" that "harmful goto" and introduce something "lighter".
Some languages support a 'break' (and a 'continue') with a numeric
argument to handle the case of nested constructs. That is of course
yet more flexible without sacrificing the "prevent wild jumps" dogma.
[ another big snip ]
>> [*] In the GNU version of Awk - a much simpler but higher abstracted
>> language - you can nicely compare strings, and even regexps.
>
> I have a narrow view of SWITCH, which is specifically for use with
> integer values. That allows comparison of N unique possibilities
> simultaneously, or in O(1) time.
> So if you're comparing strings, then it is not SWITCH IMO, unless those
> strings are perhaps interned.
A CDC 175/176 carried a Pascal TEXT object in one machine word and
could compare it as atom. Newer standard PC CPUs have more bits in
a word than those former supercomputers. - But the point here was
that internals should be abstracted by a higher level programming
language. - And compilers have principally various possibilities to
support some "atomization" of string comparisons with compile-time
string constants. - As said, it would have been useful in many of
my application cases. (No more, no less.)
(BTW, it would be new to me that you'd have complexity guarantees in
"C".)
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web