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 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-15 05:17 -0700 |
| Message-ID | <86bj8vqhtl.fsf@linuxsc.com> |
| In reply to | #403173 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >> On 14/10/2026 20:30, Dan Cross wrote: >> [snip more of the same already hashed and rehashed ad naseum] >> >> As for multiple nested loops, this will fix that too, that's great. We >> just require some real examples of that being needed! > > Here's a pretty terrible way to write part of a lexical > analyzer. I just typed this in an hour or so ago. > > [200+ lines of code] This code provides an excellent example of why multi-level breaks should not be added to C. The code would be easier to understand if all the 'break <label>;' lines were replaced with one of 'goto TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate, and with the loop labels being removed and the two new labels put in at the appropriate places.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-15 14:37 +0000 |
| Message-ID | <11aqoep$82u$1@reader2.panix.com> |
| In reply to | #403187 |
In article <86bj8vqhtl.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> >>> On 14/10/2026 20:30, Dan Cross wrote: >>> [snip more of the same already hashed and rehashed ad naseum] >>> >>> As for multiple nested loops, this will fix that too, that's great. We >>> just require some real examples of that being needed! >> >> Here's a pretty terrible way to write part of a lexical >> analyzer. I just typed this in an hour or so ago. >> >> [200+ lines of code] > >This code provides an excellent example of why multi-level breaks >should not be added to C. It is probably true that this snippet is a good example of how labeled break/continue can be abused. The code is awful. However, the current C2y draft standard already has labeled break and continue; the probability that it won't make it into the next standard revision is low. Moreover, other languages have had it for years (in some cases, decades) at this point and the sky has not fallen. One bad example, meant only to illustrate a couple of use cases, should not be used as evidence either way to draw a general conclusion about, well, anything. >The code would be easier to understand >if all the 'break <label>;' lines were replaced with one of 'goto >TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate, >and with the loop labels being removed and the two new labels put >in at the appropriate places. Whenever one says that, "the code would be easier to understand" one is necessarily making a subjective judgement. In this case, _I_ think that code would be far easier to understand written in an entirely different way that didn't reach for `goto` at all. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-15 20:50 +0200 |
| Message-ID | <11ar7a6$206gg$1@dont-email.me> |
| In reply to | #403189 |
On 2026-10-15 16:37, Dan Cross wrote: > In article <86bj8vqhtl.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> [...] > > It is probably true that this snippet is a good example of how > labeled break/continue can be abused. [...] Else-thread (in a reply to bart) you had already written: > > The point was to illustrate a contrived > example where one might break out of nested switch statements, > loops inside of switch, switch inside of loops, loops inside of > switch inside of loops, and so on. In a newsgroup (also generally) where part of the audience isn't interested in understanding the context and intention of such examples it's "good" fodder for those to continue their campaign. Of course your example with its intent were obvious and clear. Your formerly posted explanations without code had already been clear. (I.e., for those that were interested to understand the point. For those that aren't, with every additional post, and especially with lots of code, you just feed the... - campaigners. Wasted time, IMO.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-15 19:59 +0100 |
| Message-ID | <11ar7rb$2mb01$1@dont-email.me> |
| In reply to | #403187 |
On 15/10/2026 13:17, Tim Rentsch wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>> On 14/10/2026 20:30, Dan Cross wrote:
>>> [snip more of the same already hashed and rehashed ad naseum]
>>>
>>> As for multiple nested loops, this will fix that too, that's great. We
>>> just require some real examples of that being needed!
>>
>> Here's a pretty terrible way to write part of a lexical
>> analyzer. I just typed this in an hour or so ago.
>>
>> [200+ lines of code]
>
> This code provides an excellent example of why multi-level breaks
> should not be added to C.
Actually most of those 'break-labels' are not multi-level breaks.
But they have to use that form because they are inside 'switch'.
(Unless you consider 'levels' to include switch statements as loops; I
don't. I mean, there is a 'continue' in there too inside switch, which
doesn't use the label. So how can that not be multi-level but 'break' is?)
It all goes back to that bad decision about 'break' that everyone is
playing down.
> The code would be easier to understand
> if all the 'break <label>;' lines were replaced with one of 'goto
> TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate,
> and with the loop labels being removed and the two new labels put
> in at the appropriate places.
Once you have to write /actual labels/, which aren't even in local scope
within the loop, then 'break label' doesn't buy much over 'goto label':
loop:
while () {
switch () {
case x:
break loop;
}
}
while () {
switch () {
case x:
goto loopend;
}
}
loopend:
The latter will at least work with every compiler.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-15 20:49 +0000 |
| Message-ID | <11are89$peu$1@reader2.panix.com> |
| In reply to | #403194 |
In article <11ar7rb$2mb01$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 15/10/2026 13:17, Tim Rentsch wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>> In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>
>>>> On 14/10/2026 20:30, Dan Cross wrote:
>>>> [snip more of the same already hashed and rehashed ad naseum]
>>>>
>>>> As for multiple nested loops, this will fix that too, that's great. We
>>>> just require some real examples of that being needed!
>>>
>>> Here's a pretty terrible way to write part of a lexical
>>> analyzer. I just typed this in an hour or so ago.
>>>
>>> [200+ lines of code]
>>
>> This code provides an excellent example of why multi-level breaks
>> should not be added to C.
>
>Actually most of those 'break-labels' are not multi-level breaks.
>
>But they have to use that form because they are inside 'switch'.
>
>(Unless you consider 'levels' to include switch statements as loops; I
>don't. I mean, there is a 'continue' in there too inside switch, which
>doesn't use the label. So how can that not be multi-level but 'break' is?)
>
>It all goes back to that bad decision about 'break' that everyone is
>playing down.
>
>> The code would be easier to understand
>> if all the 'break <label>;' lines were replaced with one of 'goto
>> TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate,
>> and with the loop labels being removed and the two new labels put
>> in at the appropriate places.
>
>
>Once you have to write /actual labels/, which aren't even in local scope
>within the loop, then 'break label' doesn't buy much over 'goto label':
>
> loop:
> while () {
> switch () {
> case x:
> break loop;
> }
> }
>
> while () {
> switch () {
> case x:
> goto loopend;
> }
> }
> loopend:
>
>The latter will at least work with every compiler.
I mentioned this already; labeled continue and labeled break
both consume only one label; `goto` would require two:
outer:
for (i = 0; i < n; i++)
for (j = 0; j < m; j++)
if (condx(i, j)) break outer;
else if (condy(i, j)) continue outer;
vs:
for (i = 0; i < n; i++) {
for (j = 0; j < m; j++)
if (condx(i, j)) goto outer_break;
else if (condy(i, j)) goto outer_continue;
outer_continue:
}
outer_break:
And so forth.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 18:51 +0100 |
| Message-ID | <11aoff0$1n82v$1@dont-email.me> |
| In reply to | #403150 |
On 14/10/2026 13:38, Dan Cross wrote:
> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
> Yes, I am aware that you will tell me that it is justified
> because that problem is actually the one worth solving, and the
> others are not; you needn't bother. Simply put, I disagree that
> that one problem is sufficiently important to warrant its own
> solution, particularly when something more general is already
> known and available in the language (labeled break/continue).
I missed this bit.
Is labeled break now available in C?
If so, how would it be used here:
while (1) {
switch (x) {
case y:
Break;
where that Break is meant to quit the loop.
Remember that if DMR hadn't made that screw-up in 1972 it would simply
have been as it is above with his choice of keyword in place of Break.
But I would be interested in trying out the new feature.
[toc] | [prev] | [next] | [standalone]
| From | "Peyton" <peyton@solacium.com> |
|---|---|
| Date | 2026-10-14 11:04 -0700 |
| Message-ID | <87zewgxip7.fsf@peyton-d> |
| In reply to | #403159 |
bart <bc@freeuk.com> writes:
> On 14/10/2026 13:38, Dan Cross wrote:
>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>> Yes, I am aware that you will tell me that it is justified
>> because that problem is actually the one worth solving, and the
>> others are not; you needn't bother. Simply put, I disagree that
>> that one problem is sufficiently important to warrant its own
>> solution, particularly when something more general is already
>> known and available in the language (labeled break/continue).
>
> I missed this bit.
>
> Is labeled break now available in C?
>
> If so, how would it be used here:
>
>
> while (1) {
> switch (x) {
> case y:
> Break;
>
> where that Break is meant to quit the loop.
>
> Remember that if DMR hadn't made that screw-up in 1972 it would simply
> have been as it is above with his choice of keyword in place of Break.
>
> But I would be interested in trying out the new feature.
>
>
No it's definetely not supported yet. I am very much in support of it
though. Not sure when or if. In the meantime I guess you can use the
forbidden goto like so:
while(1) {
switch(x) {
case 1:
doThing();
break;
case 2:
goto exitLoop;
default:
break;
}
}
exitLoop;
--
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 19:47 +0000 |
| Message-ID | <11aom8a$6sa$1@reader2.panix.com> |
| In reply to | #403159 |
In article <11aoff0$1n82v$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 14/10/2026 13:38, Dan Cross wrote:
>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>> Yes, I am aware that you will tell me that it is justified
>> because that problem is actually the one worth solving, and the
>> others are not; you needn't bother. Simply put, I disagree that
>> that one problem is sufficiently important to warrant its own
>> solution, particularly when something more general is already
>> known and available in the language (labeled break/continue).
>
>I missed this bit.
>
>Is labeled break now available in C?
It's in C2y, and has been implemented in (at least) LLVM/clang
and GCC. I don't know about other compilers.
>If so, how would it be used here:
>
>
> while (1) {
> switch (x) {
> case y:
> Break;
>
>where that Break is meant to quit the loop.
term% cat lb.c
#include <stdio.h>
int
main(void)
{
int sum = 0;
outer:
for (int i = 0; i < 100; i++) {
for (int j = 0; j < 100; j++) {
int p = i * j;
switch (p) {
case 500:
break outer;
default:
sum += p;
break;
}
}
}
printf("sum = %d\n", sum);
return 0;
}
term% clang-23 -std=c2y -o lb lb.c
term% ./lb
sum = 235000
term% gcc-16 -std=c2y -o lb lb.c
term% ./lb
sum = 235000
term% sed 's/outer./\;/' lb.c >lb2.c
term% clang-23 -std=c2y -o lb2 lb2.c
term% ./lb2
sum = 24500500
term%
>Remember that if DMR hadn't made that screw-up in 1972 it would simply
>have been as it is above with his choice of keyword in place of Break.
As I said in my other post, you incorrectly assume that that was
the fundamental issue, when really it's just a detail: the
problem was that no facility to break out of nested control
structures as provided. Remedied now!
>But I would be interested in trying out the new feature.
So do it. You don't need me to hold your hand.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-14 13:58 -0700 |
| Message-ID | <11aoqed$1qib2$1@kst.eternal-september.org> |
| In reply to | #403159 |
bart <bc@freeuk.com> writes:
> On 14/10/2026 13:38, Dan Cross wrote:
>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>> Yes, I am aware that you will tell me that it is justified
>> because that problem is actually the one worth solving, and the
>> others are not; you needn't bother. Simply put, I disagree that
>> that one problem is sufficiently important to warrant its own
>> solution, particularly when something more general is already
>> known and available in the language (labeled break/continue).
>
> I missed this bit.
How?? I've mentioned it more than once in this thread.
> Is labeled break now available in C?
It's proposed for C2y, and implemented as an extension in gcc and clang.
The latest C2y draft is
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf
6.8.2 describes named iteration and switch statements.
6.8.7.3 and 6.8.7.4 describe the "continue" and "break" statements.
> If so, how would it be used here:
>
> while (1) {
> switch (x) {
> case y:
> Break;
>
> where that Break is meant to quit the loop.
I have no doubt that you can figure it out after reading the cited
sections. (I'm not sure why you spelled "break" with an uppercase 'B'.)
[...]
Elsewhere, you've mentioned that labels have function scope.
That's not a problem. A named "break" or "continue" can only
refer to the label of an enclosing iteration or switch statement.
"break FOO;" where FOO does not apply to an enclosing loop or switch
is a constraint violation. But "goto FOO;" is valid as long as
"FOO:" is within the same function (with some restrictions that
aren't relevant here).
--
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-15 12:08 +0200 |
| Message-ID | <11aq8nn$206gh$1@dont-email.me> |
| In reply to | #403168 |
On 2026-10-14 22:58, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 14/10/2026 13:38, Dan Cross wrote: >>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> >>> Yes, I am aware that you will tell me that it is justified >>> because that problem is actually the one worth solving, and the >>> others are not; you needn't bother. Simply put, I disagree that >>> that one problem is sufficiently important to warrant its own >>> solution, particularly when something more general is already >>> known and available in the language (labeled break/continue). >> >> I missed this bit. > > How?? If operating one's intellect in a batten-down-the-hatches mode, or if a brain is working in /dev/null mode, are two possibilities that occur to me to miss that. I also see the possibility that in a heated discussion one might be tempted to prioritize a rebuttal in a post without beforehand taking the time thinking about the provided information. (Although the former two possibilities seem more likely in this case.) > I've mentioned it more than once in this thread. A couple other posters as well. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-14 14:23 -0700 |
| Message-ID | <11aorsh$1qib2$2@kst.eternal-september.org> |
| In reply to | #403148 |
bart <bc@freeuk.com> writes:
[...]
>> But as Keith pointed out, W14 is now entertaining proposals to
>> add labeled `break` to the language. I haven't looked myself,
>> but if that is usable in a `switch` context, then it would solve
>> the problem for good.
>
> OK. Although in that form, it really is little different from
> 'goto'. I believe the main difference is that the label goes at the
> beginning of the loop rather than the end!
Hardly.
Like most or all "structured" control flow constructs, it's a kind of
restricted goto -- and it's the restrictions that make it useful in
writing clear code.
"break", with or without a label, can only jump forward. That makes it
much more difficult to use it to write spaghetti code.
Yes, "break FOO;" is equivalent to a goto, given an appropriately placed
label. So what?
FOO:
for (blah;blah;blah) {
BAR:
while (blah) {
if (cond1) {
break FOO;
}
else if (cond2) {
break BAR;
}
}
}
"break FOO" is implemented as a jump to a point just after the end
of the outer loop. But the way I think of it is that "FOO" is the
name of the entire outer loop, not just a single point in the code.
"break FOO;" applies to the named loop, causing execution of the
loop to terminate. The fact that it's equivalent to a goto (just
as "break;" is) is an implementation detail.
One very minor infelicity is that the same syntax is used for labels
intended to be the targets of gotos and labels intended to name
loops and switch statements. I think this same issue occurs in
most languages that have named breaks. (Ada is an exception; it
uses a deliberately heavy syntax for goto labels, "<<LABEL>>", and
a simpler syntax for loop names, "NAME:". But Ada had both gotos
and named loops from the begining.) There has been a proposal to
use a different syntax for named loops ("for NAME (;;)"), but it's
not reflected in the latest C2y draft. The fact that a loop name
can also be used as the target of a goto is a trivial problem,
perhaps a non-problem, solved by just not doing that.
> And maybe those scoping rules will be different: goto labels have
> function-wide scope.
See the C2y draft.
[...]
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-14 14:35 +0000 |
| Message-ID | <frMzS.2749$e_i.171@fx08.iad> |
| In reply to | #403132 |
bart <bc@freeuk.com> writes: >On 13/10/2026 01:33, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >> [...] >I've got a better idea. I added an extra keyword to my C compiler called >"breakloop". It's like 'break' but always works with the nearest >enclosing loop, even from inside switch. It's hardly a new idea. The 1967 BPL compiler at burroughs supported 'EXITLOOP', 'EXITCOND', 'EXITCASE' and 'EXITBLOCK'; each with the expected semantics for the name.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 16:38 -0700 |
| Message-ID | <11aei9t$24k8m$4@kst.eternal-september.org> |
| In reply to | #402890 |
Michael S <already5chosen@yahoo.com> writes:
> On Sat, 10 Oct 2026 20:08:20 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-10-10 15:11, bart wrote:
>> >
>> > Well, Algol 68 doesn't even have 'break'. For unusual control-flow
>> > it needs goto.
>>
>> Yes. - And while "C" has 'goto' as well it also supports 'break' for
>> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
>> keyword for other purposes as in 'switch' where it's been useful.
>
> After practicing C programming for more than 35 years I am deeply
> convinced that reuse of the same 'break' keyword for loops and for
> switch was a mistake. But then again, DRM did not have a benefit
> of hindsight.
Actually he (DMR) did. C's parent language, BCPL, had distinct BREAK
and ENDCASE keywords.
I agree that combining them both into "break" was a mistake. At this
point, I think the best solution is named loops and "break loop_name;".
There are proposals for C2y.
A distinct "endcase" keyword would have been cleaner IMHO, but code
using the existing case/break will continue to exist approximately
forever.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-10 21:09 +0100 |
| Message-ID | <11ae62d$221po$1@dont-email.me> |
| In reply to | #402887 |
On 10/10/2026 19:08, Janis Papanagnou wrote:
> On 2026-10-10 15:11, bart wrote:
>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>> [...]
>> If you look at actual C codebases, fall-through is incredibly rare.
>> Nearly always, it will use break, or sometimes other control-flow such
>> as return or goto, so that fall-through doesn't happen.
>
> I have no representative statistics, but my impression also matches
> that; fall-through is certainly much rarer than the 'break' case.
>
> In 6 C-sources in some of my directories I have 30 'switch' statements
> (some nested on more than one level), and in two cases fall-throughs.
> In another (non-C) place I find 40+ fall-throughs. - Not predominantly,
> but it's certainly not only an exotic corner-case! - So there's reason
> to support it, best without clumsy surrogate-constructs (workarounds).
This is difficult for me to survey as it take some effort in a compiler,
and I no long have many C codebases around. But here is one attempt:
Program Case Labels Break/Goto/Return
Piet 6 6
SQLite3 793 805
Lua 555 472
Nano 9 9
TinyPas 160 118
STB 69 62
MiniGMP 13 13
Middle column is total case labels which not followed by another case label.
Right column is total number of switch-breaks, plus return/goto IF they
are the first and only statement in the case-block. (Being unstructured
makes it tricky.)
So Return/Goto following other code is not counted. In some cases I have
verified that some been missed for that reason.
This is not foolproof: one case may have 2 breaks, and the following
none so falls through. But from visual inspections failed to show
significant fall-through in use.
>>
>> Note that if-statement blocks don't have fall-through either when
>> there is an else branch.
>>
>> Imagine having to write this: [...]
>
> (Slow down, cool down your brain! - It makes no sense to speak about
> fall-throughs in contexts of 'if' constructs. Making up inappropriate
> comparisons never lead you anywhere;
If it is probably the most relevant comparison that you can make.
A statement like this:
if (cond) {A} else {B}
can be always be expressed as:
switch (!!cond)
case 1: {A}; break;
default: {B}
}
Notice that 'break' the switch needs, that 'if' doesn't.
>> I guess everyone would still defend that choice (because for one
>> person in a million it will be valuable feature). But it is CLEARLY
>> wrong.
>
> Sadly you show again and confirm that it's just *you* who speaks about
> "right" or "wrong" (even "clearly"), and again fall into the habit to
> speak for or at least make wild guesses about "everyone".
> I've shown above that I'm obviously regularly using it
You haven't given an example, which would be interesting. But this is
the curious fact about C, that after 50 years, every misfeature and
quirk is an invaluable feature to somebody!
- and before my
> post I didn't even know that fact, so it's nothing about "defending"
> anything. And I've got not yet any indication - i.e. before your own
> personal complaints about it - that only "one person / million" would
Well, that was about fall-through in an IF statement.
> make good use of that feature; that's also completely implausible, and
> there's many facts that support this opinion (e.g. people talking about
> it, being part of coding standards, reading various explanations about
> it as being a "*concept* in programming", etc.).
>
> (Your opinions don't reflect the world, but rather just your personal
> vicinity - which I fear isn't even more than the personal small bubble
> you reside in.)
No. Look at how 'switch' implemented in pretty much every other language
other C (and C++ which inherited it).
How many have default fall-through?
I suggest most people have the same opinion as I do on this.
>>
>>> Just imagine if some C-programmers wanted a fall-through semantics
>>> but all they got would be the Pascal or Algol 68 'case' construct.
>>
>> Well, Algol 68 doesn't even have 'break'. For unusual control-flow it
>> needs goto.
>
> Yes. - And while "C" has 'goto' as well it also supports 'break' for
> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
> keyword for other purposes as in 'switch' where it's been useful.
No, it makes no sense at all, because their use-cases overlap.
It means that, inside a SWITCH statement, you can't do an early break
out of a case-block from inside a loop.
And if inside a loop, you can't break out of that loop from inside a
switch statement:
while (1) {
if (x == 3)
break;
switch (x) {
case 3: break;
}
}
The first break works within IF. But if you choose to use SWITCH, if
doesn't work.
You still think it makes sense?
> (Somewhere you thematized whether fall-through should be the default
> behavior of 'switch'; for me it would make as much sense to switch
> roles of the defaults in C's 'switch' to make the more common case
> terser, or have explicit statements for both branch-behaviors types.
> Actually I don't care much; there's more important things here that
> I'd find noteworthy; see below.)
>
>>
>> I don't have fall-through either; it is just so rare. But I do have a
>> 'recase' statement to pass control to an /arbitrary/ block, not just
>> the one that happens to follow.
>
> (I'm not interested in your language.)
Why not? You don't have to use it; it just needs to exist.
A 'structured switch' has been discussed. And I have a 'structured
switch' implemented in a equally low level language, so Ask Me Anything.
>> This way, BLOCKS CAN BE REORDERED without changing behaviour.
>
> Fine for you.
It's fine for everyone.
>> But C's switch is just /too/ low-level. For example, a structured
>> switch could be easily transformed into an if-else chain.
>>
>> You can't do that in general with C switch because there IS no
>> structure; it can be totally chaotic.
>
> I recall, the disappointment I had with C's 'switch' was that it didn't
> support "strings" as tags.[*] - But so what? Noting that as impossible
> and carrying on, either with workarounds ('if' cascades) or switching
> the language (if appropriate, possible, and worthwhile).
>
> [*] In the GNU version of Awk - a much simpler but higher abstracted
> language - you can nicely compare strings, and even regexps.
I have a narrow view of SWITCH, which is specifically for use with
integer values. That allows comparison of N unique possibilities
simultaneously, or in O(1) time.
So if you're comparing strings, then it is not SWITCH IMO, unless those
strings are perhaps interned.
(I use a different feature when it needs to be more flexible, and in
that case, any type for which equality, or sometimes 'in', is defined,
will work.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-10 23:14 +0200 |
| Message-ID | <11ae9r3$cjlv$7@dont-email.me> |
| In reply to | #402899 |
[ I skip most of what you wrote because it's not adding anything new
and I basically still just disagree with all you presented; if you
re-read my previous post you have my comments on your "new" text. ]
On 2026-10-10 22:09, bart wrote:
> On 10/10/2026 19:08, Janis Papanagnou wrote:
>> On 2026-10-10 15:11, bart wrote:
>>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>>>
>>>> Just imagine if some C-programmers wanted a fall-through semantics
>>>> but all they got would be the Pascal or Algol 68 'case' construct.
>>>
>>> Well, Algol 68 doesn't even have 'break'. For unusual control-flow it
>>> needs goto.
>>
>> Yes. - And while "C" has 'goto' as well it also supports 'break' for
>> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
>> keyword for other purposes as in 'switch' where it's been useful.
>
> No, it makes no sense at all, because their use-cases overlap.
>
> It means that, inside a SWITCH statement, you can't do an early break
> out of a case-block from inside a loop.
>
> And if inside a loop, you can't break out of that loop from inside a
> switch statement:
>
> while (1) {
> if (x == 3)
> break;
>
> switch (x) {
> case 3: break;
> }
> }
>
> The first break works within IF. But if you choose to use SWITCH, if
> doesn't work.
It also doesn't work in nested loops. (That's a restriction of C's
'break'.)
I don't think it makes sense to introduce another distinct keyword
to address a special case like that; that's very short-sighted. You
could still not address, e.g., a "for() for() switch()" structure.
Other languages provide more universal, thus more sensible features
to support out-of-band conditions, or more universal "local exits"
(that support more than one nested level).
> You still think it makes sense?
Yes, because it works as intended for the other common cases.
If you need a "flexible jump" just use 'goto'. The point of 'break'
is to "tame" that "harmful goto" and introduce something "lighter".
Some languages support a 'break' (and a 'continue') with a numeric
argument to handle the case of nested constructs. That is of course
yet more flexible without sacrificing the "prevent wild jumps" dogma.
[ another big snip ]
>> [*] In the GNU version of Awk - a much simpler but higher abstracted
>> language - you can nicely compare strings, and even regexps.
>
> I have a narrow view of SWITCH, which is specifically for use with
> integer values. That allows comparison of N unique possibilities
> simultaneously, or in O(1) time.
> So if you're comparing strings, then it is not SWITCH IMO, unless those
> strings are perhaps interned.
A CDC 175/176 carried a Pascal TEXT object in one machine word and
could compare it as atom. Newer standard PC CPUs have more bits in
a word than those former supercomputers. - But the point here was
that internals should be abstracted by a higher level programming
language. - And compilers have principally various possibilities to
support some "atomization" of string comparisons with compile-time
string constants. - As said, it would have been useful in many of
my application cases. (No more, no less.)
(BTW, it would be new to me that you'd have complexity guarantees in
"C".)
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-10 23:01 +0100 |
| Message-ID | <11aecjq$24dls$1@dont-email.me> |
| In reply to | #402911 |
On 10/10/2026 22:14, Janis Papanagnou wrote:
> [ I skip most of what you wrote because it's not adding anything new
> and I basically still just disagree with all you presented; if you
> re-read my previous post you have my comments on your "new" text. ]
>
> On 2026-10-10 22:09, bart wrote:
>> On 10/10/2026 19:08, Janis Papanagnou wrote:
>>> On 2026-10-10 15:11, bart wrote:
>>>> On 10/10/2026 13:01, Janis Papanagnou wrote:
>>>>>
>>>>> Just imagine if some C-programmers wanted a fall-through semantics
>>>>> but all they got would be the Pascal or Algol 68 'case' construct.
>>>>
>>>> Well, Algol 68 doesn't even have 'break'. For unusual control-flow
>>>> it needs goto.
>>>
>>> Yes. - And while "C" has 'goto' as well it also supports 'break' for
>>> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
>>> keyword for other purposes as in 'switch' where it's been useful.
>>
>> No, it makes no sense at all, because their use-cases overlap.
>>
>> It means that, inside a SWITCH statement, you can't do an early break
>> out of a case-block from inside a loop.
>>
>> And if inside a loop, you can't break out of that loop from inside a
>> switch statement:
>>
>> while (1) {
>> if (x == 3)
>> break;
>>
>> switch (x) {
>> case 3: break;
>> }
>> }
>>
>> The first break works within IF. But if you choose to use SWITCH, if
>> doesn't work.
>
> It also doesn't work in nested loops. (That's a restriction of C's
> 'break'.)
That is a separate matter, and one that occurs sparingly.
On the other hand, breaking out of one level is fairly common, and so is
the use of 'switch'.
Now you have an artificial problem caused by two brain-dead decisions:
* A crappy, crude design of 'switch' that leaves you stranded in the
middle of the statement
* Deciding to fix that by USING THE SAME KEYWORD as one of the loop
controls, for something that isn't to do with loops.
This is just very poor language design.
(Inside my C compiler, there are two AST tags called 'jbreak' and
'jbreaksw' - they are two distinct features.)
>
> I don't think it makes sense to introduce another distinct keyword
> to address a special case like that; that's very short-sighted. You
> could still not address, e.g., a "for() for() switch()" structure.
> Other languages provide more universal, thus more sensible features
> to support out-of-band conditions, or more universal "local exits"
> (that support more than one nested level).
THIS IS NOT A NESTED LOOP PROBLEM! It has been made into one by reusing
BREAK.
What's the big deal about keywords anyway?
>> You still think it makes sense?
>
> Yes, because it works as intended for the other common cases.
Would you have made the same choice?
Assuming yes, and assuming you'd also devise some scheme to cut across
nesting, what would happen here:
FOR
SWITCH
FOR
SWITCH
break...
You want to break out of that inner FOR, but now you have to count both
nested loops and switch. So, break 2?
So what would break 3 mean: does it get you to the end of that outer
SWITCH? This is something that would not previously have cross your mind:
SWITCH
SWITCH
break 2
That is, to use 'break' to cut to the end of the enclosing switch
statements. It is just not meaningful.
This just further shows that the two concepts are distinct.
>> I have a narrow view of SWITCH, which is specifically for use with
>> integer values. That allows comparison of N unique possibilities
>> simultaneously, or in O(1) time.
>> So if you're comparing strings, then it is not SWITCH IMO, unless
>> those strings are perhaps interned.
>
> A CDC 175/176 carried a Pascal TEXT object in one machine word and
> could compare it as atom. Newer standard PC CPUs have more bits in
> a word than those former supercomputers. - But the point here was
> that internals should be abstracted by a higher level programming
> language. - And compilers have principally various possibilities to
> support some "atomization" of string comparisons with compile-time
> string constants. - As said, it would have been useful in many of
> my application cases. (No more, no less.)
My point is that SWITCH should be a low level feature working on
integers. (Like how CASE works in Algol68.)
A version for higher level types, for runtime case-values, and a
possible sequential, ordered search, could share the same keyword, but I
would prefer a different keywords here since the semantics can be very
different.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-11 08:00 +0000 |
| Message-ID | <11affmm$1m9m7$1@paganini.bofh.team> |
| In reply to | #402911 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2026-10-10 22:09, bart wrote:
>> On 10/10/2026 19:08, Janis Papanagnou wrote:
>>> [*] In the GNU version of Awk - a much simpler but higher abstracted
>>> language - you can nicely compare strings, and even regexps.
>>
>> I have a narrow view of SWITCH, which is specifically for use with
>> integer values. That allows comparison of N unique possibilities
>> simultaneously, or in O(1) time.
>> So if you're comparing strings, then it is not SWITCH IMO, unless those
>> strings are perhaps interned.
>
> A CDC 175/176 carried a Pascal TEXT object in one machine word and
> could compare it as atom. Newer standard PC CPUs have more bits in
> a word than those former supercomputers. - But the point here was
> that internals should be abstracted by a higher level programming
> language. - And compilers have principally various possibilities to
> support some "atomization" of string comparisons with compile-time
> string constants. - As said, it would have been useful in many of
> my application cases. (No more, no less.)
In C there are multi-character "characters". Details are implementation
defined, but AFAICS on 64-bit machine you can pack 8 bytes into single
machine word and use that in a switch. CDC used 6 bit characters, so
it could cram 10 characters into a single word. Corresponding comparison
of strings would execute as a single machine instruction. But AFAIK
Pascal did not allow to use strings in 'case' statement.
In principle C compiler could generate matching code for strings,
basically if all cases correspond to short strings it could pack
characters into a single machine word and then reuse integer
case. For longer strings it could generate either tree of
comparisons (IIUC some sparse switches use this) or use hashing
to find correct case. That would be modest extention of current
switch (with sparse case labels one needs to handle most of it
anyway). I would guess that main counterargument to such a switch
is C++ compatibility: clearly C++ would want such things for classes
and it opens a can of worms.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-11 10:27 +0200 |
| Message-ID | <11afh96$286mm$2@dont-email.me> |
| In reply to | #402951 |
On 2026-10-11 10:00, Waldek Hebisch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-10-10 22:09, bart wrote: >>> On 10/10/2026 19:08, Janis Papanagnou wrote: >>>> [*] In the GNU version of Awk - a much simpler but higher abstracted >>>> language - you can nicely compare strings, and even regexps. >>> >>> I have a narrow view of SWITCH, which is specifically for use with >>> integer values. That allows comparison of N unique possibilities >>> simultaneously, or in O(1) time. >>> So if you're comparing strings, then it is not SWITCH IMO, unless those >>> strings are perhaps interned. >> >> A CDC 175/176 carried a Pascal TEXT object in one machine word and >> could compare it as atom. Newer standard PC CPUs have more bits in >> a word than those former supercomputers. - But the point here was >> that internals should be abstracted by a higher level programming >> language. - And compilers have principally various possibilities to >> support some "atomization" of string comparisons with compile-time >> string constants. - As said, it would have been useful in many of >> my application cases. (No more, no less.) > > In C there are multi-character "characters". Details are implementation > defined, but AFAICS on 64-bit machine you can pack 8 bytes into single > machine word and use that in a switch. CDC used 6 bit characters, so > it could cram 10 characters into a single word. Corresponding comparison > of strings would execute as a single machine instruction. But AFAIK > Pascal did not allow to use strings in 'case' statement. That is absolutely correct; about the PACKED ARRAY [1..10] OF CHAR on these CDCs, and about what the Pascal language's CASE allowed per language definition, which was any enumerable type, and strings were, being arrays, not enumerable. I seem to recall that operations on the Pascal's TEXT type were not very elaborated, though. And assignments were possible for any type not restricted to primitive types or the TEXT type. My point was, as you also wrote, that there's possibilities to handle a short string at least as an atom for comparisons in principle (if the language definition allows that, if it's appropriately defined). > > In principle C compiler could generate matching code for strings, > basically if all cases correspond to short strings it could pack > characters into a single machine word and then reuse integer > case. For longer strings it could generate either tree of > comparisons (IIUC some sparse switches use this) or use hashing > to find correct case. That would be modest extention of current > switch (with sparse case labels one needs to handle most of it > anyway). I would guess that main counterargument to such a switch > is C++ compatibility: clearly C++ would want such things for classes > and it opens a can of worms. Yes, probably. - There's so many things you cannot do now, decades after the base of "C" has been defined. Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-11 10:49 +0200 |
| Message-ID | <11afiji$286mm$3@dont-email.me> |
| In reply to | #402952 |
On 2026-10-11 10:27, Janis Papanagnou wrote: > On 2026-10-11 10:00, Waldek Hebisch wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> On 2026-10-10 22:09, bart wrote: >>>> On 10/10/2026 19:08, Janis Papanagnou wrote: >>>>> [*] In the GNU version of Awk - a much simpler but higher abstracted >>>>> language - you can nicely compare strings, and even regexps. >>>> >>>> I have a narrow view of SWITCH, which is specifically for use with >>>> integer values. That allows comparison of N unique possibilities >>>> simultaneously, or in O(1) time. >>>> So if you're comparing strings, then it is not SWITCH IMO, unless those >>>> strings are perhaps interned. >>> >>> A CDC 175/176 carried a Pascal TEXT object in one machine word and >>> could compare it as atom. Newer standard PC CPUs have more bits in >>> a word than those former supercomputers. - But the point here was >>> that internals should be abstracted by a higher level programming >>> language. - And compilers have principally various possibilities to >>> support some "atomization" of string comparisons with compile-time >>> string constants. - As said, it would have been useful in many of >>> my application cases. (No more, no less.) >> >> In C there are multi-character "characters". Details are implementation >> defined, but AFAICS on 64-bit machine you can pack 8 bytes into single >> machine word and use that in a switch. CDC used 6 bit characters, so >> it could cram 10 characters into a single word. Corresponding comparison >> of strings would execute as a single machine instruction. But AFAIK >> Pascal did not allow to use strings in 'case' statement. > > That is absolutely correct; about the PACKED ARRAY [1..10] OF CHAR > on these CDCs, and about what the Pascal language's CASE allowed > per language definition, which was any enumerable type, and strings > were, being arrays, not enumerable. I just looked it up in an old book; you could (in Pascal) also compare "strings" (PACKED ARRAY OF TEXT) by the six comparison operators (where other general array type objects needed an element-wise comparison). So you could at least compare strings of type TEXT directly with IF (and need no function, as in "C"). > > I seem to recall that operations on the Pascal's TEXT type were not > very elaborated, though. And assignments were possible for any type > not restricted to primitive types or the TEXT type. > > My point was, as you also wrote, that there's possibilities to handle > a short string at least as an atom for comparisons in principle (if > the language definition allows that, if it's appropriately defined). > >> >> In principle C compiler could generate matching code for strings, >> basically if all cases correspond to short strings it could pack >> characters into a single machine word and then reuse integer >> case. For longer strings it could generate either tree of >> comparisons (IIUC some sparse switches use this) or use hashing >> to find correct case. That would be modest extention of current >> switch (with sparse case labels one needs to handle most of it >> anyway). I would guess that main counterargument to such a switch >> is C++ compatibility: clearly C++ would want such things for classes >> and it opens a can of worms. > > Yes, probably. - There's so many things you cannot do now, decades > after the base of "C" has been defined. > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 16:30 -0700 |
| Message-ID | <11aehqg$24k8m$3@kst.eternal-september.org> |
| In reply to | #402873 |
bart <bc@freeuk.com> writes:
> 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
BCPL's "SWITCHON" is a more structured replacement for what was probably
(I'm speculating) a major use case for CPL's "go to expr".
[...]
> 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).
Huh? "computed goto" is not a looping construct. But C doesn't
have computed goto, so I'm not going to discuss it here other than
in the context of how C's switch statement came to be.
[...]
> (Of, course, my language has it all:
Of course it does.
[...]
>> 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?
Yes, of course it does. Did you think that a construct that's used in
most existing C programs could just be removed from the language?
> That hasn't stop C++ having a higher level version.
C is not C++. A future C could have additional looping constructs,
but I haven't seen any concrete proposals.
[...]
>> 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:
No, with a little care.
> case 10: default: case 20:
Doctor, it hurts when I do this.
[...]
>> 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.
You're angry about a decision that was made in the 1960s and 1970s,
and you're whining about it to people who can't do anything about it.
That can't be good for you.
I've explained why it doesn't need fixing, and would not be easy to fix.
> It could also be easy to implement as structured switch can be
> syntactic sugar for an if-else-if chain.
If you want an if-else-if chain, write an if-else-if chain.
--
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]
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web