Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-11 22:12 +0000 |
| Articles | 20 on this page of 238 — 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 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 11:16 +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 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -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 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
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-10 11:53 +0100 |
| Message-ID | <11ad5eq$1l8hg$1@dont-email.me> |
| In reply to | #402868 |
On 10/10/2026 03:17, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 10/10/2026 01:25, Lawrence D’Oliveiro 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.
>>
>> C, doesn't specifically have fallthrough. It's just that C's switch is
>> so bizarre, 'fallthrough' is a consequence of it being so dumb it
>> doesn't know it's still inside a switch statement; it is just code
>> that it carries ploughing through until it hits more control flow.
>
> 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.
>
> Think of C's "switch", not as an inferior version of Pascal's case
> statement, but as an improved version of a computed goto.
It's not that great as computed goto either. That tended to look like this:
goto (L1, L2, L3) index
But C's switch index need not have consecutive values from 0 to N-1 or 1
to N. This C switch statement (when I first wrote it I'd forgotten the
breaks!):
switch (a) {
case 3: case 5:
b = 100;
break;
case 2:
b = 200;
break;
default:
b = 300;
}
Corresponds to this explicit jump-table using using gnu extensions for
label pointers:
void* jumptable[] = {&&def, &&def, &&case2, &&case35, &&def, &&case35};
if (a>=0 && a<=5)
goto *jumptable[a];
else
goto def;
case35:
b = 100;
goto next;
case2:
b = 200;
goto next;
def:
b = 300;
next:
(Or it can correspond, since a compiler may choose other strategies.)
And, these days 'computed goto' in C tends to means something specific,
which is a kind of looping switch but using multiple dispatch points
(each break has its own goto *jumptable) rather the regular switch's one
at the start).
The other day I posted this example from lua.c:
vmcase(OP_ADDK) {
op_arithK(L, l_addi, luai_numadd);
vmbreak;
}
vmcase and vmbreak are macros that either expand to 'case' and 'break',
or to normal labels and goto *jumptable when gnuC is detected.
(Of, course, my language has it all:
[]ref label jumptable = (L1, L2, L3) # first class labels
goto (index | L1, L2, L3 | Ldef) # 'computed goto'
switch index when... else... end # proper structured switch
doswitch index... # looping version
doswitchx index # multiple dispatch points
(So regular switch can be changed to full multi-dispatch points by
adding that 'x'.)
But then, mine's a lower level systems language where I can consider
such things fundamental. C is obviously higher level!)
> 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.
I guess the same rationale means it is stuck with for(;;) loops?
That hasn't stop C++ having a higher level version.
Yet C23 has multiple ways of specifying a 32-bit integer type:
int
int32_t
long (on some platforms)
_BitInt(32)
> Anything you could do with a more structured switch-like statement can
> be done, with just a little care, with the existing switch statement.
With a LOT more care, and with too much flexibility making it too easy
to get things wrong. You even have this:
case 10: default: case 20:
While if you want to do that multi-dispatch point stuff like the Lua
example:
* You need to rewrite a normal switch into that ugly form
* There must be conditional macros somewhere to set them according
to compiler
* A table of labels must be maintained that /exactly corresponds/ to the
enumerations used for the index
* It doesn't work in standard C so you must use extensions
> Yes, you have to remember to write "break;" at the end of each case.
>
> I haven't seen any proposals to add such a feature -- probably
> because nobody else is as angry about it as you are.
I'm angry because it was SO EASY to get right in the first place
(Algol68 and Pascal already existed), and nearly as easy to fix even
within the intervening decades.
It could also be easy to implement as structured switch can be syntactic
sugar for an if-else-if chain.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-10 14:01 +0200 |
| Message-ID | <11ad9fg$cjm0$4@dont-email.me> |
| In reply to | #402873 |
On 2026-10-10 12:53, bart wrote: > On 10/10/2026 03:17, Keith Thompson wrote: [...] >> Yes, you have to remember to write "break;" at the end of each case. >> >> I haven't seen any proposals to add such a feature -- probably >> because nobody else is as angry about it as you are. > > I'm angry because it was SO EASY to get right in the first place > (Algol68 and Pascal already existed), and nearly as easy to fix even > within the intervening decades. The C-folks had other design criteria than the Pascal or Algol 68 people; the latter two have also fundamental different concepts in their respective language (also concerning their 'case' construct). (Specifically the Algol 68 'case' isn't very progressive, being restricted to - even implicit! - integer tags from 1 to some N.) I think the problem with your statement is also that you think your preferred construct is the only one that is "right". (You seem to be confident that supporting "fall-though" is generally "wrong".) Just imagine if some C-programmers wanted a fall-through semantics but all they got would be the Pascal or Algol 68 'case' construct. I also want to remind Kornshell's break/fall-though options in their 'case', not as bulky as 'break' but yet more punctuation characters (that makes it, if not somewhat cryptic, at least easy to overlook). (I'm using both options, in Shell and in "C". And I cannot do that [as simply as in "C"] in Pascal or Algol 68, where I then [have to] use other code patterns.) Whichever language; they have design principles. Buy them or switch. (Unintended "switch" pun.) You may blame the respective language if you have problems with it. But I have a general (and well meant) suggestion for you... If you notice that you are doing specific mistakes repeatedly - and where you cannot change "the environment" of your mistake! - train your awareness! (That's more successful a strategy than persistent whining about it; i.e. if you're interested to get your tasks done.) Janis PS (disclaimer): That all said, I still think the approach in "C" is a low level pattern. In other programming language I'm using their respective patterns within their language design principles. - Some minimum mental _flexibility_ is certainly required from programmers if they want to (or have to) use different types of languages. > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-10 14:11 +0100 |
| Message-ID | <11addhr$1oakb$1@dont-email.me> |
| In reply to | #402874 |
On 10/10/2026 13:01, Janis Papanagnou wrote:
> On 2026-10-10 12:53, bart wrote:
>> On 10/10/2026 03:17, Keith Thompson wrote:
> [...]
>>> Yes, you have to remember to write "break;" at the end of each case.
>>>
>>> I haven't seen any proposals to add such a feature -- probably
>>> because nobody else is as angry about it as you are.
>>
>> I'm angry because it was SO EASY to get right in the first place
>> (Algol68 and Pascal already existed), and nearly as easy to fix even
>> within the intervening decades.
>
> The C-folks had other design criteria than the Pascal or Algol 68
> people; the latter two have also fundamental different concepts in
> their respective language (also concerning their 'case' construct).
> (Specifically the Algol 68 'case' isn't very progressive, being
> restricted to - even implicit! - integer tags from 1 to some N.)
I forgot the A68 version wasn't quite the same. But both will have a
properly structured form, where the aim is execute one of N possible
blocks. After executing that block, control escapes the enclosing statement.
The C aim is to pass control to one of N possible locations, but there
are virtually no rules about where those locations can be within the
statement following 'switch()', and it doesn't care what happens from
then on.
> I think the problem with your statement is also that you think your
> preferred construct is the only one that is "right". (You seem to
> be confident that supporting "fall-though" is generally "wrong".)
Yes. Why, you think that fall-through is right AND should be the default
behaviour?
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.
Note that if-statement blocks don't have fall-through either when there
is an else branch. Imagine having to write this:
if (cond) {
statement;
break;
} else {
statement;
}
because C was crazy enough to fall through to the else block unless
'break' was added!
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.
> 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.
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.
This way, BLOCKS CAN BE REORDERED without changing behaviour.
This is an important point: a switch statement where every case block
ends with 'break', can have those case blocks appear in any order. Or
new ones can be inserted anywhere. Blocks commented out, deleted etc etc.
But that all goes out the window as soon as fall-through is used.
> You may blame the respective language if you have problems with it.
> But I have a general (and well meant) suggestion for you...
> If you notice that you are doing specific mistakes repeatedly - and
> where you cannot change "the environment" of your mistake! - train
> your awareness! (That's more successful a strategy than persistent
> whining about it; i.e. if you're interested to get your tasks done.)
>
> Janis
>
> PS (disclaimer): That all said, I still think the approach in "C" is
> a low level pattern.
The kind of structured switch I favour is still low level! After all it
basically a jump.
It is not the structural or parametric kind of pattern matching you find
in Rust etc.
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.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-10 21:34 +0800 |
| Message-ID | <n9ryS.11350$Nbkf.9077@fx03.ams4> |
| In reply to | #402875 |
On 10/10/2026 9:11 PM, bart wrote: > because C was crazy enough to fall through to the else block unless > 'break' was added! > > 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. It's been some years, so my memory is hazy, but the original C.P.L. language "specification" or manual had all case: examples with an ex- plicit return. I'm not even sure they had thought through exactly how the semantics were meant to work, when they figured they couldn't make a compiler after all. Then BCPL happened -- IIRC it happened before they had a working CPL compiler -- and I expect that one had the fall through we're used to, but bear in mind if you look at the most recent manual that it's not the same compiler that predates B, and the rest is history. You can of course ask Martin Richards, and maybe he still remembers if the C.P.L. people had something else in mind. Good luck. -- 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 | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-10 21:58 +0800 |
| Message-ID | <KvryS.192386$xra3.145895@fx16.ams4> |
| In reply to | #402878 |
On 10/10/2026 9:34 PM, Johann 'Myrkraverk' Oskarsson wrote: > On 10/10/2026 9:11 PM, bart wrote: >> because C was crazy enough to fall through to the else block unless >> 'break' was added! >> >> 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. > > It's been some years, so my memory is hazy, but the original C.P.L. > language "specification" or manual had all case: examples with an ex- > plicit return. I'm not even sure they had thought through exactly how > the semantics were meant to work, when they figured they couldn't make a > compiler after all. > > Then BCPL happened -- IIRC it happened before they had a working CPL > compiler -- and I expect that one had the fall through we're used to, > but bear in mind if you look at the most recent manual that it's not > the same compiler that predates B, and the rest is history. > > > You can of course ask Martin Richards, and maybe he still remembers if > the C.P.L. people had something else in mind. Good luck. Sort of. My memory was a bit off. See pages 122, and a bit onwards; then 127 for the "definition" which to me is inconclusive. https://www.ancientgeek.org.uk/CPL/CPL_Working_Papers.pdf Best wishes, and happy learning of the C.P.L. programming language. -- 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-10 17:50 +0200 |
| Message-ID | <11admri$1s1lb$1@dont-email.me> |
| In reply to | #402875 |
On 10/10/2026 15:11, bart wrote: > On 10/10/2026 13:01, Janis Papanagnou wrote: >> On 2026-10-10 12:53, bart wrote: >>> On 10/10/2026 03:17, Keith Thompson wrote: >> [...] > >> I think the problem with your statement is also that you think your >> preferred construct is the only one that is "right". (You seem to >> be confident that supporting "fall-though" is generally "wrong".) > > Yes. Why, you think that fall-through is right AND should be the default > behaviour? > > 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. > Keith explained the background for C's switch. It has its origins in a time when "goto" was commonly used, and it is a significant improvement on many uses of calculated goto. It is not "bizarre", dangerous, or "dumb" - or "wrong". It is simple /different/ from the structured switch/case/match construct found in many other languages. The choice was made long ago, and it must be obvious to everyone that the behaviour could not be changed. This makes it flexible - you can do things with C's "switch" that you cannot do with Pascal "case". That means you can do some different, interesting and useful things - and it also means you can make some different and annoying mistakes. You point out that most C code uses "switch" in a structured manner, with "break" rather than implicit fall-through. That is my experience too. What does that tell us? I think it tells us two things : 1. People don't have a problem writing structured code with C's switch statements, using "break" as appropriate. It works fine for that purpose. It's fair, I think, to say that forgetting a "break" is a source of error found in C programming but not in languages with a more structured equivalent construct - but it is an error that is easily found by common tools, and will normally be found in testing otherwise. "Missing break" bugs do make it into the wild sometimes, but I could not find evidence that it ranks high in the statistics. 2. C programmers would mostly also have been fine with a structured "switch" where each "case" had its own block and there was no fall-through. There are, however, occasional exceptions and more complicated code. Such use-cases would need to be handled in other ways if C's switch did not work as it does. My gut feeling is that a solid proportion of such cases were more relevant in the old days before more optimising compilers - things like Duff's Device spring to mind as being useful long ago, but unnecessary with modern tools. I personally would have been happier if C's switch was more structured and had no fall-through (obviously it would still need a way to have multiple cases attached to the same sub-block). Does that mean I think C's switch is "wrong", or a bad design? No, it does not. Even if I did think it was wrong, would that mean that it /is/ wrong? No, it would not - an opinion is not a fact. Like a great many things in life, we can simply say that C's "switch" might have been a little more convenient if it had been defined in a different manner, and when making a new switch-like concept in a new language we would probably make different choices. But it is what it is, and it's not hard to use it for correct code, so why make a fuss about it? No amount of wailing and gnashing of teeth here is going to change anything. To re-enforce another of Keith's points, it /would/ be possible to add a new switch-like construct to C with more structure and no fall-through. But it would provide very little benefit, and simply make the language that little bit more complicated - existing "switch" would obviously not be removed. It's a different matter for other languages. In C++, there is a lot that can be gained from a more powerful pattern-matching construct, so there is a lot of work going on to add it to the language. But that is not a replacement for "switch" - it is primarily targeting class hierarchies (match on different types in the hierarchy), variants (safe union types, also known as "summation" types), and other features that do not have correspondence with C. In C++ there is a lot to be gained here by a more powerful construct - the lack of implicit fall-through is a very minor detail. For C, there would not be enough benefit - maybe it could be used to replace _Generic for some uses, but that's not worth the effort.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-11 05:52 +0000 |
| Message-ID | <11af87h$1m4em$1@paganini.bofh.team> |
| In reply to | #402880 |
David Brown <david.brown@hesbynett.no> wrote:
> On 10/10/2026 15:11, bart wrote:
>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>> On 2026-10-10 12:53, bart wrote:
>>>> On 10/10/2026 03:17, Keith Thompson wrote:
>>> [...]
>>
>>> I think the problem with your statement is also that you think your
>>> preferred construct is the only one that is "right". (You seem to
>>> be confident that supporting "fall-though" is generally "wrong".)
>>
>> Yes. Why, you think that fall-through is right AND should be the default
>> behaviour?
>>
>> 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.
>>
> Keith explained the background for C's switch. It has its origins in a
> time when "goto" was commonly used, and it is a significant improvement
> on many uses of calculated goto. It is not "bizarre", dangerous, or
> "dumb" - or "wrong". It is simple /different/ from the structured
> switch/case/match construct found in many other languages. The choice
> was made long ago, and it must be obvious to everyone that the behaviour
> could not be changed.
>
> This makes it flexible - you can do things with C's "switch" that you
> cannot do with Pascal "case". That means you can do some different,
> interesting and useful things - and it also means you can make some
> different and annoying mistakes.
AFAICS Pascal-style 'case' + 'goto' that can jump inside constructs
can do everthing C 'switch' can do. Falltrough is just jump to
another case, disallowed in Pascal, but legal in C. Similarly,
other unstructured uses of 'switch' could be done using combination
of structured 'switch' and 'goto'. Structured uses are much more
frequent, so really there is no argument for C-style 'switch' except
for backward compatibility (which is deciding argument).
> 2. C programmers would mostly also have been fine with a structured
> "switch" where each "case" had its own block and there was no
> fall-through. There are, however, occasional exceptions and more
> complicated code. Such use-cases would need to be handled in other ways
> if C's switch did not work as it does. My gut feeling is that a solid
> proportion of such cases were more relevant in the old days before more
> optimising compilers - things like Duff's Device spring to mind as being
> useful long ago, but unnecessary with modern tools.
Using 'goto' + structured 'switch' one needs only two optimizations to
get the same code as from C 'switch':
1) 'goto' to instruction directly following it should be deleted,
2) if body of a case consists of single 'goto' for this case
'switch' should transfer control to the target of 'goto'.
Those are very simple optimizations and could be included in
rather small compiler (like one running on PDP-11).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-11 21:16 +0000 |
| Message-ID | <11aguaq$30k5e$4@dont-email.me> |
| In reply to | #402940 |
On Sun, 11 Oct 2026 05:52:51 -0000 (UTC), Waldek Hebisch wrote: > AFAICS Pascal-style 'case' + 'goto' that can jump inside constructs > can do everthing C 'switch' can do. There is an interesting result known as the “Structure Theorem”, which proves that any kind of control structure can be implemented by putting your entire program inside a large switch-statement within a loop and using state variables to control which path is taken each time round the loop -- with no gotos anywhere! Of course, since it can be hard to discern the relationship between one switch-branch being executed on one loop iteration and whatever switch-branch is entered on the next iteration, the result is still a form of spaghetti code ...
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-11 23:38 +0000 |
| Message-ID | <11ah6ll$1pjp4$1@paganini.bofh.team> |
| In reply to | #403005 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 11 Oct 2026 05:52:51 -0000 (UTC), Waldek Hebisch wrote:
>
>> AFAICS Pascal-style 'case' + 'goto' that can jump inside constructs
>> can do everthing C 'switch' can do.
>
> There is an interesting result known as the “Structure Theorem”, which
> proves that any kind of control structure can be implemented by
> putting your entire program inside a large switch-statement within a
> loop and using state variables to control which path is taken each
> time round the loop -- with no gotos anywhere!
>
> Of course, since it can be hard to discern the relationship between
> one switch-branch being executed on one loop iteration and whatever
> switch-branch is entered on the next iteration, the result is still a
> form of spaghetti code ...
Unlike structure theorem the above does not need extra state variable.
BTW: Good compiler should be able to eliminate state varible and
recreate original spagetti, but no compiler that I use is good
enough.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 11:58 +0100 |
| Message-ID | <11afq4b$2idte$1@dont-email.me> |
| In reply to | #402880 |
On 10/10/2026 16:50, David Brown wrote:
> On 10/10/2026 15:11, bart wrote:
>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>> On 2026-10-10 12:53, bart wrote:
>>>> On 10/10/2026 03:17, Keith Thompson wrote:
>>> [...]
>>
>>> I think the problem with your statement is also that you think your
>>> preferred construct is the only one that is "right". (You seem to
>>> be confident that supporting "fall-though" is generally "wrong".)
>>
>> Yes. Why, you think that fall-through is right AND should be the
>> default behaviour?
>>
>> 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.
>>
> Keith explained the background for C's switch. It has its origins in a
> time when "goto" was commonly used, and it is a significant improvement
> on many uses of calculated goto. It is not "bizarre", dangerous, or
> "dumb" - or "wrong". It is simple /different/ from the structured
> switch/case/match construct found in many other languages. The choice
> was made long ago, and it must be obvious to everyone that the behaviour
> could not be changed.
>
> This makes it flexible - you can do things with C's "switch" that you
> cannot do with Pascal "case". That means you can do some different,
> interesting and useful things - and it also means you can make some
> different and annoying mistakes.
>
> You point out that most C code uses "switch" in a structured manner,
> with "break" rather than implicit fall-through. That is my experience
> too. What does that tell us? I think it tells us two things :
>
> 1. People don't have a problem writing structured code with C's switch
> statements, using "break" as appropriate. It works fine for that purpose.
We don't know that, we just see the end result.
The best one say about C-switch is that it can emulate a real switch
statement. But when reading unfamiliar code, you can't be as confident
as to the author's intentions: is that an ordinary switch, or is there
something odd about it?
A bit like looking at a 'busy' for-statement header and trying to
determine, is this a simple iteration, or is there something else going on?
Because unfortunately C's flexibility makes weird stuff possible.
C's 'switch' is truly bizarre. Below is an experiment where I took an
ordinary function body, and wrapped 'switch' around it with randomly
placed case labels.
It still worked (as I placed 'default:' near the start, and providing
'm' is greater than 7), but What The Hell?
gcc with warnings says nothing useful about it.
> There are, however, occasional exceptions and more complicated
> code. Such use-cases would need to be handled in other ways if C's
> switch did not work as it does. My gut feeling is that a solid
> proportion of such cases were more relevant in the old days before more
> optimising compilers - things like Duff's Device spring to mind as being
> useful long ago, but unnecessary with modern tools.
This is the core C code for Duff's Device from Wikipedia:
switch (count % 8) {
case 0: *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
}
This is the emulation of it in my language ('to' is a reserved word, and
that constuct is 1-based):
goto (count rem 8| L1, L2, L3, L4, L5, L6, L7 | L0)
L0: d^ := s++^
L7: d^ := s++^
L6: d^ := s++^
L5: d^ := s++^
L4: d^ := s++^
L3: d^ := s++^
L2: d^ := s++^
L1: d^ := s++^
Those labels need to be unique, but probably you won't need more than
one Duff's Device in any one function.
This could be done in C too via existing extensions.
> I personally would have been happier if C's switch was more structured
> and had no fall-through (obviously it would still need a way to have
> multiple cases attached to the same sub-block).
>Does that mean I think
> C's switch is "wrong", or a bad design? No, it does not. Even if I did
> think it was wrong, would that mean that it /is/ wrong? No, it would
> not - an opinion is not a fact.
That is astounding. But then, how many other languages, which have
copied all sorts of dubious features from C, have also duplicated its
bizarre switch statement?
That should tell you more.
> Like a great many things in life, we can simply say that C's "switch"
> might have been a little more convenient if it had been defined in a
> different manner,
I suggest you try the same exercise I did.
and when making a new switch-like concept in a new
> language we would probably make different choices. But it is what it
> is, and it's not hard to use it for correct code, so why make a fuss
> about it? No amount of wailing and gnashing of teeth here is going to
> change anything.
>
>
> To re-enforce another of Keith's points, it /would/ be possible to add a
> new switch-like construct to C with more structure and no fall-through.
I posted a proposal for such a statement in a reply to Keith Thompson,
who completely dismissed it.
The fall-through feature is a minor detail.
-----------------------
static void nsieve(int m) {
unsigned int count = 0, i, j;
boolean * flags = (boolean *) malloc(m * sizeof(boolean));
for (i = 0; i < m; ++i) flags[i]=1;
for (i = 2; i < m; ++i)
if (flags[i]) {
++count;
for (j = i << 1; j < m; j += i)
flags[j] = 0;
}
free(flags);
printf("Primes up to %8u %8u\n", m, count);
}
static void nsieve_sw(int m) {
switch (m) {
default:
case 1:
unsigned int count = 0, i, j;
case 2:
boolean * flags = (boolean *) malloc(m * sizeof(boolean));
for (i = 0; i < m; ++i)
case 3:
flags[i]=1;
for (i = 2; i < m; ++i)
if (flags[i]) {
case 4:
++count;
case 5:
for (j = i << 1; j < m; j += i)
case 6:
flags[j] = 0;
}
free(flags);
case 7:
printf("Primes up to %8u %8u\n", m, count);
}
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-11 14:42 +0200 |
| Message-ID | <11ag08f$2k9do$1@dont-email.me> |
| In reply to | #402971 |
On 11/10/2026 12:58, bart wrote: > On 10/10/2026 16:50, David Brown wrote: >> On 10/10/2026 15:11, bart wrote: >>> On 10/10/2026 13:01, Janis Papanagnou wrote: >>>> On 2026-10-10 12:53, bart wrote: >>>>> On 10/10/2026 03:17, Keith Thompson wrote: >>>> [...] >>> >>>> I think the problem with your statement is also that you think your >>>> preferred construct is the only one that is "right". (You seem to >>>> be confident that supporting "fall-though" is generally "wrong".) >>> >>> Yes. Why, you think that fall-through is right AND should be the >>> default behaviour? >>> >>> 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. >>> >> Keith explained the background for C's switch. It has its origins in >> a time when "goto" was commonly used, and it is a significant >> improvement on many uses of calculated goto. It is not "bizarre", >> dangerous, or "dumb" - or "wrong". It is simple /different/ from the >> structured switch/case/match construct found in many other languages. >> The choice was made long ago, and it must be obvious to everyone that >> the behaviour could not be changed. >> >> This makes it flexible - you can do things with C's "switch" that you >> cannot do with Pascal "case". That means you can do some different, >> interesting and useful things - and it also means you can make some >> different and annoying mistakes. >> >> You point out that most C code uses "switch" in a structured manner, >> with "break" rather than implicit fall-through. That is my experience >> too. What does that tell us? I think it tells us two things : >> >> 1. People don't have a problem writing structured code with C's switch >> statements, using "break" as appropriate. It works fine for that >> purpose. > > We don't know that, we just see the end result. I don't think there is anything much you can say about that without sidetracking to a definition of what we mean by "a problem", and then doing a massive survey of lots of C programmers. We do know that C is a massively successful programming language, used by vast numbers of people, and that switch statements are common in C. This is true regardless of any real or imagined "problem" with C's switch statements. > >> There are, however, occasional exceptions and more complicated >> code. Such use-cases would need to be handled in other ways if C's >> switch did not work as it does. My gut feeling is that a solid >> proportion of such cases were more relevant in the old days before >> more optimising compilers - things like Duff's Device spring to mind >> as being useful long ago, but unnecessary with modern tools. > > This is the core C code for Duff's Device from Wikipedia: > We know what Duff's Device is, and no one cares about your language. It is not an alternative to C in any way. >> I personally would have been happier if C's switch was more structured >> and had no fall-through (obviously it would still need a way to have >> multiple cases attached to the same sub-block). > >> Does that mean I think C's switch is "wrong", or a bad design? No, it >> does not. Even if I did think it was wrong, would that mean that it / >> is/ wrong? No, it would not - an opinion is not a fact. > > That is astounding. But then, how many other languages, which have > copied all sorts of dubious features from C, have also duplicated its > bizarre switch statement? > > That should tell you more. We could pick a dozen different real-world languages, with a dozen different kinds of switch, case, match or other multiple choice construct (or lack thereof). That should tell you that there is no "right" or "wrong" choice here - there are different design choices, with different pros and cons, different flexibilities and limitations, and appropriate for different kinds of language and different kinds of tools. > >> Like a great many things in life, we can simply say that C's "switch" >> might have been a little more convenient if it had been defined in a >> different manner, > > I suggest you try the same exercise I did. I suggest you find something better to spend your time on than re-hashes of your obsessions about what you don't like about C. > > and when making a new switch-like concept in a new >> language we would probably make different choices. But it is what it >> is, and it's not hard to use it for correct code, so why make a fuss >> about it? No amount of wailing and gnashing of teeth here is going to >> change anything. >> >> >> To re-enforce another of Keith's points, it /would/ be possible to add >> a new switch-like construct to C with more structure and no fall-through. > > I posted a proposal for such a statement in a reply to Keith Thompson, > who completely dismissed it. > Keith is a big boy, and responsible for his own opinions and posts - it is not my place to defend his writing. However, I entirely agree with him in that post. It would be possible to add a more structured switch-like statement to C, without fall-through, but doing so would be detrimental to the language as a whole as the disadvantages and added complexity would not be balanced by significant added usability or let you write code in a significantly better way.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 14:39 +0100 |
| Message-ID | <11ag3ia$2m2aj$1@dont-email.me> |
| In reply to | #402977 |
On 11/10/2026 13:42, David Brown wrote:
> On 11/10/2026 12:58, bart wrote:
>> We don't know that, we just see the end result.
>
> I don't think there is anything much you can say about that without
> sidetracking to a definition of what we mean by "a problem", and then
> doing a massive survey of lots of C programmers.
>
> We do know that C is a massively successful programming language, used
> by vast numbers of people, and that switch statements are common in C.
> This is true regardless of any real or imagined "problem" with C's
> switch statements.
I know that, despite the success, a vast amount of effort has to be
spent to keep on top of or to get around all its problems, and there may
yet be bugs we don't know about due to them.
I can see that from looking at other forums at the things people have
trouble with, that wouldn't happen with a tidier and less quirky language.
>
>>
>>> There are, however, occasional exceptions and more complicated
>>> code. Such use-cases would need to be handled in other ways if C's
>>> switch did not work as it does. My gut feeling is that a solid
>>> proportion of such cases were more relevant in the old days before
>>> more optimising compilers - things like Duff's Device spring to mind
>>> as being useful long ago, but unnecessary with modern tools.
>>
>> This is the core C code for Duff's Device from Wikipedia:
>>
>
> We know what Duff's Device is, and no one cares about your language. It
> is not an alternative to C in any way.
It doesn't matter. The point is that Duff's Device is always given as an
example to show how wonderful it is to have default fall-through in C,
even though in the vast majority of cases, 'break' has to be used to
inhibit it.
Yet there are other ways to express the same thing using other features.
(BTW gcc gives me fall-through warnings on that Duff's example. How do
you shut that up while keeping them for other code?)
>> That should tell you more.
>
> We could pick a dozen different real-world languages, with a dozen
> different kinds of switch, case, match or other multiple choice
> construct (or lack thereof). That should tell you that there is no
> "right" or "wrong" choice here - there are different design choices,
> with different pros and cons, different flexibilities and limitations,
> and appropriate for different kinds of language and different kinds of
> tools.
This is a line from my C compiler written in my language:
doswitch lxsptr++^
when 'A'..'Z', 'a'..'z', '$', '_' then ...
This is what I'd have to write to express the same thing in standard C:
while (1)
switch (*lxsptr++) {
case 'A': case 'B': case 'C': case 'D': case 'E': case 'F': case 'G':
case 'H': case 'I': case 'J': case 'K': case 'L': case 'M': case 'N':
case 'O': case 'P': case 'Q': case 'R': case 'S': case 'T': case 'U':
case 'V': case 'W': case 'X': case 'Y': case 'Z':
case 'a': case 'b': case 'c': case 'd': case 'e': case 'f': case 'g':
case 'h': case 'i': case 'j': case 'k': case 'l': case 'm': case 'n':
case 'o': case 'p': case 'q': case 'r': case 's': case 't': case 'u':
case 'v': case 'w': case 'x': case 'y': case 'z':
case '0': case '1': case '2': case '3': case '4': case '5': case '6':
case '7': case '8': case '9': case '_': case '$': ...
So, what are the pros here? As I can't see any, only cons.
> I suggest you find something better to spend your time on than re-hashes
> of your obsessions about what you don't like about C.
Actually it is fascinating seeing people defend ludicrously bad (to say
nothing of unergonomic) language features like this, and vigorously
reject any suggestions of improvement.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-11 15:35 -0700 |
| Message-ID | <11ah2v2$329bt$1@kst.eternal-september.org> |
| In reply to | #402981 |
bart <bc@freeuk.com> writes:
> On 11/10/2026 13:42, David Brown wrote:
[...]
>> We know what Duff's Device is, and no one cares about your
>> language. It is not an alternative to C in any way.
>
> It doesn't matter. The point is that Duff's Device is always given as
> an example to show how wonderful it is to have default fall-through in
> C, even though in the vast majority of cases, 'break' has to be used
> to inhibit it.
No, it is not.
Here's what Tom Duff himself wrote about it in 1988:
Disgusting, no? But it compiles and runs just fine. I feel
a combination of pride and revulsion at this discovery. If no
one's thought of it before, I think I'll name it after myself.
It amazes me that after 10 years of writing C there are still
little corners that I haven't explored fully. (Actually, I have
another revolting way to use switches to implement interrupt
driven state machines but it's too horrid to go into.)
Many people (even bwk?) have said that the worst feature of C is
that switches don't break automatically before each case label.
This code forms some sort of argument in that debate, but I'm
not sure whether it's for or against.
https://doc.cat-v.org/bell_labs/duffs_device
> Yet there are other ways to express the same thing using other features.
Are there? Duff himself was unable to find a more efficient
algorithm -- and this was in a (rare) context where efficiency
was more important than clarity.
> (BTW gcc gives me fall-through warnings on that Duff's example. How do
> you shut that up while keeping them for other code?)
The ways to inhibit gcc's warnings about implicit fallthrough have
already been discussed in this thread. But you've said before
that you don't care about gcc, so I won't try yet again to teach you
about how to use it.
[...]
> Actually it is fascinating seeing people defend ludicrously bad (to
> say nothing of unergonomic) language features like this, and
> vigorously reject any suggestions of improvement.
When someone here explains how something works, you think they're
vigorously defending it.
Yes, the implicit fallthrough in C's switch statements a misfeature.
I do not support suggestions to "fix" it because no such fix would
actually improve the language.
--
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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-11 14:42 +0000 |
| Message-ID | <11ag78a$1nqv3$1@paganini.bofh.team> |
| In reply to | #402971 |
bart <bc@freeuk.com> wrote:
> On 10/10/2026 16:50, David Brown wrote:
>> On 10/10/2026 15:11, bart wrote:
>
> Because unfortunately C's flexibility makes weird stuff possible.
>
> C's 'switch' is truly bizarre. Below is an experiment where I took an
> ordinary function body, and wrapped 'switch' around it with randomly
> placed case labels.
>
> It still worked (as I placed 'default:' near the start, and providing
> 'm' is greater than 7), but What The Hell?
>
> gcc with warnings says nothing useful about it.
>
<snip>
> The fall-through feature is a minor detail.
>
> -----------------------
>
> static void nsieve(int m) {
> unsigned int count = 0, i, j;
> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
> for (i = 0; i < m; ++i) flags[i]=1;
>
> for (i = 2; i < m; ++i)
> if (flags[i]) {
> ++count;
> for (j = i << 1; j < m; j += i)
> flags[j] = 0;
> }
>
> free(flags);
> printf("Primes up to %8u %8u\n", m, count);
> }
>
> static void nsieve_sw(int m) {
> switch (m) {
> default:
> case 1:
> unsigned int count = 0, i, j;
> case 2:
> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
> for (i = 0; i < m; ++i)
> case 3:
> flags[i]=1;
>
> for (i = 2; i < m; ++i)
> if (flags[i]) {
> case 4:
> ++count;
> case 5:
> for (j = i << 1; j < m; j += i)
> case 6:
> flags[j] = 0;
> }
>
> free(flags);
> case 7:
> printf("Primes up to %8u %8u\n", m, count);
> }
> }
>
I am disappointed by gcc optimizations (at least by gcc-12). gcc
should notice that m equal to 3 immediately leads to use of
uninitialized variable, so is undefined behaviour. Similarly
m equal to 6. When m equals 4 or m equals 5 then test for
containing loop will lead to use of uninitialized variable.
AFAICS m equal 1 and m equal 2 are useless. gcc should assume
that there is no undefined behaviour, so the only remaining
case is m = 7. So gcc could simplify this function quite a lot.
But looking at assembly shows that gcc generated actual switch
with 5 cases (corresponding to m being 3, 4, 5, 6, 7).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 17:23 +0100 |
| Message-ID | <11agd65$2pscf$1@dont-email.me> |
| In reply to | #402984 |
On 11/10/2026 15:42, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 10/10/2026 16:50, David Brown wrote:
>>> On 10/10/2026 15:11, bart wrote:
>>
>> Because unfortunately C's flexibility makes weird stuff possible.
>>
>> C's 'switch' is truly bizarre. Below is an experiment where I took an
>> ordinary function body, and wrapped 'switch' around it with randomly
>> placed case labels.
>>
>> It still worked (as I placed 'default:' near the start, and providing
>> 'm' is greater than 7), but What The Hell?
>>
>> gcc with warnings says nothing useful about it.
>>
> <snip>
>> The fall-through feature is a minor detail.
>>
>> -----------------------
>>
>> static void nsieve(int m) {
>> unsigned int count = 0, i, j;
>> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
>> for (i = 0; i < m; ++i) flags[i]=1;
>>
>> for (i = 2; i < m; ++i)
>> if (flags[i]) {
>> ++count;
>> for (j = i << 1; j < m; j += i)
>> flags[j] = 0;
>> }
>>
>> free(flags);
>> printf("Primes up to %8u %8u\n", m, count);
>> }
>>
>> static void nsieve_sw(int m) {
>> switch (m) {
>> default:
>> case 1:
>> unsigned int count = 0, i, j;
>> case 2:
>> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
>> for (i = 0; i < m; ++i)
>> case 3:
>> flags[i]=1;
>>
>> for (i = 2; i < m; ++i)
>> if (flags[i]) {
>> case 4:
>> ++count;
>> case 5:
>> for (j = i << 1; j < m; j += i)
>> case 6:
>> flags[j] = 0;
>> }
>>
>> free(flags);
>> case 7:
>> printf("Primes up to %8u %8u\n", m, count);
>> }
>> }
>>
>
> I am disappointed by gcc optimizations (at least by gcc-12). gcc
> should notice that m equal to 3 immediately leads to use of
> uninitialized variable, so is undefined behaviour. Similarly
> m equal to 6. When m equals 4 or m equals 5 then test for
> containing loop will lead to use of uninitialized variable.
> AFAICS m equal 1 and m equal 2 are useless. gcc should assume
> that there is no undefined behaviour, so the only remaining
> case is m = 7. So gcc could simplify this function quite a lot.
> But looking at assembly shows that gcc generated actual switch
> with 5 cases (corresponding to m being 3, 4, 5, 6, 7).
>
My gcc 14 eliminates the entire function with -O3!
If I remove the 'static', the jumptable stays in, but it is only 5 elements.
If 'static' is left in but it is called as nsieve_sw(10000000) from
elsewhere, then it is inlined and the switch disappears.
BTW, nsieve_sw(10000000) takes gcc -O1/2/3 0.15 seconds to run.
With BCC (needs some labels to end with ";") the full jumptable stays
in, it is not inlined, but it also takes 0.15 seconds (when 'boolean' is
unsigned char).
The switch and call is a one-time cost, and the benchmark is memory
intensive, so it is kind to poor optimisers.
(But TCC takes 0.3s because locals reside in memory. Still, it is only
2:1 slower than optimised C. My scripting language takes 0.9s when using
a bit-array. Lua/CPython take 2.7/2.5s using default numeric type.)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-11 17:48 +0000 |
| Message-ID | <11agi5a$1oe5j$1@paganini.bofh.team> |
| In reply to | #402989 |
bart <bc@freeuk.com> wrote:
> On 11/10/2026 15:42, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 10/10/2026 16:50, David Brown wrote:
>>>> On 10/10/2026 15:11, bart wrote:
>>>
>>> Because unfortunately C's flexibility makes weird stuff possible.
>>>
>>> C's 'switch' is truly bizarre. Below is an experiment where I took an
>>> ordinary function body, and wrapped 'switch' around it with randomly
>>> placed case labels.
>>>
>>> It still worked (as I placed 'default:' near the start, and providing
>>> 'm' is greater than 7), but What The Hell?
>>>
>>> gcc with warnings says nothing useful about it.
>>>
>> <snip>
>>> The fall-through feature is a minor detail.
>>>
>>> -----------------------
>>>
>>> static void nsieve(int m) {
>>> unsigned int count = 0, i, j;
>>> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
>>> for (i = 0; i < m; ++i) flags[i]=1;
>>>
>>> for (i = 2; i < m; ++i)
>>> if (flags[i]) {
>>> ++count;
>>> for (j = i << 1; j < m; j += i)
>>> flags[j] = 0;
>>> }
>>>
>>> free(flags);
>>> printf("Primes up to %8u %8u\n", m, count);
>>> }
>>>
>>> static void nsieve_sw(int m) {
>>> switch (m) {
>>> default:
>>> case 1:
>>> unsigned int count = 0, i, j;
>>> case 2:
>>> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
>>> for (i = 0; i < m; ++i)
>>> case 3:
>>> flags[i]=1;
>>>
>>> for (i = 2; i < m; ++i)
>>> if (flags[i]) {
>>> case 4:
>>> ++count;
>>> case 5:
>>> for (j = i << 1; j < m; j += i)
>>> case 6:
>>> flags[j] = 0;
>>> }
>>>
>>> free(flags);
>>> case 7:
>>> printf("Primes up to %8u %8u\n", m, count);
>>> }
>>> }
>>>
>>
>> I am disappointed by gcc optimizations (at least by gcc-12). gcc
>> should notice that m equal to 3 immediately leads to use of
>> uninitialized variable, so is undefined behaviour. Similarly
>> m equal to 6. When m equals 4 or m equals 5 then test for
>> containing loop will lead to use of uninitialized variable.
>> AFAICS m equal 1 and m equal 2 are useless. gcc should assume
>> that there is no undefined behaviour, so the only remaining
>> case is m = 7. So gcc could simplify this function quite a lot.
>> But looking at assembly shows that gcc generated actual switch
>> with 5 cases (corresponding to m being 3, 4, 5, 6, 7).
>>
>
> My gcc 14 eliminates the entire function with -O3!
>
> If I remove the 'static', the jumptable stays in, but it is only 5 elements.
Of course I removed 'static'. A single 'static' function which is
never called should be removed.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 19:10 +0100 |
| Message-ID | <11agjff$2sf17$1@dont-email.me> |
| In reply to | #402991 |
On 11/10/2026 18:48, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 11/10/2026 15:42, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>> static void nsieve_sw(int m) {
>>>> switch (m) {
>>>> default:
>>>> case 1:
>>>> unsigned int count = 0, i, j;
>>>> case 2:
>>>> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
>>>> for (i = 0; i < m; ++i)
>>>> case 3:
>>>> flags[i]=1;
>>>>
>>>> for (i = 2; i < m; ++i)
>>>> if (flags[i]) {
>>>> case 4:
>>>> ++count;
>>>> case 5:
>>>> for (j = i << 1; j < m; j += i)
>>>> case 6:
>>>> flags[j] = 0;
>>>> }
>>>>
>>>> free(flags);
>>>> case 7:
>>>> printf("Primes up to %8u %8u\n", m, count);
>>>> }
>>>> }
>>>>
>>>
>>> I am disappointed by gcc optimizations (at least by gcc-12). gcc
>>> should notice that m equal to 3 immediately leads to use of
>>> uninitialized variable, so is undefined behaviour. Similarly
>>> m equal to 6. When m equals 4 or m equals 5 then test for
>>> containing loop will lead to use of uninitialized variable.
>>> AFAICS m equal 1 and m equal 2 are useless. gcc should assume
>>> that there is no undefined behaviour, so the only remaining
>>> case is m = 7. So gcc could simplify this function quite a lot.
>>> But looking at assembly shows that gcc generated actual switch
>>> with 5 cases (corresponding to m being 3, 4, 5, 6, 7).
>>>
>>
>> My gcc 14 eliminates the entire function with -O3!
>>
>> If I remove the 'static', the jumptable stays in, but it is only 5 elements.
>
> Of course I removed 'static'. A single 'static' function which is
> never called should be removed.
If I do this:
static void nsieve_sw(int m) { ... }
static void* abc = nsieve_sw;
int main(void) {
abc = nsieve_sw;
}
then nsieve_sw is never called, but it is not removed. It /is/ removed
if 'abc' is moved into main().
Apart from that anomaly, only the potential to call even a static
function needs to exist, say by taking its address. The function might
never be called though.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-12 07:01 +0000 |
| Message-ID | <11ai0jt$206ko$1@paganini.bofh.team> |
| In reply to | #402993 |
bart <bc@freeuk.com> wrote:
> On 11/10/2026 18:48, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 11/10/2026 15:42, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
>
>>>>> static void nsieve_sw(int m) {
>>>>> switch (m) {
>>>>> default:
>>>>> case 1:
>>>>> unsigned int count = 0, i, j;
>>>>> case 2:
>>>>> boolean * flags = (boolean *) malloc(m * sizeof(boolean));
>>>>> for (i = 0; i < m; ++i)
>>>>> case 3:
>>>>> flags[i]=1;
>>>>>
>>>>> for (i = 2; i < m; ++i)
>>>>> if (flags[i]) {
>>>>> case 4:
>>>>> ++count;
>>>>> case 5:
>>>>> for (j = i << 1; j < m; j += i)
>>>>> case 6:
>>>>> flags[j] = 0;
>>>>> }
>>>>>
>>>>> free(flags);
>>>>> case 7:
>>>>> printf("Primes up to %8u %8u\n", m, count);
>>>>> }
>>>>> }
>>>>>
>>>>
>>>> I am disappointed by gcc optimizations (at least by gcc-12). gcc
>>>> should notice that m equal to 3 immediately leads to use of
>>>> uninitialized variable, so is undefined behaviour. Similarly
>>>> m equal to 6. When m equals 4 or m equals 5 then test for
>>>> containing loop will lead to use of uninitialized variable.
>>>> AFAICS m equal 1 and m equal 2 are useless. gcc should assume
>>>> that there is no undefined behaviour, so the only remaining
>>>> case is m = 7. So gcc could simplify this function quite a lot.
>>>> But looking at assembly shows that gcc generated actual switch
>>>> with 5 cases (corresponding to m being 3, 4, 5, 6, 7).
>>>>
>>>
>>> My gcc 14 eliminates the entire function with -O3!
>>>
>>> If I remove the 'static', the jumptable stays in, but it is only 5 elements.
>>
>> Of course I removed 'static'. A single 'static' function which is
>> never called should be removed.
>
> If I do this:
>
> static void nsieve_sw(int m) { ... }
>
> static void* abc = nsieve_sw;
>
> int main(void) {
> abc = nsieve_sw;
> }
>
> then nsieve_sw is never called, but it is not removed. It /is/ removed
> if 'abc' is moved into main().
Another missing optimization.
> Apart from that anomaly, only the potential to call even a static
> function needs to exist, say by taking its address. The function might
> never be called though.
Sure, if compiler can not decide (say due to taken address) if a
function is called, then it should keep it. But the case above is
an easy one. And in other contexts gcc actually can do transfomations
that require rather complex reasoning to justify.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 16:41 +0100 |
| Message-ID | <11aganl$2oslb$1@dont-email.me> |
| In reply to | #402971 |
On 11/10/2026 11:58, bart wrote:
> On 10/10/2026 16:50, David Brown wrote:
> This is the core C code for Duff's Device from Wikipedia:
>
> switch (count % 8) {
> case 0: *to = *from++;
> case 7: *to = *from++;
> case 6: *to = *from++;
> case 5: *to = *from++;
> case 4: *to = *from++;
> case 3: *to = *from++;
> case 2: *to = *from++;
> case 1: *to = *from++;
> }
>
> This is the emulation of it in my language ('to' is a reserved word, and
> that constuct is 1-based):
>
> goto (count rem 8| L1, L2, L3, L4, L5, L6, L7 | L0)
>
> L0: d^ := s++^
> L7: d^ := s++^
> L6: d^ := s++^
> L5: d^ := s++^
> L4: d^ := s++^
> L3: d^ := s++^
> L2: d^ := s++^
> L1: d^ := s++^
>
> Those labels need to be unique, but probably you won't need more than
> one Duff's Device in any one function.
Here is it in my language after 10 minutes' work to create a
fall-through version of my switch:
switchf count rem 8
when 0 then d^ := s++^
when 7 then d^ := s++^
when 6 then d^ := s++^
when 5 then d^ := s++^
when 4 then d^ := s++^
when 3 then d^ := s++^
when 2 then d^ := s++^
when 1 then d^ := s++^
end
It remains properly structured, but the block order is now important.
The feature will not be kept.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-10 20:08 +0200 |
| Message-ID | <11aduuk$cjlv$1@dont-email.me> |
| In reply to | #402875 |
On 2026-10-10 15:11, bart wrote:
> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>[...]
>
> I forgot the A68 version wasn't quite the same. But both will have a
> properly structured form, where the aim is execute one of N possible
> blocks.
N(+1), yes. (And not "blocks", but that's a detail.)
> After executing that block, control escapes the enclosing statement.
Unless other things happen, yes.
>
> The C aim is to pass control to one of N possible locations, but there
> are virtually no rules about where those locations can be within the
> statement following 'switch()', and it doesn't care what happens from
> then on.
Yes, that's quite a mess (IMO), but that is how it's got designed.
>
>> I think the problem with your statement is also that you think your
>> preferred construct is the only one that is "right". (You seem to
>> be confident that supporting "fall-though" is generally "wrong".)
>
> Yes. Why, you think that fall-through is right AND should be the default
> behaviour?
But I don't think so and haven't made any such claim.
I expressed that your view of what is "right" or "wrong" is futile,
it makes no sense, and is not more than an opinion.
I explained that lacking the features makes it necessary to emulate
it where needed. (That's an annoyance for those that want it.)
>
> 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).
>
> 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; I firmly suggest to try to stop
that, as to not again get another thread stray and out of focus.)
>
> 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 - 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
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.)
>
>> 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.
(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.)
> This way, BLOCKS CAN BE REORDERED without changing behaviour.
Fine for you.
>
> This is an important point: a switch statement where every case block
> ends with 'break', can have those case blocks appear in any order. Or
> new ones can be inserted anywhere. Blocks commented out, deleted etc etc.
>
> But that all goes out the window as soon as fall-through is used.
I understand that it interferes with some of your design decisions.
>> [...]
>
> The kind of structured switch I favour is still low level! After all it
> basically a jump.
Well, I certainly favor sensible _abstractions_ to low-level jumps.
(Ideally the abstract language concepts are efficiently representable
by the processors; I like the basic Pascal design in that respect.)
>
> It is not the structural or parametric kind of pattern matching you find
> in Rust etc.
(I don't know Rust.)
>
> 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).
Janis
[*] In the GNU version of Awk - a much simpler but higher abstracted
language - you can nicely compare strings, and even regexps.
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web