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 315 — 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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -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-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +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 antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 17:02 -0700 |
| Message-ID | <11ajsfi$28f2$5@kst.eternal-september.org> |
| In reply to | #403054 |
bart <bc@freeuk.com> writes:
[...]
> That's what it seems like: obstinately trying to pretend it is not a
> flaw, that it makes perfect sense, then you never want to do any of
> the stuff where it causes problems anyway etc.
Nobody is trying to pretend that there are no flaws. The rest of
us acknowledge that C has flaws (though we don't necessarily agree
with what those flaws are) and then get on with writing working C
code in spite of those flaws.
Most of us are also aware of how very difficult it would be to "fix"
those flaws without breaking existing code.
You completely misunderstand where most of us are coming from,
even after it's explained to you.
> There are several issues discussed regarding switch:
>
> * That its structure is totally chaotic (there /is/ no structure)
An overstatement, but I don't entirely disagree. switch is a low-level
control structure. I'd say it's notable for its low-levelness even
compared to other C features.
> * That 'break' is needed to escape from the middle of that statement to
> the end
Yes. We all know that.
> * That that 'break' happens also to clash, needlessly, with loop-break
Yes, we all know that. BCPL had BREAK and ENDCASE. B apparently
dropped both, and then re-added just BREAK. C inherited break
from B. I haven't seen anyone say that that wasn't a mistake.
We just don't spend decades worrying about it.
Tell me, have this ever been a problem for you personally? Have
you ever written a switch statement nested in a loop and wanted to
break out of the loop from within the switch? (In C; I'm not asking
about your experience with other langauges.) How much difficulty
has it really cause for you?
> * And also with 'case' only doing one label at a time, instead of
> being able to do, for example: 'case a, b, c:' or 'case x...y',
> although some of this is taken care of via extensions.
"case a, b, c:" is written as "case a: case b: case c:". It's a little
more verbose than it needs to be. It's very mildly annoying.
As for "case x...y", that's already proposed for C2Y, and is
documented in the N3886 draft. You continue to whine about problems
that have already been solved.
> There's quite a lot that could have been done much better!
So invent a time machine and tell Dennis Ritchie to do it your way.
[...]
> Defending every shortcoming or quirk to the death seems common
> here.
No, it isn't.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 01:53 +0100 |
| Message-ID | <11ajvf2$492m$1@dont-email.me> |
| In reply to | #403076 |
On 13/10/2026 01:02, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] > Tell me, have this ever been a problem for you personally? It's the bigger picture that is more the problem. And yes it has affected me as I've never been able to adopt C as my main language. I guess I was too spoilt. But it isn't really about me - decisions in the language, how tools work and so on affect everyone. And yes, discussing PL design is interesting to me - there's so much going on here! > Have > you ever written a switch statement nested in a loop and wanted to > break out of the loop from within the switch? (In C; I'm not asking > about your experience with other langauges.) How much difficulty > has it really cause for you? Yes. I had to use 'goto'. I don't mind using goto when necessary but here it shouldn't have been. >> * And also with 'case' only doing one label at a time, instead of >> being able to do, for example: 'case a, b, c:' or 'case x...y', >> although some of this is taken care of via extensions. > > "case a, b, c:" is written as "case a: case b: case c:". It's a little > more verbose than it needs to be. It's very mildly annoying. It is quite annoying and a distraction. A lot more to mistype too.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 03:54 +0200 |
| Message-ID | <11ak2vp$4o6m$1@dont-email.me> |
| In reply to | #403076 |
On 2026-10-13 02:02, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> There are several issues discussed regarding switch: >> * That its structure is totally chaotic (there /is/ no structure) > > An overstatement, but I don't entirely disagree. switch is a low-level > control structure. I'd say it's notable for its low-levelness even > compared to other C features. I'm a bit astonished about that statement. The [original] "C" control structures appear to me to be all low-level; if I see "for (..;..;..)" it doesn't really strike me with awe concerning its abstraction level. And 'for' is the "most complex", the others are even more primitive. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-13 10:52 +0000 |
| Message-ID | <11al2i7$gd2$1@reader2.panix.com> |
| In reply to | #403076 |
In article <11ajsfi$28f2$5@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >[snip] >Yes, we all know that. BCPL had BREAK and ENDCASE. B apparently >dropped both, and then re-added just BREAK. C inherited break >from B. I haven't seen anyone say that that wasn't a mistake. >We just don't spend decades worrying about it. A minor historical quibble: BCPL, at the time of C's invention, did not have `ENDCASE`; that came later. We tend to forget that BCPL did not stop evolving after C's invention; in fact, it went on as a going concern for quite a few more years. From Dennis Ritchie's HOPL paper: |Not every difference between the BCPL language documented in |Richards's book [Richards 79] and B was deliberate; we started |from an earlier version of BCPL [Richards 67]. For example, the |`endcase` that escapes from a BCPL `switchon` statement was not |present in the language when we learned it in the 1960s, and so |the overloading of the `break` keyword to escape from the B and |C `switch` statement owes to divergent evolution rather than |conscious change. (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html) Note this is the only place in that paper where Dennis Ritchie mentions `break`. Why was it overloaded for `switch`? He does not say, exactly, but he _does_ alude to space being a consideration for B, and some of the resulting syntactic quirks then escaping into C: |Storage limitations on the B compiler demanded a one-pass |technique in which output was generated as soon as possible, |and the syntactic redesign that made this possible was carried |forward into C. This is from a section discussing why C did not implement the, `valof`/`resultis` mechanism of BCPL: BCPL parsed the whole program into memory and operated on the parsed representation; B could not afford that luxury. Btw, one hypothesizes that some of the subsequent evolution of BCPL came from C influence; BCPL added the PL/1-style `/* ... */` comments, and it wouldn't surprise me if `ENDCASE` came from C's `break` inside of a `switch`, though I have no evidence of that. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-13 23:16 +0300 |
| Message-ID | <20261013231606.00003e16@yahoo.com> |
| In reply to | #403093 |
On Tue, 13 Oct 2026 10:52:55 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <11ajsfi$28f2$5@kst.eternal-september.org>, > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >[snip] > >Yes, we all know that. BCPL had BREAK and ENDCASE. B apparently > >dropped both, and then re-added just BREAK. C inherited break > >from B. I haven't seen anyone say that that wasn't a mistake. > >We just don't spend decades worrying about it. > > A minor historical quibble: BCPL, at the time of C's invention, > did not have `ENDCASE`; that came later. We tend to forget that > BCPL did not stop evolving after C's invention; in fact, it went > on as a going concern for quite a few more years. > > From Dennis Ritchie's HOPL paper: > > |Not every difference between the BCPL language documented in > |Richards's book [Richards 79] and B was deliberate; we started > |from an earlier version of BCPL [Richards 67]. For example, the > |`endcase` that escapes from a BCPL `switchon` statement was not > |present in the language when we learned it in the 1960s, and so > |the overloading of the `break` keyword to escape from the B and > |C `switch` statement owes to divergent evolution rather than > |conscious change. > (https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html) > Good catch. Thank you. > Note this is the only place in that paper where Dennis Ritchie > mentions `break`. Why was it overloaded for `switch`? He does > not say, exactly, but he _does_ alude to space being a > consideration for B, and some of the resulting syntactic quirks > then escaping into C: > > |Storage limitations on the B compiler demanded a one-pass > |technique in which output was generated as soon as possible, > |and the syntactic redesign that made this possible was carried > |forward into C. > > This is from a section discussing why C did not implement the, > `valof`/`resultis` mechanism of BCPL: BCPL parsed the whole > program into memory and operated on the parsed representation; > B could not afford that luxury. > > Btw, one hypothesizes that some of the subsequent evolution of > BCPL came from C influence; BCPL added the PL/1-style > `/* ... */` comments, and it wouldn't surprise me if `ENDCASE` > came from C's `break` inside of a `switch`, though I have no > evidence of that. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 18:44 -0700 |
| Message-ID | <11ammp5$12efg$3@kst.eternal-september.org> |
| In reply to | #403093 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> Note this is the only place in that paper where Dennis Ritchie
> mentions `break`. Why was it overloaded for `switch`? He does
> not say, exactly, but he _does_ alude to space being a
> consideration for B, and some of the resulting syntactic quirks
> then escaping into C:
[...]
Pure speculation follows.
I'm skeptical that space concerns were the reasons for not having a
separate endcase keyword, though I suppose it's possible. (C had
23 keywords as of 1974.) It seems more likely that Ritchie just
didn't think of it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 17:33 -0700 |
| Message-ID | <11aju80$28f2$6@kst.eternal-september.org> |
| In reply to | #403054 |
bart <bc@freeuk.com> writes:
[...]
> This is my first example expressed in C (note those first three args
> are passed by reference):
>
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> switch (pmtype)
> case pm_option: ...; break;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break;
>
> Except I can't use break like that. So I have to find a workaround.
The code appears to be valid C that doesn't do what you want. I can't
easily tell what you want it to do. I don't know which of the two break
statements was intended to break out of the loop. A comment would have
solved that.
I'm going to guess that the first break is supposed to apply to the
switch statement, and the second to the while loop.
You want the language to be changed to make this kind of thing easier.
That's already happening. If you take a look at the N3886 working
draft for C2y, it has named break statements. In C2y (or in gcc
if you use an extension), the above could be written as:
WHILE:
while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
SWITCH:
switch (pmtype)
case pm_option: ...; break SWITCH;
case pm_sourcefile:
if (passlevel == run_pass || passlevel == runpcl_pass) {
break WHILE;
assuming it's the second "break' that's supposed to break out of
the loop. (I'd probably use more meaninful names.)
There is already a solution for the problem you're complaining about.
(It also solves the problem of breaking out of nested loops.)
If you're unable to use this feature, you can use goto. That's not
ideal, but with well chosen label names and no backward branching
it's not too bad.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 00:21 +0100 |
| Message-ID | <11amecs$10eab$1@dont-email.me> |
| In reply to | #403077 |
On 13/10/2026 01:33, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> This is my first example expressed in C (note those first three args
>> are passed by reference):
>>
>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>> switch (pmtype)
>> case pm_option: ...; break;
>> case pm_sourcefile:
>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>> break;
>>
>> Except I can't use break like that. So I have to find a workaround.
>
> The code appears to be valid C that doesn't do what you want. I can't
> easily tell what you want it to do. I don't know which of the two break
> statements was intended to break out of the loop. A comment would have
> solved that.
>
> I'm going to guess that the first break is supposed to apply to the
> switch statement, and the second to the while loop.
>
> You want the language to be changed to make this kind of thing easier.
>
> That's already happening. If you take a look at the N3886 working
> draft for C2y, it has named break statements. In C2y (or in gcc
> if you use an extension), the above could be written as:
>
> WHILE:
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> SWITCH:
> switch (pmtype)
> case pm_option: ...; break SWITCH;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break WHILE;
>
> assuming it's the second "break' that's supposed to break out of
> the loop. (I'd probably use more meaninful names.)
>
> There is already a solution for the problem you're complaining about.
> (It also solves the problem of breaking out of nested loops.)
>
> If you're unable to use this feature, you can use goto. That's not
> ideal, but with well chosen label names and no backward branching
> it's not too bad.
I've got a better idea. I added an extra keyword to my C compiler called
"breakloop". It's like 'break' but always works with the nearest
enclosing loop, even from inside switch.
So this example (a starts at 0):
while (1) {
switch (a++) {
case 1: puts("one"); break;
case 2: puts("two"); breakloop;
case 3: puts("three"); break;
default: puts("other");
}
if (a>40) break;
}
finishes after displaying 'two', instead of after the 37th or so 'other'.
Modding the compiler took 90 seconds, and needed 4 extra lines of code.
Setting up this test took 2-3 minutes.
Simple, yes? Then you think that this could be done even more easily 50
years ago.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 20:40 -0700 |
| Message-ID | <11amtjk$14pou$1@kst.eternal-september.org> |
| In reply to | #403132 |
bart <bc@freeuk.com> writes:
> On 13/10/2026 01:33, Keith Thompson wrote:
[...]
>> That's already happening. If you take a look at the N3886 working
>> draft for C2y, it has named break statements.
[...]
>> There is already a solution for the problem you're complaining
>> about.
>>
>> (It also solves the problem of breaking out of nested loops.)
>> If you're unable to use this feature, you can use goto. That's not
>> ideal, but with well chosen label names and no backward branching
>> it's not too bad.
>
> I've got a better idea. I added an extra keyword to my C compiler
> called "breakloop". It's like 'break' but always works with the
> nearest enclosing loop, even from inside switch.
Adding a keyword to your personal C compiler is easy. That's a tiny
fraction of the effort needed to make a change to the language.
Getting the WG14 committee to agree that your solution is a good idea,
nailing down the exact wording that describes it, and waiting for all
C compilers to implement it, is not.
Sure, your "breakloop" could work, but it's blatantly nothing more
than a workaround for one specific minor problem. Presumably if
"breakloop" appears outside a switch statement it means exactly
the same thing as "break". How are programmers to decide which
one to use? Would you want to deprecate the use of "break" other
than to break out of a switch statement?
We have decades of precedent that "break" is how you break out of a
loop. Your solution is to add a second way to do the same thing.
Sorry, but it's ugly. I'd rather use goto. And there's already
a more general solution planned for C2y.
[...]
> Simple, yes? Then you think that this could be done even more easily
> 50 years ago.
It could have been done more easily 50 years ago than now. Using,
say, "breaksw" for switch statements and "break" for loops would
have been equally easy, and a better solution that what you propose.
Allowing name for loops and switch statements is a more general
solution to this and other problems, it's already been implemented,
and it will almost certainly be standardized.
I dislike the default fallthrough behavior of switch statements.
If I were designing C today, I'd probably (a) *not* have default
fallthrough, (b) add something like a "fallthrough" keyword for
when you want it, and (c) have named loops. As of C2y, we'll have
(c) but not (a) and (b) -- and that's good enough.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 03:59 +0000 |
| Message-ID | <11amune$ipi$1@reader2.panix.com> |
| In reply to | #403132 |
In article <11amecs$10eab$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 13/10/2026 01:33, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> This is my first example expressed in C (note those first three args
>>> are passed by reference):
>>>
>>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>>> switch (pmtype)
>>> case pm_option: ...; break;
>>> case pm_sourcefile:
>>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>>> break;
>>>
>>> Except I can't use break like that. So I have to find a workaround.
>>
>> The code appears to be valid C that doesn't do what you want. I can't
>> easily tell what you want it to do. I don't know which of the two break
>> statements was intended to break out of the loop. A comment would have
>> solved that.
>>
>> I'm going to guess that the first break is supposed to apply to the
>> switch statement, and the second to the while loop.
>>
>> You want the language to be changed to make this kind of thing easier.
>>
>> That's already happening. If you take a look at the N3886 working
>> draft for C2y, it has named break statements. In C2y (or in gcc
>> if you use an extension), the above could be written as:
>>
>> WHILE:
>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>> SWITCH:
>> switch (pmtype)
>> case pm_option: ...; break SWITCH;
>> case pm_sourcefile:
>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>> break WHILE;
>>
>> assuming it's the second "break' that's supposed to break out of
>> the loop. (I'd probably use more meaninful names.)
>>
>> There is already a solution for the problem you're complaining about.
>> (It also solves the problem of breaking out of nested loops.)
>>
>> If you're unable to use this feature, you can use goto. That's not
>> ideal, but with well chosen label names and no backward branching
>> it's not too bad.
>
>I've got a better idea. I added an extra keyword to my C compiler called
>"breakloop". It's like 'break' but always works with the nearest
>enclosing loop, even from inside switch.
>
>So this example (a starts at 0):
>
> while (1) {
> switch (a++) {
> case 1: puts("one"); break;
> case 2: puts("two"); breakloop;
> case 3: puts("three"); break;
> default: puts("other");
> }
>
> if (a>40) break;
> }
>
>finishes after displaying 'two', instead of after the 37th or so 'other'.
>
>Modding the compiler took 90 seconds, and needed 4 extra lines of code.
>Setting up this test took 2-3 minutes.
>
>Simple, yes? Then you think that this could be done even more easily 50
>years ago.
Not really; for a general mechanism, if suffers from the obvious
deficiency that it doesn't compose.
For example, if the switch is inside of nested loops, and I
want to break out of everything, or I have two embedded switches
(which I have written when parsing firmware tables); I can think
of a number of instances where you might want to have switch
inside of nested loops and want to break out to function scope,
such as advancing states a la a Thompson-style NFA, where one
has a loop over the input text, a loop over the set of all
states, and a switch matching state against the current input
character, and you want to break out when you find a match.
Many other languages solve this using a "labeled break" (Go,
Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have
used a "counted"/"multi-level" break (Ruby, Perl; I think PHP).
You could have elegantly solved this problem by making `break`
take an optional integer argument, which is the number of levels
of structure to break out of. For a `switch` inside of a loop,
`break 2;` would exit both the case and the enclosing loop; for
a nested switch, `break 2;` would break out of both. Workable,
but in some respects the labeled form is better because it is
resilient to code shuffling around and changing nesting levels
and so forth.
An obvious next extension would be augmenting `continue`
similarly.
But as Keith pointed out, W14 is now entertaining proposals to
add labeled `break` to the language. I haven't looked myself,
but if that is usable in a `switch` context, then it would solve
the problem for good.
This illustrates one reason why changing a language can be hard:
your idea sounds good at first blush, but it has its own
deficiencies.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 21:35 -0700 |
| Message-ID | <11an0q3$14pou$4@kst.eternal-september.org> |
| In reply to | #403141 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> Many other languages solve this using a "labeled break" (Go,
> Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have
> used a "counted"/"multi-level" break (Ruby, Perl; I think PHP).
The only languages I know of that have a "counted break" (where
"break 2" breaks out of two levels of loops) are the Bourne shell
and shells derived from it, and PHP (you're right about that).
Perl has named break (spelled "last" or "last NAME") and continue
(spelled "next" or "next NAME). It does not have counted versions.
Ruby allows an argument on "break", but it's not the number of levels.
It specifies the value of the expression that it breaks out of. (A
loop is an expression that can yield a value.)
The latest draft of the C++ standard does not include labeled break
and continue statements. I don't know whether it's been proposed.
> You could have elegantly solved this problem by making `break`
> take an optional integer argument, which is the number of levels
> of structure to break out of.
I don't consider that elegant, for reasons I've already ranted about
here.
[...]
> But as Keith pointed out, W14 is now entertaining proposals to
> add labeled `break` to the language. I haven't looked myself,
> but if that is usable in a `switch` context, then it would solve
> the problem for good.
Yes, labeled "break" in C2y applies to both loops and switch statements.
There's also a labeled "continue" that applies only to loops.
The labels are optional, so existing code isn't broken.
The latest C2y draft is
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf>
(3.3 MB, 793 pages).
> This illustrates one reason why changing a language can be hard:
> your idea sounds good at first blush, but it has its own
> deficiencies.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 11:27 +0000 |
| Message-ID | <11anouc$5lo$1@reader2.panix.com> |
| In reply to | #403143 |
In article <11an0q3$14pou$4@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >[...] >> Many other languages solve this using a "labeled break" (Go, >> Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have >> used a "counted"/"multi-level" break (Ruby, Perl; I think PHP). > >The only languages I know of that have a "counted break" (where >"break 2" breaks out of two levels of loops) are the Bourne shell >and shells derived from it, and PHP (you're right about that). > >Perl has named break (spelled "last" or "last NAME") and continue >(spelled "next" or "next NAME). It does not have counted versions. > >Ruby allows an argument on "break", but it's not the number of levels. >It specifies the value of the expression that it breaks out of. (A >loop is an expression that can yield a value.) Ah, you're right and I was simply wrong about Perl and Ruby. I must have hallucinated those. Regarding expression oriented languages where constructs like loops can return values, it's somewhat ironic that BCPL could do something like that using its, `valof`/`resultis` mechanism; I have often wanted something like that in C; it would obviate the ternary operator. >The latest draft of the C++ standard does not include labeled break >and continue statements. I don't know whether it's been proposed. That's unfortunate. I wonder if that's merely an oversight, or a conscious decision; I'll have to look it up later. >> You could have elegantly solved this problem by making `break` >> take an optional integer argument, which is the number of levels >> of structure to break out of. > >I don't consider that elegant, for reasons I've already ranted about >here. Fair. I do believe that the labeled variant is better for a host of reasons, though I don't love the syntax, but that is merely a subjective aesthetic judgement on my part. >[...] > >> But as Keith pointed out, W14 is now entertaining proposals to >> add labeled `break` to the language. I haven't looked myself, >> but if that is usable in a `switch` context, then it would solve >> the problem for good. > >Yes, labeled "break" in C2y applies to both loops and switch statements. >There's also a labeled "continue" that applies only to loops. >The labels are optional, so existing code isn't broken. > >The latest C2y draft is ><https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf> >(3.3 MB, 793 pages). (Thanks; I've been meaning to download a copy of the latest draft anyway.) It seems that the matter is settled conclusively, and this entire thread is lots of heat and light generated for no reason. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 12:17 +0100 |
| Message-ID | <11anobe$1dt0e$1@dont-email.me> |
| In reply to | #403141 |
On 14/10/2026 04:59, Dan Cross wrote:
> In article <11amecs$10eab$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>> I've got a better idea. I added an extra keyword to my C compiler called
>> "breakloop". It's like 'break' but always works with the nearest
>> enclosing loop, even from inside switch.
>>
>> So this example (a starts at 0):
>>
>> while (1) {
>> switch (a++) {
>> case 1: puts("one"); break;
>> case 2: puts("two"); breakloop;
>> case 3: puts("three"); break;
>> default: puts("other");
>> }
>>
>> if (a>40) break;
>> }
>>
>> finishes after displaying 'two', instead of after the 37th or so 'other'.
>>
>> Modding the compiler took 90 seconds, and needed 4 extra lines of code.
>> Setting up this test took 2-3 minutes.
(I've now simplified it to adding one extra line and tweaking another!
I'd even suggest that using distinct keywords in the original C compiler
would have made it a tiny bit simpler.)
>> Simple, yes? Then you think that this could be done even more easily 50
>> years ago.
>
> Not really; for a general mechanism, if suffers from the obvious
> deficiency that it doesn't compose.
>
> For example, if the switch is inside of nested loops, and I
> want to break out of everything,
This isn't the problem being discussed. IME breaking of nested loops is
uncommon, but breaking out of a loop from inside switch /is/ common.
It's using the same 'break' keyword that makes that awkward in C. And my
experiment solves that easily.
> or I have two embedded switches
That's not a problem; 'breakloop' will completely ignore any switch
statements, in the same way that 'continue' does.
Unless you've invented a new requirement where you want 'break' within a
switch (itself solving an artificial problem) to jump straight to the
end of an outer switch.
> (which I have written when parsing firmware tables); I can think
> of a number of instances where you might want to have switch
> inside of nested loops and want to break out to function scope,
> such as advancing states a la a Thompson-style NFA, where one
> has a loop over the input text, a loop over the set of all
> states, and a switch matching state against the current input
> character, and you want to break out when you find a match.
'Jumping to function scope' is poorly defined. Do you mean cutting
across not only all loops, but any containing nested 'if' and 'switch'
statements?
So that would be a separate feature from loop-break? Would it still
involve loops at all, or could it be used from within any statement?
That sounds too general and wide-reaching; I think 'goto' is a much
better fit for that, if 'return' or 'defer' wouldn't work.
> Many other languages solve this using a "labeled break" (Go,
> Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have
> used a "counted"/"multi-level" break (Ruby, Perl; I think PHP).
>
> You could have elegantly solved this problem by making `break`
> take an optional integer argument, which is the number of levels
> of structure to break out of.
I could have done that in C but it would have taken more than 5 minutes,
and this was anyway a proof of concept.
I've already used that approach for some decades in my other languages,
but as I showed in the tables I posted, it is not common, and where
used, it was always to break out of all loops.
Anyway, I normally use 'all' instead of a specific number to quit all
loops. A number works too but I dislike it.
> For a `switch` inside of a loop,
> `break 2;` would exit both the case and the enclosing loop; for
> a nested switch, `break 2;` would break out of both. Workable,
> but in some respects the labeled form is better because it is
> resilient to code shuffling around and changing nesting levels
> and so forth.
No, it just has a different set of problems. For example, you label the
outer loop and exit to that. Now you add an extra outer loop layer: does
that label go inside this new loop or outside?
That depends on the intended logic, which you don't know.
Maybe the original set of loop performed some task T, and the new loop
wants to repeat T, in which case it must stay inside.
Or maybe it is really has to quit ALL loops including any future outer
ones. Neither labeling or numbering solves this.
Labeled loops may also have a new problem with scoping: is the loop name
local to this nest of loops, or could an outer loop name especially
clash with other loop elsewhere?
> An obvious next extension would be augmenting `continue`
> similarly.
In my other languages, I use 'exit' for break, and 'nextloop' for
continue, and 'redoloop' to repeat iteration. (The latter will have
different behaviour inside a for-loop with formal loop variables.)
I've just done a survey in my major apps and haven't found an instance
where those latter two needed to cross two or more loops.
Although I am sure C programmers would put 'continue x' to good use if
it was available!
> 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!
And maybe those scoping rules will be different: goto labels have
function-wide scope.
> This illustrates one reason why changing a language can be hard:
> your idea sounds good at first blush, but it has its own
> deficiencies.
I appreciate your concern. I've only been doing this (devising and
implementing systems languages) for 45 years!
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 12:38 +0000 |
| Message-ID | <11ant3u$6o$1@reader2.panix.com> |
| In reply to | #403148 |
In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 14/10/2026 04:59, Dan Cross wrote:
>> In article <11amecs$10eab$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>> I've got a better idea. I added an extra keyword to my C compiler called
>>> "breakloop". It's like 'break' but always works with the nearest
>>> enclosing loop, even from inside switch.
>>>
>>> So this example (a starts at 0):
>>>
>>> while (1) {
>>> switch (a++) {
>>> case 1: puts("one"); break;
>>> case 2: puts("two"); breakloop;
>>> case 3: puts("three"); break;
>>> default: puts("other");
>>> }
>>>
>>> if (a>40) break;
>>> }
>>>
>>> finishes after displaying 'two', instead of after the 37th or so 'other'.
>>>
>>> Modding the compiler took 90 seconds, and needed 4 extra lines of code.
>>> Setting up this test took 2-3 minutes.
>
>(I've now simplified it to adding one extra line and tweaking another!
>
>I'd even suggest that using distinct keywords in the original C compiler
>would have made it a tiny bit simpler.)
Unlikely. I'm trying to chase down the citation, but it was
known that getting B to fit on the PDP-7 was a challenge. From
the C history paper,
|After the TMG version of B was working, Thompson rewrote B in
|itself (a bootstrapping step). During development, he
|continually struggled against memory limitations: each language
|addition inflated the compiler so it could barely fit, but each
|rewrite taking advantage of the feature reduced its size. For
|example, B introduced generalized assignment operators, using
|`x=+y` to add `y` to `x`. The notation came from Algol 68
|[Wijngaarden 75] via McIlroy, who had incorporated it into his
|version of TMG. (In B and early C, the operator was spelled
|`=+` instead of `+=`; this mistake, repaired in 1976, wa
| induced by a seductively easy way of handling the first form
|in B's lexical analyzer.)
(https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html)
[Context: "TMG" was a compiler-compiler, similar to yacc]
Early C was not much better. Compiler sources for some of the
earliest Unix C compilers are available, and pretty interesting
reads: one can see that great pains were taken so that the
compiler actually fits onto the machine. By the time they were
on a PDP-11/45 class machine (with split I- and D-space) things
were somewhat better, but by then the basic design of the
language was set and adding an extra keyword just for
terminating cases in a `switch` was likely seen as unnecessary.
>>> Simple, yes? Then you think that this could be done even more easily 50
>>> years ago.
>>
>> Not really; for a general mechanism, if suffers from the obvious
>> deficiency that it doesn't compose.
>>
>> For example, if the switch is inside of nested loops, and I
>> want to break out of everything,
>
>This isn't the problem being discussed. IME breaking of nested loops is
>uncommon, but breaking out of a loop from inside switch /is/ common.
The irony here, of course, is that you are claiming that C is
deficient because it doesn't solve what you see as a problem,
but trying to force the problem space specifically so that it
fits the solution your proposed, so that you can avoid
confronting that proposal's deficiencies.
The problem space is actually much wider than what you have
narrowly defined it to be. *You* don't see that as interesting,
so you simply ignore it.
In this sense, your proposal is strictly a regression: it adds
complexity to the language by introducing a new keyword, but it
only solves one tiny problem, but nothing beyond that.
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).
>It's using the same 'break' keyword that makes that awkward in C. And my
>experiment solves that easily.
...except for all the other cases where it is still awkward and
solves nothing.
>> or I have two embedded switches
>
>That's not a problem; 'breakloop' will completely ignore any switch
>statements, in the same way that 'continue' does.
Yes, but it does nothing to break out of the outer switch, if
that's what I want; the inner switch might be followed by more
statements in the case it is nested in.
>Unless you've invented a new requirement where you want 'break' within a
>switch (itself solving an artificial problem) to jump straight to the
>end of an outer switch.
Yes, that's exactly what I'm saying. Again, you've identified
one narrow problem, proposed a solution for that problem, and
decided any identified issues with that solution don't apply
because they don't affect the narrowly defined problem that you
have decided is important.
Past behavior suggests that you imagine that anyone pointing out
a reason why your solution may not be everything you think it is
is somehow unfairly changing the rules of the game in order to
give you a hard time. But consider: perhaps they're just
pointing out a reason why your solution isn't optimal.
I think this is the central reason people don't take your
criticism of C particularly seriously. There is space for
discussing how C _could_ be different, but if you are not
willing to engage in actually understanding the problems, and
actually, I don't know, having a discussion about your proposed
solutions and recognizing when they fall short, then you're not
being serious.
>> (which I have written when parsing firmware tables); I can think
>> of a number of instances where you might want to have switch
>> inside of nested loops and want to break out to function scope,
>> such as advancing states a la a Thompson-style NFA, where one
>> has a loop over the input text, a loop over the set of all
>> states, and a switch matching state against the current input
>> character, and you want to break out when you find a match.
>
>'Jumping to function scope' is poorly defined. Do you mean cutting
>across not only all loops, but any containing nested 'if' and 'switch'
>statements?
What I mean is this:
void
foo(void)
{
for (int i = 0; i < n; i++) {
for (int j = 0; j < m; i++) {
switch (something) {
case ...:
// I want to break out
// of the switch and
// both loops here.
goto label;
}
}
}
label:
}
>So that would be a separate feature from loop-break? Would it still
>involve loops at all, or could it be used from within any statement?
>
>That sounds too general and wide-reaching; I think 'goto' is a much
>better fit for that, if 'return' or 'defer' wouldn't work.
Why? The labeled break mechanism that looks like it's coming in
C2Y neatly solves this and your original problem; it's a
consistent, general mechanism. It also handles loops inside of
switches, and other cases your proposal doesn't handle.
>> Many other languages solve this using a "labeled break" (Go,
>> Rust, C#, Kotlin, Java, Ada, Pike, and now C), though some have
>> used a "counted"/"multi-level" break (Ruby, Perl; I think PHP).
>>
>> You could have elegantly solved this problem by making `break`
>> take an optional integer argument, which is the number of levels
>> of structure to break out of.
>
>I could have done that in C but it would have taken more than 5 minutes,
>and this was anyway a proof of concept.
Yup. And it took less than that to point out problems.
>I've already used that approach for some decades in my other languages,
>but as I showed in the tables I posted, it is not common, and where
>used, it was always to break out of all loops.
>
>Anyway, I normally use 'all' instead of a specific number to quit all
>loops. A number works too but I dislike it.
That sounds overly specific.
>> For a `switch` inside of a loop,
>> `break 2;` would exit both the case and the enclosing loop; for
>> a nested switch, `break 2;` would break out of both. Workable,
>> but in some respects the labeled form is better because it is
>> resilient to code shuffling around and changing nesting levels
>> and so forth.
>
>No, it just has a different set of problems. For example, you label the
>outer loop and exit to that. Now you add an extra outer loop layer: does
>that label go inside this new loop or outside?
This is actually the argument against the counted multi-level
break: if I add or remove a level of nesting, I have to find and
adjust all of the counts. The labeled break mechanism ties the
`break` or `continue` to another syntactic element (a label), so
if I add or remove a nesting level, I'm still breaking to where
I had intended to before.
That said, applying the argument to the labeled case is silly.
Software engineering and good programming practice still matter.
If you are changing the nested looping structure of your
program, then you should know where you want to break to;
presumably your program's behavior depends on it.
I'd say the stronger argument for the labeled control structure
is actually nested switch statements, where I may change a
series of `if`s to a `switch` with a `case` that contains a
nested `switch`, or I may change a `switch` to an `if`; if the
intent is to break out of an enclosing loop, labeled breaks are
resilient to that, but counted breaks are not.
>That depends on the intended logic, which you don't know.
Yes.
>Maybe the original set of loop performed some task T, and the new loop
>wants to repeat T, in which case it must stay inside.
Yes.
>Or maybe it is really has to quit ALL loops including any future outer
>ones. Neither labeling or numbering solves this.
No. If I want to break out of *all* loops, I just make sure
that the outermost loop is labeled thusly.
>Labeled loops may also have a new problem with scoping: is the loop name
>local to this nest of loops, or could an outer loop name especially
>clash with other loop elsewhere?
Since labels are, you know, labels, they follow the semantics of
... labels.
>> An obvious next extension would be augmenting `continue`
>> similarly.
>
>In my other languages, I use 'exit' for break, and 'nextloop' for
>continue, and 'redoloop' to repeat iteration. (The latter will have
>different behaviour inside a for-loop with formal loop variables.)
>
>I've just done a survey in my major apps and haven't found an instance
>where those latter two needed to cross two or more loops.
Anecdotal evidence, I'm afraid.
>Although I am sure C programmers would put 'continue x' to good use if
>it was available!
Yes.
>> 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!
The problem there is that `break` and `continue` would require
different labels: `continue loop;` conceptually jumps to the
_end_ of the loop body, and resumes on the next iteration, while
`break loop;` jumps to the next statement immediately following
the loop body. With the named-label mechanism, the same "name"
can be used for both.
>And maybe those scoping rules will be different: goto labels have
>function-wide scope.
It's easy enough to look it up in the draft document; Keith
posted a link.
>> This illustrates one reason why changing a language can be hard:
>> your idea sounds good at first blush, but it has its own
>> deficiencies.
>
>I appreciate your concern. I've only been doing this (devising and
>implementing systems languages) for 45 years!
That really doesn't mean anything. Just doing something for a
long time doesn't mean you're good at it: I have been shooting
baskets for 45 years, but I will never be a point guard in the
NBA.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 16:49 +0100 |
| Message-ID | <11ao8af$1k8p3$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:
>> I'd even suggest that using distinct keywords in the original C compiler
>> would have made it a tiny bit simpler.)
>
> Unlikely. I'm trying to chase down the citation, but it was
> known that getting B to fit on the PDP-7 was a challenge. From
> the C history paper,
Perhaps Switch should have been left out then if it was that tight.
Sharing a keyword is just crass. Or maybe they should have considered
not needing 'break' for switch.
> The irony here, of course, is that you are claiming that C is
> deficient because it doesn't solve what you see as a problem,
> but trying to force the problem space specifically so that it
No, /you/ are trying to discredit a simple solution by widening the
goalposts.
The main problem being discussed, and the one my test fixed, is that of
'break' being used for two purposes and therefore resulting in clashes
when Switches and Loops are mixed.
That could easily have been fixed by DMR choosing to use distinct
keywords. Do you agree so far?
That of breaking out of nested loops is a different problem that would
need a different solution, and nothing to do with the clash with switch.
It is also one that seems to be about 100 times less common IME.
> ...except for all the other cases where it is still awkward and
> solves nothing.
IT WAS ONLY SUPPOSED TO SOLVE THIS PROBLEM! Namely the issues that
ensued from DMR overloading 'break'. NOTHING ELSE.
In fact the confusion between switch-break and loop-break will still be
there even if labels are added.
>> Unless you've invented a new requirement where you want 'break' within a
>> switch (itself solving an artificial problem) to jump straight to the
>> end of an outer switch.
>
> Yes, that's exactly what I'm saying. Again, you've identified
> one narrow problem,
It's not that narrow a problem, unless you want to call loops themselves
a narrow feature.
It is one that many languages solve for LOOPs by using break or
equivalent. But they tend not to broaden it either to include breaks out
of arbitrary kinds of blocks.
> I think this is the central reason people don't take your
> criticism of C particularly seriously.
I'm sorry but here I don't take yours seriously either. (Have you ever
implemented any of this stuff, or even used such features that you propose?)
>> 'Jumping to function scope' is poorly defined. Do you mean cutting
>> across not only all loops, but any containing nested 'if' and 'switch'
>> statements?
>
> What I mean is this:
>
> void
> foo(void)
> {
> for (int i = 0; i < n; i++) {
> for (int j = 0; j < m; i++) {
> switch (something) {
> case ...:
> // I want to break out
> // of the switch and
> // both loops here.
> goto label;
> }
> }
> }
> label:
> }
This example just breaks out of both loops. That the outer one is at
function scope is incidental.
If the outer loop was contained within an IF statement, could you jump
to outside that statement using your proposed feature? If not then that
is not function scope.
>> I could have done that in C but it would have taken more than 5
minutes,>> and this was anyway a proof of concept.
>
> Yup. And it took less than that to point out problems.
But it solved the problem I wanted to solve! It would solve the problem
Michael S reported! That is, using distinct keywords for two different
things.
>> I've already used that approach for some decades in my other languages,
>> but as I showed in the tables I posted, it is not common, and where
>> used, it was always to break out of all loops.
>>
>> Anyway, I normally use 'all' instead of a specific number to quit all
>> loops. A number works too but I dislike it.
>
> That sounds overly specific.
So is breaking out of an inner loop with 'break;'! But it works well as
it's by far the most common requirement. The next most common IME is to
quit all loops (like you do in your example).
In fact, if there are only two nested loops, the inner and outer cover
all the possibilities.
> This is actually the argument against the counted multi-level
> break: if I add or remove a level of nesting, I have to find and
> adjust all of the counts. The labeled break mechanism ties the
> `break` or `continue` to another syntactic element (a label), so
No, it's just another set of problems as I said.
You can add new inner loops, delete inner loops, add outer ones, and
each time you will need to consider whether the labels need to be moved,
or extra ones added.
Here's another solution I favour (not implemented), but it only works
for FOR loops:
for i in a..b
for j in c..d
... break i
It's a little like using a label, but here that 'label' is the loop
index. (This won't work in C as there are no formal loop indices.)
> if I add or remove a nesting level, I'm still breaking to where
> I had intended to before.
Yes, but that might now be the wrong loop.
> That said, applying the argument to the labeled case is silly.
> Software engineering and good programming practice still matter.
> If you are changing the nested looping structure of your
> program, then you should know where you want to break to;
> presumably your program's behavior depends on it.
Agreed; see below.
> I'd say the stronger argument for the labeled control structure
> is actually nested switch statements, where I may change a
> series of `if`s to a `switch` with a `case` that contains a
> nested `switch`, or I may change a `switch` to an `if`; if the
> intent is to break out of an enclosing loop, labeled breaks are
> resilient to that, but counted breaks are not.
You're assuming that the count in indexed breaks includes switch
statements. It shouldn't; that would be preposterous, and it all still
comes down to the shared 'break' keyword.
How about fixing that first, or even admitting it was wrong, before
>> Maybe the original set of loop performed some task T, and the new
loop>> wants to repeat T, in which case it must stay inside.
>
> Yes.
>
>> Or maybe it is really has to quit ALL loops including any future outer
>> ones. Neither labeling or numbering solves this.
>
> No. If I want to break out of *all* loops, I just make sure
> that the outermost loop is labeled thusly.
But in my first example, that is not what you want! It all depends.
I don't like using multi-level loop exit, it's an untidy feature even
though I implement it. And I don't like using labeled solutions, as they
just turn them into thinly disguised gotos.
>> Labeled loops may also have a new problem with scoping: is the loop name
>> local to this nest of loops, or could an outer loop name especially
>> clash with other loop elsewhere?
>
> Since labels are, you know, labels, they follow the semantics of
> ... labels.
Careful here: do you really mean that loop-labels will be in the same
name-space as ordinary labels? That means:
* Getting clashes when a labeled loop is copied elsewhere within the
function
* Being able to do an ordinary 'goto' to a loop-label ...
* ... which will also be confusing when loop labels are placed at the
beginning of a loop rather than the end:
L1:
while () {
goto L1: This jumps to L1
goto L2; This jumps to L2
continue L1; This jumps to L2
break L1; This jumps to L3
L2:
}
L3:
See there's a bit more to this language-design lark!
>> I've just done a survey in my major apps and haven't found an instance
>> where those latter two needed to cross two or more loops.
>
> Anecdotal evidence, I'm afraid.
You're welcome to post your own surveys. Although unless the languages
used in your survey support such features, you may find that hard.
> It's easy enough to look it up in the draft document; Keith
> posted a link.
Is that that 793-page document? Perhaps you can summarise how it works!
>
>>> This illustrates one reason why changing a language can be hard:
>>> your idea sounds good at first blush, but it has its own
>>> deficiencies.
>>
>> I appreciate your concern. I've only been doing this (devising and
>> implementing systems languages) for 45 years!
>
> That really doesn't mean anything. Just doing something for a
> long time doesn't mean you're good at it: I have been shooting
> baskets for 45 years, but I will never be a point guard in the
> NBA.
And yet I've solved all the problems in this thread and many others.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 19:30 +0000 |
| Message-ID | <11aol8k$adq$1@reader2.panix.com> |
| In reply to | #403155 |
In article <11ao8af$1k8p3$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:
>>> I'd even suggest that using distinct keywords in the original C compiler
>>> would have made it a tiny bit simpler.)
>>
>> Unlikely. I'm trying to chase down the citation, but it was
>> known that getting B to fit on the PDP-7 was a challenge. From
>> the C history paper,
>
>Perhaps Switch should have been left out then if it was that tight.
Why? It's genuinely useful.
>Sharing a keyword is just crass.
Don't you share `end`?
>Or maybe they should have considered
>not needing 'break' for switch.
Maybe? And yet here we are, 50+ years later.
>> The irony here, of course, is that you are claiming that C is
>> deficient because it doesn't solve what you see as a problem,
>> but trying to force the problem space specifically so that it
>
>No, /you/ are trying to discredit a simple solution by widening the
>goalposts.
Here we go again. Suffice it to say, no one is trying to
persecute you. People would take you more seriously if you
stopped whining about being a victim all the time.
>The main problem being discussed,
No, that is the problem _you_ are discussing. You're ignoring
any other problem anyone else points out, and you seem incapable
of considering that people might be dismissing your proposed
solution because it doesn't solve enough of a problem, and other
mechanisms are more general.
I recognize you are not going to understand, let alone
appreciate, the distinction here.
>and the one my test fixed, is that of
>'break' being used for two purposes and therefore resulting in clashes
>when Switches and Loops are mixed.
And what many others in this thread have told you is that that
is a "problem" that is trivially worked around, that a special
case for _that problem only_ is not worth it, and that a more
general solution is being added to the language in C2y.
What more do you want anyone to say?
>That could easily have been fixed by DMR choosing to use distinct
>keywords. Do you agree so far?
No. You've described what I consider to be a non-problem; a
mild annoyance at best, and certainly not something that
deserves complicating the language for.
The general category is more interesting, which is what I (and
probably others) have been trying to tell you. Instead of
appreciating that a more general solution to the entire category
of problems, that oh-by-the-way also solves this specific
problem exists, you instead whine about people moving goalposts.
No wonder the language never gets better in your view; you can't
see anything beyond your way of doing things.
>That of breaking out of nested loops is a different problem that would
>need a different solution, and nothing to do with the clash with switch.
Wrong. The new solution shows that it's actually the same
solution to the entire category of problems. And that's the
issue: it doesn't _need_ a different solution.
>It is also one that seems to be about 100 times less common IME.
...and yet it's easily solved using the labeled break mechanism
that is _already in the C2y draft_.
>> ...except for all the other cases where it is still awkward and
>> solves nothing.
>
>IT WAS ONLY SUPPOSED TO SOLVE THIS PROBLEM! Namely the issues that
>ensued from DMR overloading 'break'. NOTHING ELSE.
But that problem is easily solved using labeled breaks.
Overloading `break` is orthogonal to the solution.
>In fact the confusion between switch-break and loop-break will still be
>there even if labels are added.
I don't know that many C programmers are "confused" by the two
uses of that single keyword. Certainly, I've seen no evidence
that such confusion is widespread.
>>> Unless you've invented a new requirement where you want 'break' within a
>>> switch (itself solving an artificial problem) to jump straight to the
>>> end of an outer switch.
>>
>> Yes, that's exactly what I'm saying. Again, you've identified
>> one narrow problem,
>
>It's not that narrow a problem, unless you want to call loops themselves
>a narrow feature.
>
>It is one that many languages solve for LOOPs by using break or
>equivalent. But they tend not to broaden it either to include breaks out
>of arbitrary kinds of blocks.
I posted a bunch of languages that use labeled breaks earlier.
>> I think this is the central reason people don't take your
>> criticism of C particularly seriously.
>
>I'm sorry but here I don't take yours seriously either. (Have you ever
>implemented any of this stuff, or even used such features that you propose?)
Yes.
>>> 'Jumping to function scope' is poorly defined. Do you mean cutting
>>> across not only all loops, but any containing nested 'if' and 'switch'
>>> statements?
>>
>> What I mean is this:
>>
>> void
>> foo(void)
>> {
>> for (int i = 0; i < n; i++) {
>> for (int j = 0; j < m; i++) {
>> switch (something) {
>> case ...:
>> // I want to break out
>> // of the switch and
>> // both loops here.
>> goto label;
>> }
>> }
>> }
>> label:
>> }
>
>This example just breaks out of both loops. That the outer one is at
>function scope is incidental.
>
>If the outer loop was contained within an IF statement, could you jump
>to outside that statement using your proposed feature? If not then that
>is not function scope.
I thought that the context would have made it obvious what I
meant. I think you are attempting to be pedantic because you
want to save face by scoring a rhetorical point. Fine, my
earlier phrasing was poor. Happy?
With labeled break, this is actually quite clear: `break foo;`
jumps to the point immediately after the loop or switch
construct "named" by the label `foo`. Perhaps if you were more
familiar with the problem space it would have have been clearer.
> >> I could have done that in C but it would have taken more than 5
>minutes,>> and this was anyway a proof of concept.
>>
>> Yup. And it took less than that to point out problems.
>
>But it solved the problem I wanted to solve! It would solve the problem
>Michael S reported! That is, using distinct keywords for two different
>things.
That's the thing: that's not what the fundamental problem is.
The _actual_ problem is that, because of that and absent some
more expressive mechanism like a labeled break, you have no way
to express that you want to leave anything more than the most
deeply nested level.
for (;;) {
int ch = getchar();
switch (ch) {
case EOF:
break; // No way to say break out of the loop.
case 'a':
// ...whatever you want to do with 'a'....
break; // Continue the loop.
default:
// whatever....
break;
}
}
You are fixating on the overloaded keyword as _the problem_ and
thus intent on addressing that as _the solution_. But there the
_problem_ is actually more general. Here's how this might be
addressed using a labeled break:
loop: for (;;) {
int ch = getchar();
switch (ch) {
case EOF:
break loop;
case 'a':
// whatever.
break;
default:
// whatever.
break;
}
}
// Control resumes here after `break loop` above.
See? Problem solved. Along with a bunch of _other_ problems:
sw: switch (foo) {
case 'a':
while ((bar = whatever()) != -1) {
if (bar == SOMETHING) break sw;
}
whatnot();
break;
default:
// etc....
break;
}
>>> I've already used that approach for some decades in my other languages,
>>> but as I showed in the tables I posted, it is not common, and where
>>> used, it was always to break out of all loops.
>>>
>>> Anyway, I normally use 'all' instead of a specific number to quit all
>>> loops. A number works too but I dislike it.
>>
>> That sounds overly specific.
>
>So is breaking out of an inner loop with 'break;'! But it works well as
>it's by far the most common requirement. The next most common IME is to
>quit all loops (like you do in your example).
>
>In fact, if there are only two nested loops, the inner and outer cover
>all the possibilities.
...and all of this can be done with labeled break, which is
being added to the language.
Look, bart! Rejoice! The 50 year sin cardinal sin of Ritchie is
being corrected! Surely you must be simultaneously vindicated
and elated.
>> This is actually the argument against the counted multi-level
>> break: if I add or remove a level of nesting, I have to find and
>> adjust all of the counts. The labeled break mechanism ties the
>> `break` or `continue` to another syntactic element (a label), so
>
>No, it's just another set of problems as I said.
Not really.
>You can add new inner loops, delete inner loops, add outer ones, and
>each time you will need to consider whether the labels need to be moved,
>or extra ones added.
Yup. Welcome to being a programmer. Play your cards right and
one day you may even graduate to being a software engineer.
>Here's another solution I favour (not implemented), but it only works
>for FOR loops:
>
> for i in a..b
> for j in c..d
> ... break i
>
>It's a little like using a label, but here that 'label' is the loop
>index. (This won't work in C as there are no formal loop indices.)
And with C2y, you can write:
outer: for (int i = a, i < b; i++) {
for (int j = c; j < d; j++) {
// ...
break outer;
}
}
// We continue here after `break outer`.
Problem solved.
>> if I add or remove a nesting level, I'm still breaking to where
>> I had intended to before.
>
>Yes, but that might now be the wrong loop.
Yup. But note the difference between "may be" and "will be".
With counts, it will be. And as I said, none of these
constructs absolve one of the responsibility to be a competent
programmer.
>> That said, applying the argument to the labeled case is silly.
>> Software engineering and good programming practice still matter.
>> If you are changing the nested looping structure of your
>> program, then you should know where you want to break to;
>> presumably your program's behavior depends on it.
>
>Agreed; see below.
>
>> I'd say the stronger argument for the labeled control structure
>> is actually nested switch statements, where I may change a
>> series of `if`s to a `switch` with a `case` that contains a
>> nested `switch`, or I may change a `switch` to an `if`; if the
>> intent is to break out of an enclosing loop, labeled breaks are
>> resilient to that, but counted breaks are not.
>
>You're assuming that the count in indexed breaks includes switch
>statements. It shouldn't; that would be preposterous, and it all still
>comes down to the shared 'break' keyword.
>
>How about fixing that first, or even admitting it was wrong, before
That's the thing; it's orthogonal to the root problem. "Admit
that it was wrong" is the wrong way to look at it. Was it
weird? I dunno; maybe. Unconventional at the time? I have no
idea. Fundamentally broken? No.
> >> Maybe the original set of loop performed some task T, and the new
>loop>> wants to repeat T, in which case it must stay inside.
>>
>> Yes.
>>
>>> Or maybe it is really has to quit ALL loops including any future outer
>>> ones. Neither labeling or numbering solves this.
>>
>> No. If I want to break out of *all* loops, I just make sure
>> that the outermost loop is labeled thusly.
>
>But in my first example, that is not what you want! It all depends.
As I said, welcome to being a programmer. Hard, isn't it?
>I don't like using multi-level loop exit, it's an untidy feature even
>though I implement it. And I don't like using labeled solutions, as they
>just turn them into thinly disguised gotos.
ALL of these control constructs are "thinly disguised gotos."
That is the arc of development over time: we started with blunt
instruments like `goto`, and refined practices to where we have
identified useful patterns, that we then extract into first
class constructs of their own.
This ebbs and flows over time; C++-style exceptions were seen as
a necessary feature at one point, now many people strive to
avoid them; Google prohibits their use outright, in a code base
with billions of lines of code written in that language.
>>> Labeled loops may also have a new problem with scoping: is the loop name
>>> local to this nest of loops, or could an outer loop name especially
>>> clash with other loop elsewhere?
>>
>> Since labels are, you know, labels, they follow the semantics of
>> ... labels.
>
>Careful here: do you really mean that loop-labels will be in the same
>name-space as ordinary labels? That means:
Yes, that's what I mean. Go read the draft standard yourself.
>[snip chest thumping puffery]
>
>See there's a bit more to this language-design lark!
Indeed! You demonstrated just how easily it can break down with
your `breakloop` proposal.
>>> I've just done a survey in my major apps and haven't found an instance
>>> where those latter two needed to cross two or more loops.
>>
>> Anecdotal evidence, I'm afraid.
>
>You're welcome to post your own surveys. Although unless the languages
>used in your survey support such features, you may find that hard.
I'm not the one trying to make the point you are attempting to
make. You made a claim; the onus is on you to provide evidence
for that claim.
>> It's easy enough to look it up in the draft document; Keith
>> posted a link.
>
>Is that that 793-page document? Perhaps you can summarise how it works!
I understand; it's a difficult document to follow when you are
already pre-biased to disregard what it says, as you have
repeatedly shown yourself to be.
In this case, it's not too hard, though; the second page says,
|The following changes were made on or after the 2024
|September/October Minneapolis, USA meeting:
|
| ...about 2/3rds of the way down the list...
| - N3355: Named/Labeled Loops
So we can look at N3355 for discussion:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
That's much shorter than the 793-page draft standard. Perhaps
you'll find it easier to understand.
>>>> This illustrates one reason why changing a language can be hard:
>>>> your idea sounds good at first blush, but it has its own
>>>> deficiencies.
>>>
>>> I appreciate your concern. I've only been doing this (devising and
>>> implementing systems languages) for 45 years!
>>
>> That really doesn't mean anything. Just doing something for a
>> long time doesn't mean you're good at it: I have been shooting
>> baskets for 45 years, but I will never be a point guard in the
>> NBA.
>
>And yet I've solved all the problems in this thread and many others.
Congratulations! And yet, despite you being obviously more
intelligent than all of Ritchie, McIlroy, Thompson, Johnson,
Kernighan, Plauger, and all of those who have and continue to
contribute to the development of C combined, we don't see your
name on the list of contributors to that language, nor does
anyone other than you use your language.
But keep shooting hoops, bart. Maybe some day a talent scout
will see you in your driveway and give you a starting position
on a playoff team.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-14 23:28 +0300 |
| Message-ID | <20261014232810.0000352a@yahoo.com> |
| In reply to | #403162 |
On Wed, 14 Oct 2026 19:30:28 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
> In article <11ao8af$1k8p3$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:
> >>> I'd even suggest that using distinct keywords in the original C
> >>> compiler would have made it a tiny bit simpler.)
> >>
> >> Unlikely. I'm trying to chase down the citation, but it was
> >> known that getting B to fit on the PDP-7 was a challenge. From
> >> the C history paper,
> >
> >Perhaps Switch should have been left out then if it was that tight.
>
> Why? It's genuinely useful.
>
C switch is in the middle between low level construct (computed goto)
and higher level select/case/whatever of many other languages.
I suppose that implementing true low level alternative would have been
simpler for compiler. And it would be even more powerful than current
construct. Of course, also more dangerous, but being dangerous is not
against C philosophy.
int foo()
{
...
case 42:
....
switch(bar(x)); // can go not just to 6 and 7, but to 42 as well.
// if there is no 'default:' in the scope then default ends up here
....
case 6:
...
case 7:
etc...
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-14 21:30 -0700 |
| Message-ID | <86o6cvr3g4.fsf@linuxsc.com> |
| In reply to | #403166 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 14 Oct 2026 19:30:28 -0000 (UTC)
> cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> In article <11ao8af$1k8p3$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:
>>>>
>>>>> I'd even suggest that using distinct keywords in the original C
>>>>> compiler would have made it a tiny bit simpler.)
>>>>
>>>> Unlikely. I'm trying to chase down the citation, but it was
>>>> known that getting B to fit on the PDP-7 was a challenge. From
>>>> the C history paper,
>>>
>>> Perhaps Switch should have been left out then if it was that tight.
>>
>> Why? It's genuinely useful.
>
> C switch is in the middle between low level construct (computed goto)
> and higher level select/case/whatever of many other languages.
> I suppose that implementing true low level alternative would have been
> simpler for compiler. And it would be even more powerful than current
> construct. Of course, also more dangerous, but being dangerous is not
> against C philosophy.
>
> int foo()
> {
> ...
> case 42:
> ....
> switch(bar(x)); // can go not just to 6 and 7, but to 42 as well.
> // if there is no 'default:' in the scope then default ends up here
> ....
> case 6:
> ...
> case 7:
> etc...
>
> }
I'm reminded of a quote from E.W. Dijkstra:
"No, gentlemen. Three times no."
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 21:56 +0100 |
| Message-ID | <11aoqa9$1rgda$1@dont-email.me> |
| In reply to | #403162 |
On 14/10/2026 20:30, Dan Cross wrote:
> In article <11ao8af$1k8p3$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>> Perhaps Switch should have been left out then if it was that tight.
>
> Why? It's genuinely useful.
If-else chains can do the same job.
>> Sharing a keyword is just crass.
>
> Don't you share `end`?
No, that has one meaning which is to terminate a block, there are no
repercussions as there are with C-break which has two meanings.
>> That could easily have been fixed by DMR choosing to use distinct
>> keywords. Do you agree so far?
>
> No. You've described what I consider to be a non-problem; a
> mild annoyance at best, and certainly not something that
> deserves complicating the language for.
I'd call it a 'howler'. Even if trivial, it was ludicrously simple to
avoid, and Michael S wouldn't have needed workarounds or to have waited
for C2y to be generally available which provides an official workaround.
Yes, in the simple case of while-switch (see below) it is still
something extra that is need to overcome that 1972 boo-boo.
> So we can look at N3355 for discussion:
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
I found it eventually. But I saw two proposals, I think the other was
N3357(?). The difference is that the latter puts the loop label after
the keyword, so 'for label (' rather than 'label: for (', which makes
the labels local to the loop, so avoiding the issues below.
gcc 16.2.0 seems to implement N3355, so the points I made are actually
true, which is surprising. So here:
L1:
while (1) {
goto L1; // jumps to L1
continue L1; // jumps to just before }
break L1; // jumps to just after }
}
L1: // error: duplicate label
while ...
Meanwhile:
while (1) {
if (x == 3)
break; // this quits the loop as before
}
while (1) {
switch (x) {
case 3:
break; // this doesn't break the loop
}
}
So this part hasn't changed. What's changed is that there is a more
direct workaround:
loop:
while (1) {
switch (x) {
case 3:
break loop; // this doesn't break the loop
}
}
Which looks remarkably like the solution I knocked up in 2 minutes:
while (1) {
switch (x) {
case 3:
breakloop; // this doesn't break the loop
}
}
The difference is, I can consistently use 'breakloop' everywhere: I can
duplicate this in the same function. But the 'loop' label is unique to
that while-loop. (This is what NN3357 or whatever could have fixed.)
As for multiple nested loops, this will fix that too, that's great. We
just require some real examples of that being needed!
>> And yet I've solved all the problems in this thread and many others.
> Congratulations! And yet, despite you being obviously more
> intelligent than all of Ritchie, McIlroy, Thompson, Johnson,
> Kernighan, Plauger, and all of those who have and continue to
> contribute to the development of C combined,
Well, my personal C has 'breakloop'! Usually these micro-extensions are
shortlived, but I'll keep this one.
we don't see your
> name on the list of contributors to that language, nor does
> anyone other than you use your language.
It's enough that I used it and benefited from it.
This is that last example in my syntax (if the switch were the only
statement within the loop otherwise two more tokens needed):
doswitch x
when 3 then exit
end
7 tokens vs. 20 tokens using N3355, and it's repeatable within the
function because 'exit' is relative.
> But keep shooting hoops, bart. Maybe some day a talent scout
> will see you in your driveway and give you a starting position
> on a playoff team.
I really don't care. Most things in the world are not going the way I'd
like, and I'm not the only one who thinks that.
This language stuff is small potatoes but it gives me kick to have long
ago come up with solutions that some languages take ... 54 years to
produce a compromise.
Anyway, at least you've been a sport, unlike Mr. P.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 21:59 +0100 |
| Message-ID | <11aoqfp$1rgda$2@dont-email.me> |
| In reply to | #403167 |
On 14/10/2026 21:56, bart wrote: > On 14/10/2026 20:30, Dan Cross wrote: > break loop; // this doesn't break the loop > breakloop; // this doesn't break the loop Ignore those comments, which are not true!
[toc] | [prev] | [next] | [standalone]
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web