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-13 23:19 +0100 |
| Articles | 20 on this page of 266 — 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 Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
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 bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
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-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
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
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 22:46 +0100 |
| Message-ID | <11ajkev$v8c$1@dont-email.me> |
| In reply to | #403063 |
On 12/10/2026 22:21, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/10/2026 20:52, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/10/2026 18:58, Dan Cross wrote:
>>>>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>>
>>>
>>>> This is my first example expressed in C (note those first three args are
>>>> passed by reference):
>>>>
>>>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>>>> switch (pmtype)
>>>> case pm_option: ...; break;
>>>> case pm_sourcefile:
>>>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>>>> break;
>>>
>>> Aside from the incorrect syntax, it's really difficult to
>>> determine your intent from this code fragment.
>>
>> Really? It's attempting to break out of the while-loop from inside that
>> switch statement. What we've been discussing at length.
>
> It's not clear from the context within the code fragment that
> you intended the second break to terminate the while loop,
> or for the first break to terminate the while loop (or
> for neither to continue the switch).
>
>>
>> But it won't work like this because in this context, that 'break' is
>> switch-break not loop-break.
>
> Which break? There are two.
Oh, OK. The original didn't need switch-break, it only had loop-break.
I added switch-break for the C version; that is the first 'break' above.
But loop-break is also 'break'. So it is still wreaking confusion!
For the same reason too: the intent in each case is different.
>
>>
>>
>>> It's likely that folks here could provide more idiomatic
>>> C if you described the problem you're attempting to solve
>>> rather than providing an incomplete and incorrect code
>>> fragment.
>>
>> I'd be interested in the idiomatic C that doesn't involve rewriting my
>> code or adding complexity in order to get around that silly clash.
>>
>
> Describe the problem the code is intended to
> address. Rather than a very small fragment
> of code without any context. It appears to be parsing
> a command line, something done quite frequently in C.
(Yes. It is normally parsing '[options] file [options]', but when a
filename is seen and that file is to be run immediately, it needs to
stop parsing as those trailing options will be processed by the
application that is run.
Maybe I should have used the simpler example.)
> In any case, using goto to leave a switch statement nested
> in a loop is certainly an idiomatic construct that is widely
> used to leave the outer loop early. Another option is to declare
> a local bool before the switch in the while loop, initialized to false.
>
> Set it to true when you want to bail early:
>
> while (condition)
> bool bail = false;
> switch (blah) {
> case 1:
> break;
> case 2:
> if (fred == name) bail = true;
> break;
> }
> if (bail) break;
> do_something();
> }
>
> Whether that is beautiful or ugly is a matter of opinion,
> and you've made yours very clear.
Using my proposal, that would look like:
while (condition)
newswitch (blah) {
case 1: # this is an empty block
case 2: # this is separate
if (fred == name) break;
}
do_something();
}
No 'break' is routinely needed for the switch. 'break' here exits the loop.
Not that this was serious, but probably 'case' would need a new keyword
since the meaning of 'case 1: case 2:' is significantly different
between old and new switch contexts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-13 09:27 +0200 |
| Message-ID | <11akmgh$9uvd$1@dont-email.me> |
| In reply to | #403066 |
On 12/10/2026 23:46, bart wrote:
> On 12/10/2026 22:21, Scott Lurndal wrote:
>
>> In any case, using goto to leave a switch statement nested
>> in a loop is certainly an idiomatic construct that is widely
>> used to leave the outer loop early. Another option is to declare
>> a local bool before the switch in the while loop, initialized to false.
>>
>> Set it to true when you want to bail early:
>>
>> while (condition)
>> bool bail = false;
>> switch (blah) {
>> case 1:
>> break;
>> case 2:
>> if (fred == name) bail = true;
>> break;
>> }
>> if (bail) break;
>> do_something();
>> }
Alternatively :
bool looping = true;
while (looping && condition)
switch (blah) {
case 1:
break;
case 2:
if (fred == name) looping = false;
break;
}
do_something();
}
(The semantics for when "do_something()" is called is slightly different
here, but that depends on what something you want to do.)
Or you put your loop in a function - and then "return" breaks out of
everything. There are plenty of ways to structure the code.
Like every programming language, C provides some features and not
others. You use the features the language has in the way that gives the
best results for your code. There are /always/ going to be some
mismatches - features that you think are unnecessary, and things that
you think would be convenient if they existed. No two programmers are
going to agree on those mismatches, though they might have some overlap
of opinion.
Trying to invent a new special syntax just for one particular use-case
is absurd. It might make sense in a little private language, but not
for a mainstream programming language.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 12:18 +0200 |
| Message-ID | <11al0h6$4o6l$2@dont-email.me> |
| In reply to | #403082 |
On 2026-10-13 09:27, David Brown wrote: > [...] > > Trying to invent a new special syntax just for one particular use-case > is absurd. That's the point! > It might make sense in a little private language, but not > for a mainstream programming language. Such dubious designs might not even make sense in a "private language"; but no one would notice such a design decision, and that is the crucial (and positive) aspect of "private languages". Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 11:33 +0100 |
| Message-ID | <11al1eh$enb3$1@dont-email.me> |
| In reply to | #403082 |
On 13/10/2026 08:27, David Brown wrote:
> On 12/10/2026 23:46, bart wrote:
>> On 12/10/2026 22:21, Scott Lurndal wrote:
>>
>>> In any case, using goto to leave a switch statement nested
>>> in a loop is certainly an idiomatic construct that is widely
>>> used to leave the outer loop early. Another option is to declare
>>> a local bool before the switch in the while loop, initialized to false.
>>>
>>> Set it to true when you want to bail early:
>>>
>>> while (condition)
>>> bool bail = false;
>>> switch (blah) {
>>> case 1:
>>> break;
>>> case 2:
>>> if (fred == name) bail = true;
>>> break;
>>> }
>>> if (bail) break;
>>> do_something();
>>> }
>
> Alternatively :
>
> bool looping = true;
> while (looping && condition)
> switch (blah) {
> case 1:
> break;
> case 2:
> if (fred == name) looping = false;
> break;
> }
> do_something();
> }
>
> (The semantics for when "do_something()" is called is slightly different
> here, but that depends on what something you want to do.)
>
> Or you put your loop in a function - and then "return" breaks out of
> everything. There are plenty of ways to structure the code.
Sometimes you just want to write the simplest, more direct and most
intuitive code.
/Having/ to invent functions, and a special interface, to get around a
language issue is always a code smell.
> Like every programming language, C provides some features and not
> others. You use the features the language has in the way that gives the
> best results for your code. There are /always/ going to be some
> mismatches - features that you think are unnecessary, and things that
> you think would be convenient if they existed. No two programmers are
> going to agree on those mismatches, though they might have some overlap
> of opinion.
>
> Trying to invent a new special syntax just for one particular use-case
> is absurd. It might make sense in a little private language, but not
> for a mainstream programming language.
In my language (and others which don't have C's quirk) there is no
special syntax needed. You just write 'exit' or 'break', as the case may
be, oblivious to whether you are inside switch or not.
This is less 'cognitive load' than the calamity of having one extra
keyword, that C would have needed.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-13 00:25 +0300 |
| Message-ID | <20261013002531.000025b8@yahoo.com> |
| In reply to | #403060 |
On Mon, 12 Oct 2026 21:57:46 +0100
bart <bc@freeuk.com> wrote:
> On 12/10/2026 20:52, Scott Lurndal wrote:
> > bart <bc@freeuk.com> writes:
> >> On 12/10/2026 18:58, Dan Cross wrote:
> >>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com>
> >>> wrote:
> >>
> >
> >> This is my first example expressed in C (note those first three
> >> args are passed by reference):
> >>
> >> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> >> switch (pmtype)
> >> case pm_option: ...; break;
> >> case pm_sourcefile:
> >> if (passlevel == run_pass || passlevel ==
> >> runpcl_pass) { break;
> >
> > Aside from the incorrect syntax, it's really difficult to
> > determine your intent from this code fragment.
>
> Really? It's attempting to break out of the while-loop from inside
> that switch statement. What we've been discussing at length.
>
Thank you. You correctly identified the most common of the patterns
that triggered my response to Janis that started this particular
sub-thread.
The important part missing in your excerpt is that there are several
variables declared and initialized before loop and further processed
both within and after the loop.
> But it won't work like this because in this context, that 'break' is
> switch-break not loop-break.
>
>
> > It's likely that folks here could provide more idiomatic
> > C if you described the problem you're attempting to solve
> > rather than providing an incomplete and incorrect code
> > fragment.
>
> I'd be interested in the idiomatic C that doesn't involve rewriting
> my code or adding complexity in order to get around that silly clash.
>
As far as I am concerned, my most common workaround is goto. Others can
have other preferences.
It works well, but the need to invent the name of the label is a bit
annoying.
BTW, Ada/VHDL solution, with optional label before the loop also
suffers from this particular defect. Yes, it is more "structural" than
goto. It is considered important by many people, supposedly including
yourself. But on my personal ladder of preferences "structureness" by
itself is not particularly high as long as it does not bring another
benefits, like, for example, locality=reduced scope.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 22:20 +0000 |
| Message-ID | <11ajmfe$mfc$1@reader2.panix.com> |
| In reply to | #403054 |
In article <11ajcv8$3u33s$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 12/10/2026 18:58, Dan Cross wrote:
>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>>> This is valid C still, but it doesn't have the same behaviour.
>>
>> Yes. I guess I fail to see the point of these, as what you are
>> trying to show seems obvious to me, and I strongly suspect it is
>> obvious to others, as well.
>>
>> Are you suggesting that people are unaware of how `break`
>> interacts with `switch` inside of a loop? I don't think that is
>> true; I think people are well aware, but know how to work around
>> it and don't see it as a huge impediment; more of a mild
>> inconvenience.
>>
>> Or are you suggesting that they are trying to defend the design
>> of the language in this regard?
>
>That's what it seems like: obstinately trying to pretend it is not a
>flaw, that it makes perfect sense, then you never want to do any of the
>stuff where it causes problems anyway etc.
I think that may be your interpretation of what others are
saying, but that is not necessarily what they _are_ saying.
>There are several issues discussed regarding switch:
>
>* That its structure is totally chaotic (there /is/ no structure)
I think Keith said exactly that; it mixes structure and no
structure.
>* That 'break' is needed to escape from the middle of that statement to
> the end
I think the discussion is mostly you saying that this is
terrible, and others shrugging with their workarounds.
>* That that 'break' happens also to clash, needlessly, with loop-break
Yeah, I also think that's annoying.
>* And also with 'case' only doing one label at a time, instead of
> being able to do, for example: 'case a, b, c:' or 'case x...y',
> although some of this is taken care of via extensions.
That's also kind of irritating.
>There's quite a lot that could have been done much better!
I mean, yes. But as I said before, C is the language that it
is; I will acknowledge that it could have been better, but here
we are. Aside from that acknowledgement, what more is there to
actually do about it at this point?
>> I similarly don't think that is
>> true; I have certainly been annoyed by this, and I suspect
>> others have as well. But again, people know how to work around
>> it.
>
>Yes, various workarounds are needed, such as the gotos in your examples.
>But if we're going to use 'goto', then why bother with 'break' at all?
>
>Presumably it is to make life easier.
I don't know. I wasn't in the room when it was invented; its
immediate predecessor, BCPL, had no way to mark the end of a
`case` in a `switchon` at all (BCPL grew `ENDCASE` later),
though did have `valof` and `resultis` for obtaining the values
of _blocks_. So, one could write something like:
let howmany = valof switchon n into
$( case 0: resultis "zero"
case 1: resultis "one"
case 2: resultis "two"
default resultis "many"
$)
And so on; something one cannot do in C (but can in Rust).
Why did C bother with `break;` to end a `case` and not something
unique, like `ENDCASE` in later versions of BCPL?
I'm speculating, but I suspect it was because they wanted to
minimize the _need_ for `goto`; that unlike in BCPL blocks could
not return values; that `break` already existed to break out of a
loop and the control flow is not dissimilar conceptually; and
perhaps more importantly they were building a compiler intended
to run on a very, very small machine, shared by others, and ran
out of space to build something more elaborate. By the time
they had a bigger computer that could compile a better language,
the construct and its consequences were well understood and
there was a body of code that would have to change, and they did
not feel it was worth it.
At least, I imagine it was something like that.
>> C is not anyone's mother; I doubt anyone who is not a kook feels
>> like they need to rise to the defense of its honor when it is
>> criticized.
>
>Defending every shortcoming or quirk to the death seems common here. And
>there will always be people to whom they are an invaluable feature (see
>SL's recent post).
I don't think that anyone is doing that. I suspect it is the
opposite: others wonder why you latch onto every quirk or
shortcoming as evidence for your ultimately subjective opinion
that C is a bad language.
It is clear that you do not like C; you are not exactly hiding
it. But there is no C language politburo; no one will denounce
you for dreaming different dreams about the poor structure of
`switch`, and no one is going to challenge you to a duel over
your criticism of C.
But it is also clear that much of your dislike is opinion, based
on things that most others here just don't care about; the
pecularities of the `switch` statement are a good example. I
occasionally find it irritating, but 99% of the time I just
don't care; one learns to write `break` and one moves on with
one's life. Life is too short as it is to get worked up over
the `break` statement.
Others also point out that your criticism is often rooted in
misconceptions or misunderstandings of the language, and that is
fair: if you say something that is technically wrong about C as
evidence in support of your opinion about it, then you _should_
expect pushback. That's not anyone picking on you, it's them
holding you to a standard.
>> What I think some people are sort of mystified by is this idea
>> that this one thing is such a deal-breaker as to render the
>> language unuseable.
>
>In my case I would find it unusable for major projects if I had to code
>manually. I'm just to spoilt for one, but always I'm a terrible typist
>and C needs a LOT of fiddly typing.
Ok.
>>> 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.
>>
>> It _can be_ an _annoyance_ in the language, sure. Is it a,
>> "definite flaw"? That is subjective. You clearly feel that it
>> is. I couldn't say whether anyone else feels that way; I think
>> it's too minor to matter for most programmers.
>
>It's minor until it bites - see the example below.
>
>[snip]
>This is my first example expressed in C (note those first three args are
>passed by reference):
>
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> switch (pmtype)
> case pm_option: ...; break;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break;
>
>Except I can't use break like that. So I have to find a workaround.
>
>This is also 30% more tokens than my original, and that's before I fix
>this problem.
The obvious syntax error aside, I'll wager that, to most C
programmers, this is still minor. I won't belabor the
workarounds as those are both well-known and have already been
discussed several times in this thread, alone. The only part
that bears mentioning here is that 99% of C programmers know
perfectly well how to deal with this and, frankly, just don't
find it that much of an imposition.
I think the impedence mismatch with what you're saying is that,
because it is so minor to so many people, it seems mystifying
that you think it's such a big deal.
>So I'm sure C is perfectly usable, what we can't quantity easily is how
>much extra effort is needed to get things done compared to a more
>amenable syntax.
That may be true. But I suspect that if you took a survey of,
say, 1000 C programmers, this would be unlikely to enter the top
10 complaints of more than a handful of them.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 17:02 -0700 |
| Message-ID | <11ajsfi$28f2$5@kst.eternal-september.org> |
| In reply to | #403054 |
bart <bc@freeuk.com> writes:
[...]
> That's what it seems like: obstinately trying to pretend it is not a
> flaw, that it makes perfect sense, then you never want to do any of
> the stuff where it causes problems anyway etc.
Nobody is trying to pretend that there are no flaws. The rest of
us acknowledge that C has flaws (though we don't necessarily agree
with what those flaws are) and then get on with writing working C
code in spite of those flaws.
Most of us are also aware of how very difficult it would be to "fix"
those flaws without breaking existing code.
You completely misunderstand where most of us are coming from,
even after it's explained to you.
> There are several issues discussed regarding switch:
>
> * That its structure is totally chaotic (there /is/ no structure)
An overstatement, but I don't entirely disagree. switch is a low-level
control structure. I'd say it's notable for its low-levelness even
compared to other C features.
> * That 'break' is needed to escape from the middle of that statement to
> the end
Yes. We all know that.
> * That that 'break' happens also to clash, needlessly, with loop-break
Yes, we all know that. BCPL had BREAK and ENDCASE. B apparently
dropped both, and then re-added just BREAK. C inherited break
from B. I haven't seen anyone say that that wasn't a mistake.
We just don't spend decades worrying about it.
Tell me, have this ever been a problem for you personally? Have
you ever written a switch statement nested in a loop and wanted to
break out of the loop from within the switch? (In C; I'm not asking
about your experience with other langauges.) How much difficulty
has it really cause for you?
> * And also with 'case' only doing one label at a time, instead of
> being able to do, for example: 'case a, b, c:' or 'case x...y',
> although some of this is taken care of via extensions.
"case a, b, c:" is written as "case a: case b: case c:". It's a little
more verbose than it needs to be. It's very mildly annoying.
As for "case x...y", that's already proposed for C2Y, and is
documented in the N3886 draft. You continue to whine about problems
that have already been solved.
> There's quite a lot that could have been done much better!
So invent a time machine and tell Dennis Ritchie to do it your way.
[...]
> Defending every shortcoming or quirk to the death seems common
> here.
No, it isn't.
[...]
--
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-13 01:53 +0100 |
| Message-ID | <11ajvf2$492m$1@dont-email.me> |
| In reply to | #403076 |
On 13/10/2026 01:02, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] > Tell me, have this ever been a problem for you personally? It's the bigger picture that is more the problem. And yes it has affected me as I've never been able to adopt C as my main language. I guess I was too spoilt. But it isn't really about me - decisions in the language, how tools work and so on affect everyone. And yes, discussing PL design is interesting to me - there's so much going on here! > Have > you ever written a switch statement nested in a loop and wanted to > break out of the loop from within the switch? (In C; I'm not asking > about your experience with other langauges.) How much difficulty > has it really cause for you? Yes. I had to use 'goto'. I don't mind using goto when necessary but here it shouldn't have been. >> * And also with 'case' only doing one label at a time, instead of >> being able to do, for example: 'case a, b, c:' or 'case x...y', >> although some of this is taken care of via extensions. > > "case a, b, c:" is written as "case a: case b: case c:". It's a little > more verbose than it needs to be. It's very mildly annoying. It is quite annoying and a distraction. A lot more to mistype too.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 03:54 +0200 |
| Message-ID | <11ak2vp$4o6m$1@dont-email.me> |
| In reply to | #403076 |
On 2026-10-13 02:02, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> There are several issues discussed regarding switch: >> * That its structure is totally chaotic (there /is/ no structure) > > An overstatement, but I don't entirely disagree. switch is a low-level > control structure. I'd say it's notable for its low-levelness even > compared to other C features. I'm a bit astonished about that statement. The [original] "C" control structures appear to me to be all low-level; if I see "for (..;..;..)" it doesn't really strike me with awe concerning its abstraction level. And 'for' is the "most complex", the others are even more primitive. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-13 10:52 +0000 |
| Message-ID | <11al2i7$gd2$1@reader2.panix.com> |
| In reply to | #403076 |
In article <11ajsfi$28f2$5@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >[snip] >Yes, we all know that. BCPL had BREAK and ENDCASE. B apparently >dropped both, and then re-added just BREAK. C inherited break >from B. I haven't seen anyone say that that wasn't a mistake. >We just don't spend decades worrying about it. A minor historical quibble: BCPL, at the time of C's invention, did not have `ENDCASE`; that came later. We tend to forget that BCPL did not stop evolving after C's invention; in fact, it went on as a going concern for quite a few more years. From Dennis Ritchie's HOPL paper: |Not every difference between the BCPL language documented in |Richards's book [Richards 79] and B was deliberate; we started |from an earlier version of BCPL [Richards 67]. For example, the |`endcase` that escapes from a BCPL `switchon` statement was not |present in the language when we learned it in the 1960s, and so |the overloading of the `break` keyword to escape from the B and |C `switch` statement owes to divergent evolution rather than |conscious change. (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html) Note this is the only place in that paper where Dennis Ritchie mentions `break`. Why was it overloaded for `switch`? He does not say, exactly, but he _does_ alude to space being a consideration for B, and some of the resulting syntactic quirks then escaping into C: |Storage limitations on the B compiler demanded a one-pass |technique in which output was generated as soon as possible, |and the syntactic redesign that made this possible was carried |forward into C. This is from a section discussing why C did not implement the, `valof`/`resultis` mechanism of BCPL: BCPL parsed the whole program into memory and operated on the parsed representation; B could not afford that luxury. Btw, one hypothesizes that some of the subsequent evolution of BCPL came from C influence; BCPL added the PL/1-style `/* ... */` comments, and it wouldn't surprise me if `ENDCASE` came from C's `break` inside of a `switch`, though I have no evidence of that. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-13 23:16 +0300 |
| Message-ID | <20261013231606.00003e16@yahoo.com> |
| In reply to | #403093 |
On Tue, 13 Oct 2026 10:52:55 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <11ajsfi$28f2$5@kst.eternal-september.org>, > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >[snip] > >Yes, we all know that. BCPL had BREAK and ENDCASE. B apparently > >dropped both, and then re-added just BREAK. C inherited break > >from B. I haven't seen anyone say that that wasn't a mistake. > >We just don't spend decades worrying about it. > > A minor historical quibble: BCPL, at the time of C's invention, > did not have `ENDCASE`; that came later. We tend to forget that > BCPL did not stop evolving after C's invention; in fact, it went > on as a going concern for quite a few more years. > > From Dennis Ritchie's HOPL paper: > > |Not every difference between the BCPL language documented in > |Richards's book [Richards 79] and B was deliberate; we started > |from an earlier version of BCPL [Richards 67]. For example, the > |`endcase` that escapes from a BCPL `switchon` statement was not > |present in the language when we learned it in the 1960s, and so > |the overloading of the `break` keyword to escape from the B and > |C `switch` statement owes to divergent evolution rather than > |conscious change. > (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html) > Good catch. Thank you. > Note this is the only place in that paper where Dennis Ritchie > mentions `break`. Why was it overloaded for `switch`? He does > not say, exactly, but he _does_ alude to space being a > consideration for B, and some of the resulting syntactic quirks > then escaping into C: > > |Storage limitations on the B compiler demanded a one-pass > |technique in which output was generated as soon as possible, > |and the syntactic redesign that made this possible was carried > |forward into C. > > This is from a section discussing why C did not implement the, > `valof`/`resultis` mechanism of BCPL: BCPL parsed the whole > program into memory and operated on the parsed representation; > B could not afford that luxury. > > Btw, one hypothesizes that some of the subsequent evolution of > BCPL came from C influence; BCPL added the PL/1-style > `/* ... */` comments, and it wouldn't surprise me if `ENDCASE` > came from C's `break` inside of a `switch`, though I have no > evidence of that. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 18:44 -0700 |
| Message-ID | <11ammp5$12efg$3@kst.eternal-september.org> |
| In reply to | #403093 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> Note this is the only place in that paper where Dennis Ritchie
> mentions `break`. Why was it overloaded for `switch`? He does
> not say, exactly, but he _does_ alude to space being a
> consideration for B, and some of the resulting syntactic quirks
> then escaping into C:
[...]
Pure speculation follows.
I'm skeptical that space concerns were the reasons for not having a
separate endcase keyword, though I suppose it's possible. (C had
23 keywords as of 1974.) It seems more likely that Ritchie just
didn't think of it.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 17:33 -0700 |
| Message-ID | <11aju80$28f2$6@kst.eternal-september.org> |
| In reply to | #403054 |
bart <bc@freeuk.com> writes:
[...]
> This is my first example expressed in C (note those first three args
> are passed by reference):
>
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> switch (pmtype)
> case pm_option: ...; break;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break;
>
> Except I can't use break like that. So I have to find a workaround.
The code appears to be valid C that doesn't do what you want. I can't
easily tell what you want it to do. I don't know which of the two break
statements was intended to break out of the loop. A comment would have
solved that.
I'm going to guess that the first break is supposed to apply to the
switch statement, and the second to the while loop.
You want the language to be changed to make this kind of thing easier.
That's already happening. If you take a look at the N3886 working
draft for C2y, it has named break statements. In C2y (or in gcc
if you use an extension), the above could be written as:
WHILE:
while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
SWITCH:
switch (pmtype)
case pm_option: ...; break SWITCH;
case pm_sourcefile:
if (passlevel == run_pass || passlevel == runpcl_pass) {
break WHILE;
assuming it's the second "break' that's supposed to break out of
the loop. (I'd probably use more meaninful names.)
There is already a solution for the problem you're complaining about.
(It also solves the problem of breaking out of nested loops.)
If you're unable to use this feature, you can use goto. That's not
ideal, but with well chosen label names and no backward branching
it's not too bad.
--
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-14 00:21 +0100 |
| Message-ID | <11amecs$10eab$1@dont-email.me> |
| In reply to | #403077 |
On 13/10/2026 01:33, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> This is my first example expressed in C (note those first three args
>> are passed by reference):
>>
>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>> switch (pmtype)
>> case pm_option: ...; break;
>> case pm_sourcefile:
>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>> break;
>>
>> Except I can't use break like that. So I have to find a workaround.
>
> The code appears to be valid C that doesn't do what you want. I can't
> easily tell what you want it to do. I don't know which of the two break
> statements was intended to break out of the loop. A comment would have
> solved that.
>
> I'm going to guess that the first break is supposed to apply to the
> switch statement, and the second to the while loop.
>
> You want the language to be changed to make this kind of thing easier.
>
> That's already happening. If you take a look at the N3886 working
> draft for C2y, it has named break statements. In C2y (or in gcc
> if you use an extension), the above could be written as:
>
> WHILE:
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> SWITCH:
> switch (pmtype)
> case pm_option: ...; break SWITCH;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break WHILE;
>
> assuming it's the second "break' that's supposed to break out of
> the loop. (I'd probably use more meaninful names.)
>
> There is already a solution for the problem you're complaining about.
> (It also solves the problem of breaking out of nested loops.)
>
> If you're unable to use this feature, you can use goto. That's not
> ideal, but with well chosen label names and no backward branching
> it's not too bad.
I've got a better idea. I added an extra keyword to my C compiler called
"breakloop". It's like 'break' but always works with the nearest
enclosing loop, even from inside switch.
So this example (a starts at 0):
while (1) {
switch (a++) {
case 1: puts("one"); break;
case 2: puts("two"); breakloop;
case 3: puts("three"); break;
default: puts("other");
}
if (a>40) break;
}
finishes after displaying 'two', instead of after the 37th or so 'other'.
Modding the compiler took 90 seconds, and needed 4 extra lines of code.
Setting up this test took 2-3 minutes.
Simple, yes? Then you think that this could be done even more easily 50
years ago.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 20:40 -0700 |
| Message-ID | <11amtjk$14pou$1@kst.eternal-september.org> |
| In reply to | #403132 |
bart <bc@freeuk.com> writes:
> On 13/10/2026 01:33, Keith Thompson wrote:
[...]
>> That's already happening. If you take a look at the N3886 working
>> draft for C2y, it has named break statements.
[...]
>> There is already a solution for the problem you're complaining
>> about.
>>
>> (It also solves the problem of breaking out of nested loops.)
>> If you're unable to use this feature, you can use goto. That's not
>> ideal, but with well chosen label names and no backward branching
>> it's not too bad.
>
> I've got a better idea. I added an extra keyword to my C compiler
> called "breakloop". It's like 'break' but always works with the
> nearest enclosing loop, even from inside switch.
Adding a keyword to your personal C compiler is easy. That's a tiny
fraction of the effort needed to make a change to the language.
Getting the WG14 committee to agree that your solution is a good idea,
nailing down the exact wording that describes it, and waiting for all
C compilers to implement it, is not.
Sure, your "breakloop" could work, but it's blatantly nothing more
than a workaround for one specific minor problem. Presumably if
"breakloop" appears outside a switch statement it means exactly
the same thing as "break". How are programmers to decide which
one to use? Would you want to deprecate the use of "break" other
than to break out of a switch statement?
We have decades of precedent that "break" is how you break out of a
loop. Your solution is to add a second way to do the same thing.
Sorry, but it's ugly. I'd rather use goto. And there's already
a more general solution planned for C2y.
[...]
> Simple, yes? Then you think that this could be done even more easily
> 50 years ago.
It could have been done more easily 50 years ago than now. Using,
say, "breaksw" for switch statements and "break" for loops would
have been equally easy, and a better solution that what you propose.
Allowing name for loops and switch statements is a more general
solution to this and other problems, it's already been implemented,
and it will almost certainly be standardized.
I dislike the default fallthrough behavior of switch statements.
If I were designing C today, I'd probably (a) *not* have default
fallthrough, (b) add something like a "fallthrough" keyword for
when you want it, and (c) have named loops. As of C2y, we'll have
(c) but not (a) and (b) -- and that's good enough.
--
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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 03:59 +0000 |
| Message-ID | <11amune$ipi$1@reader2.panix.com> |
| In reply to | #403132 |
In article <11amecs$10eab$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 13/10/2026 01:33, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> This is my first example expressed in C (note those first three args
>>> are passed by reference):
>>>
>>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>>> switch (pmtype)
>>> case pm_option: ...; break;
>>> case pm_sourcefile:
>>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>>> break;
>>>
>>> Except I can't use break like that. So I have to find a workaround.
>>
>> The code appears to be valid C that doesn't do what you want. I can't
>> easily tell what you want it to do. I don't know which of the two break
>> statements was intended to break out of the loop. A comment would have
>> solved that.
>>
>> I'm going to guess that the first break is supposed to apply to the
>> switch statement, and the second to the while loop.
>>
>> You want the language to be changed to make this kind of thing easier.
>>
>> That's already happening. If you take a look at the N3886 working
>> draft for C2y, it has named break statements. In C2y (or in gcc
>> if you use an extension), the above could be written as:
>>
>> WHILE:
>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>> SWITCH:
>> switch (pmtype)
>> case pm_option: ...; break SWITCH;
>> case pm_sourcefile:
>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>> break WHILE;
>>
>> assuming it's the second "break' that's supposed to break out of
>> the loop. (I'd probably use more meaninful names.)
>>
>> There is already a solution for the problem you're complaining about.
>> (It also solves the problem of breaking out of nested loops.)
>>
>> If you're unable to use this feature, you can use goto. That's not
>> ideal, but with well chosen label names and no backward branching
>> it's not too bad.
>
>I've got a better idea. I added an extra keyword to my C compiler called
>"breakloop". It's like 'break' but always works with the nearest
>enclosing loop, even from inside switch.
>
>So this example (a starts at 0):
>
> while (1) {
> switch (a++) {
> case 1: puts("one"); break;
> case 2: puts("two"); breakloop;
> case 3: puts("three"); break;
> default: puts("other");
> }
>
> if (a>40) break;
> }
>
>finishes after displaying 'two', instead of after the 37th or so 'other'.
>
>Modding the compiler took 90 seconds, and needed 4 extra lines of code.
>Setting up this test took 2-3 minutes.
>
>Simple, yes? Then you think that this could be done even more easily 50
>years ago.
Not really; for a general mechanism, if suffers from the obvious
deficiency that it doesn't compose.
For example, if the switch is inside of nested loops, and I
want to break out of everything, or I have two embedded switches
(which I have written when parsing firmware tables); I can think
of a number of instances where you might want to have switch
inside of nested loops and want to break out to function scope,
such as advancing states a la a Thompson-style NFA, where one
has a loop over the input text, a loop over the set of all
states, and a switch matching state against the current input
character, and you want to break out when you find a match.
Many other languages solve this using a "labeled break" (Go,
Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have
used a "counted"/"multi-level" break (Ruby, Perl; I think PHP).
You could have elegantly solved this problem by making `break`
take an optional integer argument, which is the number of levels
of structure to break out of. For a `switch` inside of a loop,
`break 2;` would exit both the case and the enclosing loop; for
a nested switch, `break 2;` would break out of both. Workable,
but in some respects the labeled form is better because it is
resilient to code shuffling around and changing nesting levels
and so forth.
An obvious next extension would be augmenting `continue`
similarly.
But as Keith pointed out, W14 is now entertaining proposals to
add labeled `break` to the language. I haven't looked myself,
but if that is usable in a `switch` context, then it would solve
the problem for good.
This illustrates one reason why changing a language can be hard:
your idea sounds good at first blush, but it has its own
deficiencies.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 21:35 -0700 |
| Message-ID | <11an0q3$14pou$4@kst.eternal-september.org> |
| In reply to | #403141 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> Many other languages solve this using a "labeled break" (Go,
> Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have
> used a "counted"/"multi-level" break (Ruby, Perl; I think PHP).
The only languages I know of that have a "counted break" (where
"break 2" breaks out of two levels of loops) are the Bourne shell
and shells derived from it, and PHP (you're right about that).
Perl has named break (spelled "last" or "last NAME") and continue
(spelled "next" or "next NAME). It does not have counted versions.
Ruby allows an argument on "break", but it's not the number of levels.
It specifies the value of the expression that it breaks out of. (A
loop is an expression that can yield a value.)
The latest draft of the C++ standard does not include labeled break
and continue statements. I don't know whether it's been proposed.
> You could have elegantly solved this problem by making `break`
> take an optional integer argument, which is the number of levels
> of structure to break out of.
I don't consider that elegant, for reasons I've already ranted about
here.
[...]
> But as Keith pointed out, W14 is now entertaining proposals to
> add labeled `break` to the language. I haven't looked myself,
> but if that is usable in a `switch` context, then it would solve
> the problem for good.
Yes, labeled "break" in C2y applies to both loops and switch statements.
There's also a labeled "continue" that applies only to loops.
The labels are optional, so existing code isn't broken.
The latest C2y draft is
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf>
(3.3 MB, 793 pages).
> This illustrates one reason why changing a language can be hard:
> your idea sounds good at first blush, but it has its own
> deficiencies.
--
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 | 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 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web