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 301 — 21 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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +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 bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
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 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 19:52 +0100 |
| Message-ID | <11ajaa1$3ssqg$1@dont-email.me> |
| In reply to | #403048 |
On 12/10/2026 19:46, Scott Lurndal wrote: > cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <11aidi3$3gbu4$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> On 12/10/2026 06:22, David Brown wrote: >>>> On 12/10/2026 00:05, bart wrote: >>> > >> I kinda sorta agree that requiring `break` between `case` >> statements in C was an historical mistake, but here we are: it >> is 2026, and the language has done that for more than 50 years >> now. The ship for changing it has sailed. What is one left to >> do, besides acknowledging it as a wart on the face of the >> langauge? > > I, on the other hand, don't consider it a mistake, in the > context of the C and C++ languages. I've used the ability to > fall through in a significant fraction (50% in some applications) of > the switch statements that I've written over the last > five decades of C and C++programming. So 99% of programmers have to suffer needing to pointlessly write 'break' everywhere, rather than the 1% having to write 'fallthru'. Although it sounds like even you need fall-through less often than break.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-12 19:42 +0000 |
| Message-ID | <KKazS.183759$ygUb.92831@fx23.iad> |
| In reply to | #403049 |
bart <bc@freeuk.com> writes: >On 12/10/2026 19:46, Scott Lurndal wrote: >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >>> In article <11aidi3$3gbu4$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>> On 12/10/2026 06:22, David Brown wrote: >>>>> On 12/10/2026 00:05, bart wrote: >>>> >> >>> I kinda sorta agree that requiring `break` between `case` >>> statements in C was an historical mistake, but here we are: it >>> is 2026, and the language has done that for more than 50 years >>> now. The ship for changing it has sailed. What is one left to >>> do, besides acknowledging it as a wart on the face of the >>> langauge? >> >> I, on the other hand, don't consider it a mistake, in the >> context of the C and C++ languages. I've used the ability to >> fall through in a significant fraction (50% in some applications) of >> the switch statements that I've written over the last >> five decades of C and C++programming. > >So 99% of programmers have to suffer Please, speak for yourself. You have no clue what programmers[*] think, or whether they suffer from the requirement to use 'break' to avoid falling through to the next case. [*] You, being atypical, are particularly ill-suited to speak for others.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 16:29 -0700 |
| Message-ID | <11ajqhc$28f2$2@kst.eternal-september.org> |
| In reply to | #403049 |
bart <bc@freeuk.com> writes:
[...]
> So 99% of programmers have to suffer needing to pointlessly write
> 'break' everywhere, rather than the 1% having to write 'fallthru'.
We're not suffering.
Speaking for myself, I had to learn *once*, several decades ago,
that each case needs to end with "break;" (unless I want fallthrough
behavior). As I've mentioned here before, I pretend that the "break;"
is part of the syntax of a switch statement, while being aware that
it really isn't.
It's easy, and it doesn't hurt a bit. I'll bet it would be easy
for you if (a) you regularly wrote C code (I don't know how often
you do) and (b) you didn't go out of your way to suffer on other
people's behalf.
--
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 00:53 +0100 |
| Message-ID | <11ajrt0$382u$1@dont-email.me> |
| In reply to | #403070 |
On 13/10/2026 00:29, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> So 99% of programmers have to suffer needing to pointlessly write
>> 'break' everywhere, rather than the 1% having to write 'fallthru'.
>
> We're not suffering.
>
I was replying to SL who doesn't think auto-fall-through is a mistake
because he uses it a lot. Even though he says this:
"I've used the ability to fall through in a significant fraction (50% in
some applications) of the switch statements"
So 50% /sometimes/, and not even individual case-blocks, but of those
switch statements which use at least one fall-through, if I read that right.
So even for him, the majority of case-labels do not fall through.
That makes it rather strange to favour the minority case when it would
be more convenient and less typing for everybody, including SL, if it
was the other way around!
> Speaking for myself, I had to learn *once*, several decades ago,
> that each case needs to end with "break;" (unless I want fallthrough
> behavior). As I've mentioned here before, I pretend that the "break;"
> is part of the syntax of a switch statement, while being aware that
> it really isn't.
>
> It's easy, and it doesn't hurt a bit. I'll bet it would be easy
> for you if (a) you regularly wrote C code (I don't know how often
> you do) and (b) you didn't go out of your way to suffer on other
> people's behalf.
>
This is what I suggested in my first reply in the thread:
break; case a: case b:
break; case c:
break; default:;
That is, use 'break; case' for the first case label of a block.
And also:
"Alternately, create a macro like 'endcase' that expands to 'break', for
a more structured appearance."
These are practical workarounds. That 'break; case' was part of a
solution I used for a 20Kloc C application.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 18:14 -0700 |
| Message-ID | <11ak0lr$28f2$7@kst.eternal-september.org> |
| In reply to | #403074 |
bart <bc@freeuk.com> writes:
> On 13/10/2026 00:29, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> So 99% of programmers have to suffer needing to pointlessly write
>>> 'break' everywhere, rather than the 1% having to write 'fallthru'.
>> We're not suffering.
>
> I was replying to SL who doesn't think auto-fall-through is a mistake
> because he uses it a lot.
[...]
And I was replying to your deeply silly claim that 99% of C programmers
"suffer" because we need to use "break" in switch statements.
[...]
> That makes it rather strange to favour the minority case when it would
> be more convenient and less typing for everybody, including SL, if it
> was the other way around!
Sure, it's strange. A small minority of C programmers might prefer
to have fallthrough as the default. The majority, I suspect, *would
have* preferred not to have fallthrough as the default.
Nobody other than you, as far as I can tell, thinks that the strange
choice made several decades ago has led to mass suffering.
[...]
> This is what I suggested in my first reply in the thread:
>
> break; case a: case b:
> break; case c:
> break; default:;
>
> That is, use 'break; case' for the first case label of a block.
Yes, I suppose that would work, but frankly it looks weird. If
you want to use that pattern in your own code, nobody is going to
stop you. It reminds me of "Yoda conditions" (if (42 == x)), an
ugly coding practice that might make it slightly easier to avoid
a certain kind of error.
> And also:
>
> "Alternately, create a macro like 'endcase' that expands to 'break',
> for a more structured appearance."
All C programmers know that "break;" is how you terminate a case
if you don't want fallthrough. A macro that expands to "break"
doesn't help anything. I have to look up the definition to be sure
it's not doing something weird, and it doesn't address any of the
problems you've been complaining about. And of course you still
have to remember that "break" in a switch in a loop doesn't break
out of the loop. It appears to be an attempt to make C look like
some other language, something I've never found to be a good idea.
But again, if you want to use your "endcase" macro, nobody will
stop you.
--
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-12 22:35 +0000 |
| Message-ID | <11ajnc4$f7l$1@reader2.panix.com> |
| In reply to | #403048 |
In article <5W9zS.161421$98z8.84067@fx33.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <11aidi3$3gbu4$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>On 12/10/2026 06:22, David Brown wrote: >>>> On 12/10/2026 00:05, bart wrote: >>> > >>I kinda sorta agree that requiring `break` between `case` >>statements in C was an historical mistake, but here we are: it >>is 2026, and the language has done that for more than 50 years >>now. The ship for changing it has sailed. What is one left to >>do, besides acknowledging it as a wart on the face of the >>langauge? > >I, on the other hand, don't consider it a mistake, in the >context of the C and C++ languages. I've used the ability to >fall through in a significant fraction (50% in some applications) of >the switch statements that I've written over the last >five decades of C and C++programming. Yeah, that's why I'm waffling by only "kinda sorta" agreeing, while means I'm also "kinda sorta" disagreeing. :-D Personally, I think that the BCPL `valof`/`resultis` thing is pretty cool and would have liked to see something like that in C, which in many ways would have subsumed this and other issues. But I honestly doubt they could have fit that into a C compiler meant to run on a PDP-11/20. >Absent other changes to the syntax (e.g. non-contiguous ranges >in the case selector[*]) the requirement to use break to avoid >falling through to other cases is rather valuable to me. I, too, would have liked to have seen ranges and mulitiple case values, at least. Rust has this, and it is genuinely useful. You can even do something analogous to duff's device in Rust, but it's hideous: https://huonw.github.io/blog/2025/03/rust-fallthrough/ Man, that sure looks like it got whacked by an ugly-stick, don't it? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 16:14 -0700 |
| Message-ID | <11ajpkj$28f2$1@kst.eternal-september.org> |
| In reply to | #403029 |
bart <bc@freeuk.com> writes:
> On 12/10/2026 06:22, David Brown wrote:
>> On 12/10/2026 00:05, bart wrote:
>>> So you don't really get it. That's fine.
>>>
>> So now you can drop it, along with all your other complaints about
>> the C language and tools people use with it?
>
> My opinions haven't changed at all. KT doesn't care because he doesn't
> understand the importance of having properly designed
> features. Probably he hasn't been involved in having to process
> somebody else's source code or having to translate it or port it.
I've speculated here about your motivations, so I suppose it's fair
that you speculate about mine.
You're completely wrong.
If someone doesn't agree with you, it's not necessarily because they
don't understand something fundamental. It could be because they're
right and you're wrong. You don't seem to consider that possibility.
[...]
--
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 22:36 +0100 |
| Message-ID | <11agvhl$31ftr$1@dont-email.me> |
| In reply to | #402930 |
On 11/10/2026 02:12, bart wrote:
> Having proper structure must make code analysis simpler than effectively
> having a bunch of case labels randomly scattered through the code.
>
> Example:
>
> newswitch (expr)
> case 3, 4, 5:
> stmt1;
> case 6...10, 12:
> stmt2;
> else
> stmt3;
>
> I think this is OK except for the possibility of that 'else' being
> attached to stmt2 when that ends with 'if (cond) stmt;'.
It might have more problems than that, due to not having 'closure'. That
is, delimiting that might be done by 'end' or via indents in some
languages, or by '}' here.
I would prefer not to have enclose the whole body in braces. But as it
is, then here:
newswitch()
case // 1
newswitch()
case
case // 3
case // 4
it's not clear, when there is no 'else' part, whether case(4) continues
that second switch and from case(3) or the first and case(1), and there
is no way to disambiguate.
OK, not a big problem, it's not hard to fix. Fortunately I'm not going
to implement it.
(BTW I had a look at an old versions of my language, and it seems it
didn't acquire 'switch' until quite late.
Instead there was another, more flexible statement:
* This worked for scalar types ints, floats and pointers
* Test values could be runtime expressions
* Comparisons were done sequentially
* The whole thing could return a value and be used in expressions, or
be the last statement of a value-returning function.
I believe 'switch' was introduced as an explicit streamlined version with:
* Only 'int' expressions
* Test values had to be compile-time constants
* Comparisons were expected to be done in parallel, and via
a jump-table.
Having two forms was considered simpler than the compiler trying to
analyse the one kind of statement, and silently /not/ using a jumptable
due to some oversight.)
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-10-10 13:14 +0000 |
| Message-ID | <11addmq$3k6om$1@news.xmission.com> |
| In reply to | #402868 |
In article <11ac783$1bkuo$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: ... >The ANSI C Rationale says "No serious consideration was given to >making the switch more structured, as in Pascal, out of fear of >invalidating working code". > >I suppose some version of C could have defined a new switch-like >statement without the fallthrough behavior. I can see some small >advantages in doing so, but the existing switch with fallthrough >would have to be kept in the language -- and such a new switch-like >statement would have added no real expressive power. We'd now have >a mix of code using the old and new constructs, pressure to convert >existing working code, and probably errors introduced by converting >code incorrectly. You are probably right that C itself will never have such a construct added (*). But the point is that there are many C-derived languages - languages that use C's basic syntax (especially, using curly braces). C++/C#/Swift - probably others. These languages are free to have (and probably do) have better switch/case/whatever-you-want-to-call-it constructs. (*) Although I certainly think it would benefit from doing so. -- To be evangelical is to spend every waking moment hovering around two emotional states: fear and rage. Evangelicals are seriously the angriest and most vicious bunch of self-pitying, constantly-moaning whinybutts I've ever encountered.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-10 19:50 +0300 |
| Message-ID | <20261010195051.00000594@yahoo.com> |
| In reply to | #402868 |
On Fri, 09 Oct 2026 19:17:35 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >BCPL's predecessor, CPL, I fully agree with your post (plus have to add that "more structured switch" apart from new keyword(s) will need some new way to express common handler for several cases. Ada/VHDL solution of using | would not work in C for obvious reasons). But for sentence above I have a nitpick. CPL is an ancestor of BCPL, but not a predecessor. Historically BCPL was implemented before CPL. I am not even sure that CPL was ever implemented entirely.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-10 20:13 +0200 |
| Message-ID | <11adv82$cjlv$2@dont-email.me> |
| In reply to | #402883 |
On 2026-10-10 18:50, Michael S wrote: > > I fully agree with your post (plus have to add that "more structured > switch" apart from new keyword(s) will need some new way to express > common handler for several cases. Ada/VHDL solution of using | would > not work in C for obvious reasons). Pascal allows '..' and ',' (for ranges and lists), and even mixed. That should (in principle) be a syntactical possibility in "C". Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 15:54 -0700 |
| Message-ID | <11aefo0$24k8m$2@kst.eternal-september.org> |
| In reply to | #402888 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-10 18:50, Michael S wrote:
>> I fully agree with your post (plus have to add that "more structured
>> switch" apart from new keyword(s) will need some new way to express
>> common handler for several cases. Ada/VHDL solution of using | would
>> not work in C for obvious reasons).
>
> Pascal allows '..' and ',' (for ranges and lists), and even mixed.
> That should (in principle) be a syntactical possibility in "C".
C2Y will add case ranges using "..." (which is already a token used for
variadic functions), with syntax and semantics close to the existing gcc
extension.
switch (foo) {
case 'a' ... 'z':
// ...
}
This was considered and rejected (with "..") for C89. One reason for
rejecting it was that 'A'..'Z' is not contiguous in all character
sets (particularly not in EBCDIC). The C89 Rationale also mentions
the problem of large code or jump table space for something like
0..65535, something that can be handled these days by minimally
clever compilers.
One problem is that `case 0...1:` is a syntax error. 0...1 is a valid
preprocessing number that can't be converted to a valid constant.
The solution is to surround the ... with spaces, which is probably
a good idea anyway.
As for ',', that would avoid having to repeat the "case" keyword,
but it could be visually confusing. `case 0, 1:` is currently a
syntax error, but only because a constant expression can't include
a comma operator (with some obscure exceptions). Allowing commas
would prevent a future version of the language from either allowing
comma operators in constant expressions or permitting non-constant
expressions in case labels. I still wouldn't mind such a change,
but it would add no real expressive power and I don't think anyone
has proposed 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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-11 03:41 +0200 |
| Message-ID | <11aepgb$286ml$1@dont-email.me> |
| In reply to | #402920 |
On 2026-10-11 00:54, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-10-10 18:50, Michael S wrote:
>>> I fully agree with your post (plus have to add that "more structured
>>> switch" apart from new keyword(s) will need some new way to express
>>> common handler for several cases. Ada/VHDL solution of using | would
>>> not work in C for obvious reasons).
>>
>> Pascal allows '..' and ',' (for ranges and lists), and even mixed.
>> That should (in principle) be a syntactical possibility in "C".
>
> C2Y will add case ranges using "..." (which is already a token used for
> variadic functions), with syntax and semantics close to the existing gcc
> extension.
>
> switch (foo) {
> case 'a' ... 'z':
> // ...
> }
>
> This was considered and rejected (with "..") for C89. One reason for
> rejecting it was that 'A'..'Z' is not contiguous in all character
> sets (particularly not in EBCDIC). The C89 Rationale also mentions
> the problem of large code or jump table space for something like
> 0..65535, something that can be handled these days by minimally
> clever compilers.
>
> One problem is that `case 0...1:` is a syntax error. 0...1 is a valid
> preprocessing number that can't be converted to a valid constant.
> The solution is to surround the ... with spaces, which is probably
> a good idea anyway.
>
> As for ',', that would avoid having to repeat the "case" keyword,
> but it could be visually confusing. `case 0, 1:` is currently a
> syntax error, but only because a constant expression can't include
> a comma operator (with some obscure exceptions). Allowing commas
> would prevent a future version of the language from either allowing
> comma operators in constant expressions or permitting non-constant
> expressions in case labels. I still wouldn't mind such a change,
> but it would add no real expressive power and I don't think anyone
> has proposed it.
Thanks for the interesting background information.
Your explanation shows how difficult it is to add features (even if
they are comparably simple appearing ones) to an existing language;
many things have to be considered, interdependencies, and also an
educated thought about future consequences.
It's certainly a lot easier if you can design a language from scratch.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-11 09:51 +0800 |
| Message-ID | <zYByS.21374$VDn8.5260@fx14.ams4> |
| In reply to | #402932 |
On 10/11/2026 9:41 AM, Janis Papanagnou wrote:
> On 2026-10-11 00:54, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 2026-10-10 18:50, Michael S wrote:
>>>> I fully agree with your post (plus have to add that "more structured
>>>> switch" apart from new keyword(s) will need some new way to express
>>>> common handler for several cases. Ada/VHDL solution of using | would
>>>> not work in C for obvious reasons).
>>>
>>> Pascal allows '..' and ',' (for ranges and lists), and even mixed.
>>> That should (in principle) be a syntactical possibility in "C".
>>
>> C2Y will add case ranges using "..." (which is already a token used for
>> variadic functions), with syntax and semantics close to the existing gcc
>> extension.
>>
>> switch (foo) {
>> case 'a' ... 'z':
>> // ...
>> }
>>
>> This was considered and rejected (with "..") for C89. One reason for
>> rejecting it was that 'A'..'Z' is not contiguous in all character
>> sets (particularly not in EBCDIC). The C89 Rationale also mentions
>> the problem of large code or jump table space for something like
>> 0..65535, something that can be handled these days by minimally
>> clever compilers.
>>
>> One problem is that `case 0...1:` is a syntax error. 0...1 is a valid
>> preprocessing number that can't be converted to a valid constant.
>> The solution is to surround the ... with spaces, which is probably
>> a good idea anyway.
>>
>> As for ',', that would avoid having to repeat the "case" keyword,
>> but it could be visually confusing. `case 0, 1:` is currently a
>> syntax error, but only because a constant expression can't include
>> a comma operator (with some obscure exceptions). Allowing commas
>> would prevent a future version of the language from either allowing
>> comma operators in constant expressions or permitting non-constant
>> expressions in case labels. I still wouldn't mind such a change,
>> but it would add no real expressive power and I don't think anyone
>> has proposed it.
>
> Thanks for the interesting background information.
>
> Your explanation shows how difficult it is to add features (even if
> they are comparably simple appearing ones) to an existing language;
> many things have to be considered, interdependencies, and also an
> educated thought about future consequences.
>
> It's certainly a lot easier if you can design a language from scratch.
>
> Janis
Dear Javis,
Even then, people screw up, such as Java's lack of labelled /break/s in-
side switch () statements. I guess they were afraid of /goto/s, and
chose to use /break/ instead, with this annoying side effect.
[Ok, I'll probably want to review that before I post more about it, but
I have faith in my recollection.]
C++ has removed some features from C++98, and again from C++11 if I re-
call correctly, so it's not like people don't screw up from time to
time.
I've not used C# extensively enough to encounter problem spots, so
people here in comp.lang.c are welcome to chime in.
My personal guess is that it would be better for everyone, if program-
ming languages didn't escape the laboratory until at least one more non-
trivial project other than the compiler is near completion or finished.
What do you think?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-11 11:41 +0200 |
| Message-ID | <11aflk7$2g8ft$1@dont-email.me> |
| In reply to | #402932 |
On 11/10/2026 03:41, Janis Papanagnou wrote:
> On 2026-10-11 00:54, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 2026-10-10 18:50, Michael S wrote:
>>>> I fully agree with your post (plus have to add that "more structured
>>>> switch" apart from new keyword(s) will need some new way to express
>>>> common handler for several cases. Ada/VHDL solution of using | would
>>>> not work in C for obvious reasons).
>>>
>>> Pascal allows '..' and ',' (for ranges and lists), and even mixed.
>>> That should (in principle) be a syntactical possibility in "C".
>>
>> C2Y will add case ranges using "..." (which is already a token used for
>> variadic functions), with syntax and semantics close to the existing gcc
>> extension.
>>
>> switch (foo) {
>> case 'a' ... 'z':
>> // ...
>> }
>>
>> This was considered and rejected (with "..") for C89. One reason for
>> rejecting it was that 'A'..'Z' is not contiguous in all character
>> sets (particularly not in EBCDIC). The C89 Rationale also mentions
>> the problem of large code or jump table space for something like
>> 0..65535, something that can be handled these days by minimally
>> clever compilers.
>>
>> One problem is that `case 0...1:` is a syntax error. 0...1 is a valid
>> preprocessing number that can't be converted to a valid constant.
>> The solution is to surround the ... with spaces, which is probably
>> a good idea anyway.
>>
>> As for ',', that would avoid having to repeat the "case" keyword,
>> but it could be visually confusing. `case 0, 1:` is currently a
>> syntax error, but only because a constant expression can't include
>> a comma operator (with some obscure exceptions). Allowing commas
>> would prevent a future version of the language from either allowing
>> comma operators in constant expressions or permitting non-constant
>> expressions in case labels. I still wouldn't mind such a change,
>> but it would add no real expressive power and I don't think anyone
>> has proposed it.
>
> Thanks for the interesting background information.
>
> Your explanation shows how difficult it is to add features (even if
> they are comparably simple appearing ones) to an existing language;
> many things have to be considered, interdependencies, and also an
> educated thought about future consequences.
>
The comma operator turns up often as a hinder to syntax extension in
C-like languages - disproportional, I think, to its usage in "typical" C
code. As a clear example, C++ had to deprecate its usage in subscript
operators so that they could later support a multi-dimensional subscript
operator. "m[x, y]" meant "evaluate x, throw away the result, then
evaluate m.operator[](y)" instead of the more useful "m.operator[](x, y)".
Still, C has the comma operator, some people like it, some code uses it,
and it is not going anywhere. And it would be nice if C can continue to
avoid C++ style special exception rules.
> It's certainly a lot easier if you can design a language from scratch.
>
Yes. Or if you can, like Bart, just change your language to suit, or
put in whatever inconsistencies and ambiguities you like because you
know exactly how programmers will use the language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 16:44 -0700 |
| Message-ID | <11aeilp$24k8m$5@kst.eternal-september.org> |
| In reply to | #402883 |
Michael S <already5chosen@yahoo.com> writes:
> On Fri, 09 Oct 2026 19:17:35 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>BCPL's predecessor, CPL,
>
> I fully agree with your post (plus have to add that "more structured
> switch" apart from new keyword(s) will need some new way to express
> common handler for several cases. Ada/VHDL solution of using | would
> not work in C for obvious reasons).
>
> But for sentence above I have a nitpick. CPL is an ancestor of BCPL,
> but not a predecessor. Historically BCPL was implemented before CPL. I
> am not even sure that CPL was ever implemented entirely.
Interesting. I've read some of the documents that describe CPL/BCPL/B,
but I'm not familiar with how they were actually implemented and used.
--
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:56 -0700 |
| Message-ID | <11aejbh$24k8m$6@kst.eternal-september.org> |
| In reply to | #402868 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> C's switch statement is essentially a computed goto. It goes back
> to BCPL (1967), which had different syntax (SWITCHON, CASE, ENDCASE)
> but similar semantics. BCPL's predecessor, CPL, had a more explicit
> computed goto that could be used in the same way; the target of a
> "go to" could be a label expression.
[...]
I realize I skipped over an entire language.
C's immediate ancestor B had the same switch/case/break syntax as C.
Ken Thompson's B manual, from 1972, doesn't mention "break" (for
either switch statements or loops), and apparently required "goto"
to break out of a loop or switch statement. There's a sample program
with a switch statement that uses "goto" on each case, but it jumps
to the top of a loop, not to the bottom of the switch.
Kernighan's B tutorial does use "break". Apparently "break" was
added to the language some time after the manual was written.
B's parent BCPL had both "BREAK" and "ENDCASE". Apparently both
were dropped when B was designed, and then only one was reintroduced.
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/kbman.html
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/kbman.pdf
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/btut.html
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/btut.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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-11 21:26 +0000 |
| Message-ID | <11aguua$30k5e$5@dont-email.me> |
| In reply to | #402866 |
On Sat, 10 Oct 2026 00:25:54 -0000 (UTC), I wrote:
> For comparison, here is an example of Python’s match-statement. Like
> all the good (i.e. non-C-based) designs, the designers saw no point in
> having fall-through.
>
> This is a very simple example, involving straight matching of values
> against instances of an enum. There are also more complex
> pattern-matching options available.
Here’s an example that matches the type of the match-expression (not
its value) against various event subclasses:
events = iter(self.ws.events())
while True :
event = next(events, None)
if event == None :
break
match event :
case wsevents.AcceptConnection() :
self.logger.debug("connection accepted")
#end case
case wsevents.RejectConnection() :
raise RuntimeError \
(
"WebSockets connection rejected: code %d" % event.status_code
)
#end case
case wsevents.CloseConnection() :
self.logger.debug("connection closing")
if not self.closing :
self.closing = True
if ASYNC :
await self.sock.sendall(self.sock, self.ws.send(event.response()))
else :
self.sock.sendall(self.sock, self.ws.send(event.response()))
#end if
#end if
#end case
case wsevents.Ping() :
if ASYNC :
await self.sock.sendall(self.ws.send(event.response()))
else :
self.sock.sendall(self.ws.send(event.response()))
#end if
#end case
case wsevents.TextMessage() :
self.partial += event.data
if not event.message_finished :
break
if self.partial != "" :
result = json.loads(self.partial)
self.partial = ""
else :
result = None
#end if
yield result
#end case
case _ :
raise RuntimeError \
(
"unexpected WebSocket event %s -- %s"
%
(type(event).__name__, repr(event))
)
#end case
#end match
#end while
It is permissible to mix all the different kinds of matches in
different case-clauses within the same match-statement.
I’m still getting used to the match-statement, and I’m currently
thinking of dropping the “#end case” line, since each case-clause is
implicitly terminated by the following one (or the end of the
match-statement) anyway. The “#end match” will stay, of course.
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.eu> |
|---|---|
| Date | 2026-10-11 22:12 +0000 |
| Message-ID | <slrn11co2em.2af.jon+usenet@raven.unequivocal.eu> |
| In reply to | #403006 |
On 2026-10-11, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> Here’s an example that matches the type of the match-expression (not
> its value) against various event subclasses:
>
> events = iter(self.ws.events())
> while True :
> event = next(events, None)
> if event == None :
> break
Um.
Why would you do that and not:
for event in self.ws.events():
?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-13 22:00 +0000 |
| Message-ID | <11am9m9$ul56$3@dont-email.me> |
| In reply to | #402866 |
On Sat, 10 Oct 2026 00:25:54 -0000 (UTC), I wrote:
> For comparison, here is an example of Python’s match-statement. Like
> all the good (i.e. non-C-based) designs, the designers saw no point
> in having fall-through.
>
> This is a very simple example, involving straight matching of values
> against instances of an enum. There are also more complex
> pattern-matching options available.
Another, slightly more involved example, where the matching is against
the components of a tuple. This is from a parser for the Varlink
interface definition language. Note the use of the “_” wildcard to
indicate don’t-care parts of matches:
match token.value, token.rule_name :
case "[]", _ :
nexttoken()
valtype = parse_typedef(None)
result = ArrayType(name, valtype)
case "[string]", _ :
nexttoken()
valtype = parse_typedef(None)
result = DictType(name, valtype)
case _, "elttypedef" :
result = parse_elttypedef(name)
case _, "typedef" :
result = parse_typedef(name)
case _ :
raise AssertionError \
(
"unrecognized typedef token %s: %s"
%
(token.rule_name, repr(token.value))
)
#end match
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web