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 423 — 22 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 David Brown <david.brown@hesbynett.no> - 2026-10-18 12:48 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 12:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:09 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:34 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:13 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:52 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:16 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 20:47 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 22:38 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 11:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 03:50 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:59 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:28 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:05 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 14:35 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 18:31 +0200
Re: Taming The Switch-Statement Bob Duff <invalid@invalid.com> - 2026-10-19 19:38 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 17:03 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:45 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 05:01 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 00:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:34 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:18 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-18 23:51 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:56 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 19:37 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 23:56 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:15 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:33 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-19 08:47 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 18:28 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 16:11 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:02 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:18 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 02:53 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 12:22 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 19:39 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 18:23 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:36 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 21:03 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 10:30 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-17 10:54 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-19 23:41 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:18 +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 David Brown <david.brown@hesbynett.no> - 2026-10-18 12:38 +0200
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-17 19:25 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 00:16 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement 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 gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 08:34 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 21:40 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:32 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 17:22 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 20:34 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 00:04 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 01:03 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 15:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:02 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 13:22 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 14:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 17:09 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:09 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 23:20 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:26 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 15:46 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 22:28 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 12:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 14:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 01:18 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 08:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 15:00 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-19 16:55 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:40 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:24 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:58 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:26 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 18:11 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 19:32 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:44 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-19 22:35 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:29 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 00:57 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:55 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:25 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 16:56 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:32 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:11 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 18:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement 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 8 of 22 — ← Prev page 1 … 6 7 [8] 9 10 … 22 Next page →
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-11 09:12 +0800 |
| Message-ID | <XnByS.11179$mPXe.6097@fx06.ams4> |
| In reply to | #402919 |
On 10/11/2026 6:32 AM, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-10-10 22:03, Michael S wrote:
>>> The cases where I want to break out of the loop from the switch in
>>> the
>>> body of the loop are very common.
>>
>> Ah, so you'd have needed something like Kornshell's 'break 2' to leave
>> more than one level. - I suppose, you needed to used a 'goto' instead
>> (and avoid the 'break' completely for those cases).
>
> Something like that, sure, but please not that.
>
> Specifying the *number* of levels to break or continue is IMHO
> horrible. "break N" makes me count things so the computer doesn't
> have to.
>
> There are proposals, and precedents in other languages, for *named*
> loops, and I'd like to see that in a future C.
>
What's wrong with labels? We already have that. You can name your
loops like this,
foo: while ( bar ) {
/* ... */
for ( int i = 0 ; i < 10 ; i++ ) {
/* ... */
goto foo ;
}
/* ... */
}
and do all kinds of control structures with just C89. So, why would you
personally need named loops? Can't you code C at all?
Best wishes, and happy named loops!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-11 04:07 +0200 |
| Message-ID | <11aer17$286ml$2@dont-email.me> |
| In reply to | #402919 |
On 2026-10-11 00:32, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-10-10 22:03, Michael S wrote: >>> The cases where I want to break out of the loop from the switch in >>> the >>> body of the loop are very common. >> >> Ah, so you'd have needed something like Kornshell's 'break 2' to leave >> more than one level. - I suppose, you needed to used a 'goto' instead >> (and avoid the 'break' completely for those cases). > > Something like that, sure, but please not that. > > Specifying the *number* of levels to break or continue is IMHO > horrible. "break N" makes me count things so the computer doesn't > have to. I agree; that's what I also dislike about it. The point is the question what choices you have. The 'goto' is IMO the worst; because of semantic interdependencies that will regularly lead to semantical restrictions about its applicability (or placement of labels); various languages have various restrictions, it's just a mess! The 'break' is a "cheap" solution, but also very restricted. There's yet other variants with their own drawbacks; I won't even start with it. > > There are proposals, and precedents in other languages, for *named* > loops, and I'd like to see that in a future C. One of the better possibilities, maybe; but still not satisfying for my (very subjective) taste. (Some language let you organize such things in completely other ways with no need for jumps of any sort.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 20:13 -0700 |
| Message-ID | <11aeusp$29hmu$2@kst.eternal-september.org> |
| In reply to | #402936 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-11 00:32, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 2026-10-10 22:03, Michael S wrote:
>>>> The cases where I want to break out of the loop from the switch in
>>>> the
>>>> body of the loop are very common.
>>>
>>> Ah, so you'd have needed something like Kornshell's 'break 2' to leave
>>> more than one level. - I suppose, you needed to used a 'goto' instead
>>> (and avoid the 'break' completely for those cases).
>> Something like that, sure, but please not that.
>> Specifying the *number* of levels to break or continue is IMHO
>> horrible. "break N" makes me count things so the computer doesn't
>> have to.
>
> I agree; that's what I also dislike about it.
>
> The point is the question what choices you have. The 'goto' is IMO
> the worst; because of semantic interdependencies that will regularly
> lead to semantical restrictions about its applicability (or placement
> of labels); various languages have various restrictions, it's just
> a mess! The 'break' is a "cheap" solution, but also very restricted.
> There's yet other variants with their own drawbacks; I won't even
> start with it.
>
>> There are proposals, and precedents in other languages, for *named*
>> loops, and I'd like to see that in a future C.
>
> One of the better possibilities, maybe; but still not satisfying for
> my (very subjective) taste.
>
> (Some language let you organize such things in completely other ways
> with no need for jumps of any sort.)
I find "break NAME;", where "NAME" is the name of an enclosing
construct, unambiguously better than "break N;", where N is the
number of levels to break out of.
The "break N" syntax is specified by POSIX. It's supported by ksh,
bash, dash, zsh, and probably other Bourne-based shells. (My guess
is that it originated in ksh.) My best guess is that because the
Bourne-like shells don't have gotos, they don't have labels, so
named loops would have required inventing those too. And admittedly
I suppose it's not too bad if it's no more than a couple of levels --
but it's still easy to, ahem, *break* if you reorganize the code.
There's a proposal for C2y to use goto labels as loop names, and a
competing one to define a new syntax like "for NAME (;;)" :
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-11 10:36 +0200 |
| Message-ID | <11afhr4$286ml$3@dont-email.me> |
| In reply to | #402938 |
On 2026-10-11 05:13, Keith Thompson wrote: > > I find "break NAME;", where "NAME" is the name of an enclosing > construct, unambiguously better than "break N;", where N is the > number of levels to break out of. Yes, sure. (Reminds me Pascal that supported for 'goto' just integer numbers [in the range 1..9999, IIRC] for jumps. - This is different from 'break N' but still also a bad design, IMO. - Not sure about later Pascal dialects, though. - Numbers for labels or levels, not nice.) > > The "break N" syntax is specified by POSIX. It's supported by ksh, > bash, dash, zsh, and probably other Bourne-based shells. (My guess > is that it originated in ksh.) My best guess is that because the > Bourne-like shells don't have gotos, they don't have labels, so > named loops would have required inventing those too. And admittedly > I suppose it's not too bad if it's no more than a couple of levels -- > but it's still easy to, ahem, *break* if you reorganize the code. Yes. - But while I don't find it (the N) elegant as concept it's in practice not that bad WRT "reorganization of code" since it's (as opposed to the 'goto' in other languages) a local construct. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-16 14:22 -0700 |
| Message-ID | <86mrsdpcgp.fsf@linuxsc.com> |
| In reply to | #402938 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> I find "break NAME;", where "NAME" is the name of an enclosing
> construct, unambiguously better than "break N;", where N is the
> number of levels to break out of. [...]
Definitely.
> There's a proposal for C2y to use goto labels as loop names, and a
> competing one to define a new syntax like "for NAME (;;)" :
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
I'm not particularly a fan of multi-level break/continue. But if
we're going to have one of these, the second ("for NAME (;;)") is
unquestionably better.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-16 15:00 -0700 |
| Message-ID | <11au6pr$3mdne$1@kst.eternal-september.org> |
| In reply to | #403221 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> I find "break NAME;", where "NAME" is the name of an enclosing
>> construct, unambiguously better than "break N;", where N is the
>> number of levels to break out of. [...]
>
> Definitely.
>
>> There's a proposal for C2y to use goto labels as loop names, and a
>> competing one to define a new syntax like "for NAME (;;)" :
>>
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
>
> I'm not particularly a fan of multi-level break/continue. But if
> we're going to have one of these, the second ("for NAME (;;)") is
> unquestionably better.
Unquestionably? Why?
I do like the fact that it doesn't conflate goto labels with loop
names, but I still prefer the "NAME: for (;;)" form, partly because
it's consistent with several other languages.
One minor drawback, IMHO, is that the name is easier to miss, because
it's not at the beginning of the line. This is based on zero experience
using it.
(The same problem exists with function names. Personally, I just
tolerate that rather than using the common convention of splitting the
return type and function name across two lines. I think I would have
preferred a syntax that puts the function name first, but I wouldn't
suggest changing it. I mildly dislike the convention of writing
int
func(void)
for reasons that are vague enough that I won't go into them.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-17 01:29 +0200 |
| Message-ID | <11auc0s$206gh$3@dont-email.me> |
| In reply to | #403224 |
On 2026-10-17 00:00, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>[...]
>>> There's a proposal for C2y to use goto labels as loop names, and a
>>> competing one to define a new syntax like "for NAME (;;)" :
>>> [...]
>>
>> I'm not particularly a fan of multi-level break/continue. But if
>> we're going to have one of these, the second ("for NAME (;;)") is
>> unquestionably better.
>
> Unquestionably? Why?
Why would one question an opinion? ;-)
>
> I do like the fact that it doesn't conflate goto labels with loop
> names, but I still prefer the "NAME: for (;;)" form, partly because
> it's consistent with several other languages.
I've no strong opinion on that, but I find the "for NAME (;;)" to
clearer express the _local scope_ of embedded breaks or continues.
(Just a matter of taste, and my appreciation for locality.)
>
> One minor drawback, IMHO, is that the name is easier to miss, because
> it's not at the beginning of the line. This is based on zero experience
> using it.
If that sort of jump would be _restricted_ to the respective loop
then I'd not see how I'd miss that since it's closely placed. (It
might also help if, as shown above, some all-caps convention would
be applied to labels.)
>
> (The same problem exists with function names. Personally, I just
> tolerate that rather than using the common convention of splitting the
> return type and function name across two lines. I think I would have
> preferred a syntax that puts the function name first, but I wouldn't
> suggest changing it. I mildly dislike the convention of writing
> int
> func(void)
> for reasons that are vague enough that I won't go into them.)
Well, there were both variants, the Algol 60 "integer procedure"
and the Algol 68 "(...) INT :" (or Pascal's syntax equivalent with
a 'function' keyword, similarly, but with another syntax, in Awk).
But there's more syntactic factors that influence where the name is
located, so many variants are existing. (But we're anyway talking
just about "C", so it's all void, whatever personal preferences.)
The point with the separation of two lines is a question distinct
from the choice, unless we'd choose a syntactic variant of the two
forms, specifically "fname (parms) res_t" (i.e. without keyword).
As far as I recall, in "C", the name of the function was often put
separately (first in the line) to have an easy method to find its
declaration by simple "grep ^fname". (With any sophisticated editor
this might be a weak argument, though.)
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 12:48 +0200 |
| Message-ID | <11b285v$121v2$2@dont-email.me> |
| In reply to | #403229 |
On 17/10/2026 01:29, Janis Papanagnou wrote:
> On 2026-10-17 00:00, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> [...]
>>>> There's a proposal for C2y to use goto labels as loop names, and a
>>>> competing one to define a new syntax like "for NAME (;;)" :
>>>> [...]
>>>
>>> I'm not particularly a fan of multi-level break/continue. But if
>>> we're going to have one of these, the second ("for NAME (;;)") is
>>> unquestionably better.
>>
>> Unquestionably? Why?
>
> Why would one question an opinion? ;-)
Time didn't word it as a personal opinion - he made it clear that he
doesn't think anyone else could have a different opinion.
The C standards committee collectively reached an agreement counter to
Tim's thoughts, so clearly his preferred variant is /not/ unquestionably
better.
>
>>
>> I do like the fact that it doesn't conflate goto labels with loop
>> names, but I still prefer the "NAME: for (;;)" form, partly because
>> it's consistent with several other languages.
>
> I've no strong opinion on that, but I find the "for NAME (;;)" to
> clearer express the _local scope_ of embedded breaks or continues.
> (Just a matter of taste, and my appreciation for locality.)
>
A main objection to "name: for ..." is that with function-scope labels,
you need a new name for every labelled loop or switch. That may be an
inconvenience, especially for macro with labelled loops, or for
copy-and-paste code. There is a proposal to deal with that which
basically says :
1. Any "break label;" or "continue label;" refers to the innermost
containing loop or switch with that label.
2. Any "label" used in "goto label;" must be unique in the function.
Those rules give a simple and intuitive fix without affecting existing code.
Beyond that, "name: for ..." or "for name ..." is, as you say, mostly a
matter of taste. (There are proposals for both versions, and you can
look them up to see the arguments.)
>
> As far as I recall, in "C", the name of the function was often put
> separately (first in the line) to have an easy method to find its
> declaration by simple "grep ^fname". (With any sophisticated editor
> this might be a weak argument, though.)
>
I think it was popularised with a shortcut in emacs.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 12:04 +0100 |
| Message-ID | <11b293j$12jfa$1@dont-email.me> |
| In reply to | #403254 |
On 18/10/2026 11:48, David Brown wrote:
> On 17/10/2026 01:29, Janis Papanagnou wrote:
>> I've no strong opinion on that, but I find the "for NAME (;;)" to
>> clearer express the _local scope_ of embedded breaks or continues.
>> (Just a matter of taste, and my appreciation for locality.)
>>
>
> A main objection to "name: for ..." is that with function-scope labels,
> you need a new name for every labelled loop or switch. That may be an
> inconvenience, especially for macro with labelled loops, or for copy-
> and-paste code. There is a proposal to deal with that which basically
> says :
>
> 1. Any "break label;" or "continue label;" refers to the innermost
> containing loop or switch with that label.
>
> 2. Any "label" used in "goto label;" must be unique in the function.
>
> Those rules give a simple and intuitive fix without affecting existing
> code.
There's something missing. Labels usually live in their own,
function-wide name space.
But if you have two loops like this:
L1: while () {} L2:
L1: while () {} L2:
Then even if no gotos exist to L1, is that rule somehow relaxed for
those L1s to allow them to co-exist? (While still applying to non-loop
labels L2, which would clash.)
Will the L1s still live within the regular name space? (Presumably each
will now be tagged with its associated loop.)
> Beyond that, "name: for ..." or "for name ..." is, as you say, mostly a
> matter of taste. (There are proposals for both versions, and you can
> look them up to see the arguments.)
The second form allows for those label names to be special, for example
by belonging in the same name space as regular identifiers and thus
subject to block scope rules. This is a tidier solution to the above.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 14:09 +0200 |
| Message-ID | <11b2cuh$141vj$1@dont-email.me> |
| In reply to | #403255 |
On 18/10/2026 13:04, bart wrote:
> On 18/10/2026 11:48, David Brown wrote:
>> On 17/10/2026 01:29, Janis Papanagnou wrote:
>
>>> I've no strong opinion on that, but I find the "for NAME (;;)" to
>>> clearer express the _local scope_ of embedded breaks or continues.
>>> (Just a matter of taste, and my appreciation for locality.)
>>>
>>
>> A main objection to "name: for ..." is that with function-scope
>> labels, you need a new name for every labelled loop or switch. That
>> may be an inconvenience, especially for macro with labelled loops, or
>> for copy- and-paste code. There is a proposal to deal with that which
>> basically says :
>>
>> 1. Any "break label;" or "continue label;" refers to the innermost
>> containing loop or switch with that label.
>>
>> 2. Any "label" used in "goto label;" must be unique in the function.
>>
>> Those rules give a simple and intuitive fix without affecting existing
>> code.
>
>
For reference:
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3658.htm>
> There's something missing. Labels usually live in their own, function-
> wide name space.
>
> But if you have two loops like this:
>
> L1: while () {} L2:
> L1: while () {} L2:
>
> Then even if no gotos exist to L1, is that rule somehow relaxed for
> those L1s to allow them to co-exist? (While still applying to non-loop
> labels L2, which would clash.)
Fair questions.
The rules (as given in proposal N3658) apply to all labels.
The point of the proposal is to look at how the labels are /used/, not
how they are defined, and make sure their /use/ is clear, intuitive,
intended, and unambiguous.
The two "L2:" labels above would not be a problem unless there is a
"goto L2" somewhere - then it is unclear which "L2" is being referenced,
and it is the use of "goto L2" that means the duplication is flagged as
an error.
The two "L1:" labels above would also constitute an error if you have
"goto L1" in the function.
But if you have "break L1" or "continue L1" within the body of one of
the loops, it is entirely clear which L1 is being referred to - and thus
there is no error.
>
> Will the L1s still live within the regular name space? (Presumably each
> will now be tagged with its associated loop.)
No - with this change, labels do not have "scope" in the same way as
before, but context-dependent lookup.
Note that if you have "L1: while () {}", and no other label "L1", then
you can happily use "goto L1" from anywhere in the function (assuming
you don't fall foul of other rules) - the label "L1" is /not/ in a local
scope within the loop.
>
>> Beyond that, "name: for ..." or "for name ..." is, as you say, mostly
>> a matter of taste. (There are proposals for both versions, and you
>> can look them up to see the arguments.)
>
> The second form allows for those label names to be special, for example
> by belonging in the same name space as regular identifiers and thus
> subject to block scope rules. This is a tidier solution to the above.
>
Yes, the "for name ..." form makes label names special. No, it is not a
"tidier solution" - though of course you are welcome to a personal
opinion that you think one syntax variant is nicer than the other.
There are pros and cons of each syntax - that's why its important that
there is a committee (two committees, actually, since both C and C++ are
working on this) rather than having one person declare "this is clearly
the best". (Just so you know I am not picking on you - in another post
I also said Tim was wrong to say "for name ..." was "unquestionably
better". And I am /not/ suggesting that "label: for ..." is
unquestionably better either.)
See :
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3568r0.html#opposition-to-n3377>
(That is a C++ proposal, but discussions have gone back and forth
between both C and C++ standards groups because the changes can apply to
both languages - and no one wants different syntaxes for identical
features.)
A key point is that labels of the form "L1: ..." are already familiar in
C and many other programming languages, and a large number of other
languages support something akin to "L1: while (..) { ... break L1; }".
Additionally, "L1 : do { ... break L1; } while (...)" puts the name at
the top of the loop, rather than at the end (if it is attached to the
"while"). (I don't know why N3377 proposed "do { } while NAME ( )"
rather than "do NAME { } while ( )". )
And for those that like to use macros for their loops, the prefix label
is neater:
#define FOR_LOOP(_i, _n) for (int _i; i = 0; i < _n)
outer : FOR_LOOP(i, 100) {
inner : FOR_LOOP(j, 100) {
if (i * j == 45) break outer;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 14:34 +0200 |
| Message-ID | <11b2eck$3pvd9$1@dont-email.me> |
| In reply to | #403263 |
On 2026-10-18 14:09, David Brown wrote:
>
> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
> rather than "do NAME { } while ( )". )
Oh! - I can only think that it would then be (sort of) "consistent"
with the place of the label attacked in a 'while' loop; i.e. behind
the 'while' keyword. - It's inconsistent in another interpretation,
though; and I'd certainly have favored the latter form, to have the
label consistently attached at the loop-entry keyword.
We'll see what they finally decide (unless it's already clear; I'm
not sure about the factual weight of the "proposal")...
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 17:13 +0300 |
| Message-ID | <20261018171339.00005308@yahoo.com> |
| In reply to | #403267 |
On Sun, 18 Oct 2026 14:34:28 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2026-10-18 14:09, David Brown wrote:
> >
> > [...] (I don't know why N3377 proposed "do { } while NAME ( )"
> > rather than "do NAME { } while ( )". )
>
> Oh! - I can only think that it would then be (sort of) "consistent"
> with the place of the label attacked in a 'while' loop; i.e. behind
> the 'while' keyword. - It's inconsistent in another interpretation,
> though; and I'd certainly have favored the latter form, to have the
> label consistently attached at the loop-entry keyword.
I'd prefer label consistently attached to the loop-exit keyword.
Unfortunately, for() and while() loops have no such keyword.
> We'll see what they finally decide (unless it's already clear; I'm
> not sure about the factual weight of the "proposal")...
>
I tend to agree with Tim (if I correctly understood him): a.t.m. the
best outcome would be proposal scrapped completely.
> Janis
>
> > [...]
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:52 +0200 |
| Message-ID | <11b2mf1$16mof$2@dont-email.me> |
| In reply to | #403270 |
On 18/10/2026 16:13, Michael S wrote:
> On Sun, 18 Oct 2026 14:34:28 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
>> On 2026-10-18 14:09, David Brown wrote:
>>>
>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>>> rather than "do NAME { } while ( )". )
>>
>> Oh! - I can only think that it would then be (sort of) "consistent"
>> with the place of the label attacked in a 'while' loop; i.e. behind
>> the 'while' keyword. - It's inconsistent in another interpretation,
>> though; and I'd certainly have favored the latter form, to have the
>> label consistently attached at the loop-entry keyword.
>
> I'd prefer label consistently attached to the loop-exit keyword.
> Unfortunately, for() and while() loops have no such keyword.
>
That would help for switch inside a loop, or loop inside a switch, but
do nothing for loop inside a loop or switch inside a switch. I don't
think anyone involved in the development of the language has seriously
considered making a solution that only handles the first two cases, and
not the second two (to say nothing of three or more nesting layers).
"break_switch" and "break_loop" style solutions have been mentioned and
quickly dismissed, along with the "break <depth>" options.
>> We'll see what they finally decide (unless it's already clear; I'm
>> not sure about the factual weight of the "proposal")...
>>
>
> I tend to agree with Tim (if I correctly understood him): a.t.m. the
> best outcome would be proposal scrapped completely.
>
The proposal has been accepted - it is coming to C and C++, whatever you
or Tim may think. But of course there is no requirement to /use/ the
new feature if you don't like it. (I don't expect to use it
significantly myself - I just don't seem to write code in a way that
could take advantage of it.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 18:16 +0300 |
| Message-ID | <20261018181623.00007978@yahoo.com> |
| In reply to | #403276 |
On Sun, 18 Oct 2026 16:52:17 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 18/10/2026 16:13, Michael S wrote:
> > On Sun, 18 Oct 2026 14:34:28 +0200
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> >
> >> On 2026-10-18 14:09, David Brown wrote:
> >>>
> >>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
> >>> rather than "do NAME { } while ( )". )
> >>
> >> Oh! - I can only think that it would then be (sort of) "consistent"
> >> with the place of the label attacked in a 'while' loop; i.e. behind
> >> the 'while' keyword. - It's inconsistent in another interpretation,
> >> though; and I'd certainly have favored the latter form, to have the
> >> label consistently attached at the loop-entry keyword.
> >
> > I'd prefer label consistently attached to the loop-exit keyword.
> > Unfortunately, for() and while() loops have no such keyword.
> >
>
> That would help for switch inside a loop, or loop inside a switch,
> but do nothing for loop inside a loop or switch inside a switch. I
> don't think anyone involved in the development of the language has
> seriously considered making a solution that only handles the first
> two cases, and not the second two
Pay attention that 4 patterns are not equal. The second case
(breaking from loop to outside of containing switch) hardly happens.
> (to say nothing of three or more
> nesting layers). "break_switch" and "break_loop" style solutions have
> been mentioned and quickly dismissed, along with the "break <depth>"
> options.
>
It does not look like you understood what I wrote.
All I wanted to say is that I prefer label to be located at where the
break goes. Or near this point. Within frame of current C syntax, I
don't see how to achieve it, except for do-while. But it does not
change the fact that I find it desirable.
> >> We'll see what they finally decide (unless it's already clear; I'm
> >> not sure about the factual weight of the "proposal")...
> >>
> >
> > I tend to agree with Tim (if I correctly understood him): a.t.m. the
> > best outcome would be proposal scrapped completely.
> >
>
> The proposal has been accepted - it is coming to C and C++, whatever
> you or Tim may think.
Nothing is set in stone until the standard released. But you are very
likely right. Which does not make me happier.
> But of course there is no requirement to /use/
> the new feature if you don't like it.
But others will use it and I'd have to read and understand their code.
> (I don't expect to use it
> significantly myself - I just don't seem to write code in a way that
> could take advantage of it.)
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 20:47 +0200 |
| Message-ID | <11b347h$1cn63$1@dont-email.me> |
| In reply to | #403279 |
On 18/10/2026 17:16, Michael S wrote:
> On Sun, 18 Oct 2026 16:52:17 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 18/10/2026 16:13, Michael S wrote:
>>> On Sun, 18 Oct 2026 14:34:28 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>
>>>> On 2026-10-18 14:09, David Brown wrote:
>>>>>
>>>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>>>>> rather than "do NAME { } while ( )". )
>>>>
>>>> Oh! - I can only think that it would then be (sort of) "consistent"
>>>> with the place of the label attacked in a 'while' loop; i.e. behind
>>>> the 'while' keyword. - It's inconsistent in another interpretation,
>>>> though; and I'd certainly have favored the latter form, to have the
>>>> label consistently attached at the loop-entry keyword.
>>>
>>> I'd prefer label consistently attached to the loop-exit keyword.
>>> Unfortunately, for() and while() loops have no such keyword.
>>>
>>
>> That would help for switch inside a loop, or loop inside a switch,
>> but do nothing for loop inside a loop or switch inside a switch. I
>> don't think anyone involved in the development of the language has
>> seriously considered making a solution that only handles the first
>> two cases, and not the second two
>
> Pay attention that 4 patterns are not equal. The second case
> (breaking from loop to outside of containing switch) hardly happens.
>
I know they are not equal - that's why I wrote all four combinations.
But I have no good statistics to determine which combinations might be
more common than others for wanting to break out of the outer structure.
I know /you/ said that /you/ regularly want to break out of a switch
that is inside a loop - fair enough. It is not something that I have
needed to do, or at least not often enough to bother about it. Indeed,
none of the cases are particularly common in my code. I've no doubt
come across some of them at times, and dealt with them using extra bools
or splitting up big functions into smaller ones where "return" could do
the job. Certainly I do not ever remember wishing I had a "break_loop"
statement, or a labelled break.
But the C standards committee don't care about my code. They don't care
about your code either. They care about what they think makes a
difference to large numbers of C programmers. I can't tell you if they
have access to good statistics, or are using the combined gut feelings
of the committee members. However, it would strike me as a serious
wasted opportunity if they made an addition to the language that only
handled the one pattern that you find most common in your code, rather
than also making it work for the other patterns.
>> (to say nothing of three or more
>> nesting layers). "break_switch" and "break_loop" style solutions have
>> been mentioned and quickly dismissed, along with the "break <depth>"
>> options.
>>
>
> It does not look like you understood what I wrote.
> All I wanted to say is that I prefer label to be located at where the
> break goes.
In C2y, you /do/ put the label along with the break - you write "break
outer;". But you also have to put the label "outer : " at the start of
the control structure.
If you want to have some kind of "break to outer structure" /without/
having a name or label on the structure, then you need some other way to
refer to it. I thought you had said before your preference was for
something like "break_switch" (ignoring any bike-shedding on the
syntax), which would work in the particular case of a switch with nested
loop(s). And as I wrote, this was considered and dismissed. (Equally,
the other plausible syntax that does not require an explicit label -
"break <depth>", was considered and dismissed.)
> Or near this point. Within frame of current C syntax, I
> don't see how to achieve it, except for do-while. But it does not
> change the fact that I find it desirable.
>
Am I right in thinking you would then have :
do {
switch (...) {
break outer;
while outer (...);
You are happy with labelling the loop or switch, but want the label at
the end, not the start?
Why not then just use "goto" and put a label at the end of the loop or
switch? (This is allowed in C23.)
>>>> We'll see what they finally decide (unless it's already clear; I'm
>>>> not sure about the factual weight of the "proposal")...
>>>>
>>>
>>> I tend to agree with Tim (if I correctly understood him): a.t.m. the
>>> best outcome would be proposal scrapped completely.
>>>
>>
>> The proposal has been accepted - it is coming to C and C++, whatever
>> you or Tim may think.
>
> Nothing is set in stone until the standard released. But you are very
> likely right. Which does not make me happier.
>
Okay. There are always changes that we like, changes we dislike, and
(often the majority) changes to which we are indifferent.
>> But of course there is no requirement to /use/
>> the new feature if you don't like it.
>
> But others will use it and I'd have to read and understand their code.
>
True - but do you /really/ think that is going to be a problem?
>> (I don't expect to use it
>> significantly myself - I just don't seem to write code in a way that
>> could take advantage of it.)
>>
>
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 22:38 +0300 |
| Message-ID | <20261018223859.000031d3@yahoo.com> |
| In reply to | #403286 |
On Sun, 18 Oct 2026 20:47:13 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 18/10/2026 17:16, Michael S wrote:
> > On Sun, 18 Oct 2026 16:52:17 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 18/10/2026 16:13, Michael S wrote:
> >>> On Sun, 18 Oct 2026 14:34:28 +0200
> >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> >>>
> >>>> On 2026-10-18 14:09, David Brown wrote:
> >>>>>
> >>>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
> >>>>> rather than "do NAME { } while ( )". )
> >>>>
> >>>> Oh! - I can only think that it would then be (sort of)
> >>>> "consistent" with the place of the label attacked in a 'while'
> >>>> loop; i.e. behind the 'while' keyword. - It's inconsistent in
> >>>> another interpretation, though; and I'd certainly have favored
> >>>> the latter form, to have the label consistently attached at the
> >>>> loop-entry keyword.
> >>>
> >>> I'd prefer label consistently attached to the loop-exit keyword.
> >>> Unfortunately, for() and while() loops have no such keyword.
> >>>
> >>
> >> That would help for switch inside a loop, or loop inside a switch,
> >> but do nothing for loop inside a loop or switch inside a switch. I
> >> don't think anyone involved in the development of the language has
> >> seriously considered making a solution that only handles the first
> >> two cases, and not the second two
> >
> > Pay attention that 4 patterns are not equal. The second case
> > (breaking from loop to outside of containing switch) hardly happens.
> >
>
> I know they are not equal - that's why I wrote all four combinations.
> But I have no good statistics to determine which combinations might
> be more common than others for wanting to break out of the outer
> structure. I know /you/ said that /you/ regularly want to break out
> of a switch that is inside a loop - fair enough. It is not something
> that I have needed to do, or at least not often enough to bother
> about it. Indeed, none of the cases are particularly common in my
> code. I've no doubt come across some of them at times, and dealt
> with them using extra bools or splitting up big functions into
> smaller ones where "return" could do the job. Certainly I do not
> ever remember wishing I had a "break_loop" statement, or a labelled
> break.
>
> But the C standards committee don't care about my code. They don't
> care about your code either. They care about what they think makes a
> difference to large numbers of C programmers. I can't tell you if
> they have access to good statistics, or are using the combined gut
> feelings of the committee members. However, it would strike me as a
> serious wasted opportunity if they made an addition to the language
> that only handled the one pattern that you find most common in your
> code, rather than also making it work for the other patterns.
>
> >> (to say nothing of three or more
> >> nesting layers). "break_switch" and "break_loop" style solutions
> >> have been mentioned and quickly dismissed, along with the "break
> >> <depth>" options.
> >>
> >
> > It does not look like you understood what I wrote.
> > All I wanted to say is that I prefer label to be located at where
> > the break goes.
>
> In C2y, you /do/ put the label along with the break - you write
> "break outer;". But you also have to put the label "outer : " at the
> start of the control structure.
>
> If you want to have some kind of "break to outer structure" /without/
> having a name or label on the structure, then you need some other way
> to refer to it. I thought you had said before your preference was
> for something like "break_switch" (ignoring any bike-shedding on the
> syntax), which would work in the particular case of a switch with
> nested loop(s). And as I wrote, this was considered and dismissed.
> (Equally, the other plausible syntax that does not require an
> explicit label - "break <depth>", was considered and dismissed.)
>
> > Or near this point. Within frame of current C syntax, I
> > don't see how to achieve it, except for do-while. But it does not
> > change the fact that I find it desirable.
> >
>
> Am I right in thinking you would then have :
>
> do {
> switch (...) {
> break outer;
> while outer (...);
>
> You are happy with labelling the loop or switch, but want the label
> at the end, not the start?
>
Almost. I want it at the end and I want it with syntax that can't be
confused with regular goto targets.
> Why not then just use "goto" and put a label at the end of the loop
> or switch? (This is allowed in C23.)
>
Like just about everybody else, I prefer weaker control transfers. They
are not easier to write, but easier to follow by reader.
goto is too powerful - can go everywhere within function. That part is
improved by C2y proposal.
But the labels that goto targets are also too powerful - they can be
reached from everywhere in the function. That part is not just not
improved by proposal, but made worse, because now we not just have a
too powerful label (that we have to name, which is problem by itself,
but lesser evil than break N alternative), but this label creates
another, completely unnecessary, target for goto, that the reader of
code should have in mind.
> >>>> We'll see what they finally decide (unless it's already clear;
> >>>> I'm not sure about the factual weight of the "proposal")...
> >>>>
> >>>
> >>> I tend to agree with Tim (if I correctly understood him): a.t.m.
> >>> the best outcome would be proposal scrapped completely.
> >>>
> >>
> >> The proposal has been accepted - it is coming to C and C++,
> >> whatever you or Tim may think.
> >
> > Nothing is set in stone until the standard released. But you are
> > very likely right. Which does not make me happier.
> >
>
> Okay. There are always changes that we like, changes we dislike, and
> (often the majority) changes to which we are indifferent.
>
> >> But of course there is no requirement to /use/
> >> the new feature if you don't like it.
> >
> > But others will use it and I'd have to read and understand their
> > code.
>
> True - but do you /really/ think that is going to be a problem?
>
For me, personally? May be not. Due to (or because of) my age, with
retirement not too distant.
> >> (I don't expect to use it
> >> significantly myself - I just don't seem to write code in a way
> >> that could take advantage of it.)
> >>
> >
> >
> >
> >
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-19 11:16 +0200 |
| Message-ID | <11b4n4s$1q18k$1@dont-email.me> |
| In reply to | #403289 |
On 18/10/2026 21:38, Michael S wrote:
> On Sun, 18 Oct 2026 20:47:13 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 18/10/2026 17:16, Michael S wrote:
>>> All I wanted to say is that I prefer label to be located at where
>>> the break goes.
>>
>> In C2y, you /do/ put the label along with the break - you write
>> "break outer;". But you also have to put the label "outer : " at the
>> start of the control structure.
>>
>> If you want to have some kind of "break to outer structure" /without/
>> having a name or label on the structure, then you need some other way
>> to refer to it. I thought you had said before your preference was
>> for something like "break_switch" (ignoring any bike-shedding on the
>> syntax), which would work in the particular case of a switch with
>> nested loop(s). And as I wrote, this was considered and dismissed.
>> (Equally, the other plausible syntax that does not require an
>> explicit label - "break <depth>", was considered and dismissed.)
>>
>>> Or near this point. Within frame of current C syntax, I
>>> don't see how to achieve it, except for do-while. But it does not
>>> change the fact that I find it desirable.
>>>
>>
>> Am I right in thinking you would then have :
>>
>> do {
>> switch (...) {
>> break outer;
>> while outer (...);
>>
>> You are happy with labelling the loop or switch, but want the label
>> at the end, not the start?
>>
>
> Almost. I want it at the end and I want it with syntax that can't be
> confused with regular goto targets.
>
I can appreciate wanting a syntax that is distinct from regular labels
for "goto".
(I can also appreciate that others prefer a similarity - they want to be
able to use the same label for "goto", it means less new learning, and
fewer conflicts with things like syntax highlighters. Since I
personally don't expect to use the feature much, and have almost no use
for "goto" or labels today, I am ambivalent here, and prefer to leave
the decision to those with more direct experience. There has been
plenty of discussion on the pros and cons here.)
However, I am curious as to why you see putting the name or label at the
end of the loop or switch as important. A "break <name>" will go to the
end, but a "continue <name>" will go back to the start. Do you see
"break" as more common or more important than "continue" ? Goto labels
are an exception, but the normal rule in C is that names are introduced
before their use.
>> Why not then just use "goto" and put a label at the end of the loop
>> or switch? (This is allowed in C23.)
>>
>
> Like just about everybody else, I prefer weaker control transfers. They
> are not easier to write, but easier to follow by reader.
> goto is too powerful - can go everywhere within function. That part is
> improved by C2y proposal.
(I am not sure that "weak" or "strong" is the right adjective here - I
see "for" and "while" as /stronger/ than "goto" because they provide
more structure and guarantees about the control flow. But I know what
you mean, and agree with you.)
> But the labels that goto targets are also too powerful - they can be
> reached from everywhere in the function. That part is not just not
> improved by proposal, but made worse, because now we not just have a
> too powerful label (that we have to name, which is problem by itself,
> but lesser evil than break N alternative), but this label creates
> another, completely unnecessary, target for goto, that the reader of
> code should have in mind.
Labelled breaks can eliminate a significant use of "goto". (And if
"defer" makes it into C2y and gains popularity - admittedly a big "if" -
that could eliminate the other major use of "goto".) If there is no
"goto" in the function, there is no concern about where it might go.
There is always going to be scope for misunderstanding, no matter what
syntax is used. It is good to pick a syntax that reduces the risk, but
it cannot be eliminated - ultimately, individual programmers are
responsible for writing clear code.
I think your concerns are valid, but I think (or hope) that they are
more pessimistic than realistic.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-19 03:50 -0700 |
| Message-ID | <11b4smj$1vt4q$1@kst.eternal-september.org> |
| In reply to | #403309 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I can appreciate wanting a syntax that is distinct from regular labels
> for "goto".
So can I. The first language I used that had this kind of thing
was Ada. In the language's initial design, it was decided that
though goto statements were needed, the labels should stand out:
<<LABEL>>
-- ...
goto LABEL;
Names used for loops have a lighter-weight syntax:
LOOP_NAME:
while condition loop
-- ...
end loop;
I can't think of a better syntax for loop names than "NAME:" (used
by several other languages), but in C that syntax is already
taken for goto labels. The possibility of any ambiguity between
"goto NAME;" and "break NAME;" doesn't bother me enough to want
to invent something new. And I consider the fact that other
languages use the "NAME:" syntax for loop names to be another
point in its favor.
The odd scoping rules for labels don't bother me either. They mean
you can't have two loops or switch statements with the same name in
the same function. I can barely imagine that being inconvenient.
And it's already specified in the latest C2y draft, and implemented in
gcc and clang, which means there's already some inertia against any
major changes. Anything could happen between now and the publication
of the next C standard, but I don't see any need to make significant
changes in this area.
I use Perl's equivalent of named break quite a lot. I found
31 occurrences of "exit NAME" in a collection of Perl scripts
I've written. I'm a little surprised to find that none of these
break out of nested loops; I just like to name loops for clarity.
I even find that having to choose a name for something forces
me to think more clearly about it.
The C2y proposed syntax and semantics for named loops and switch
statements is of course imperfect, but it's reasonably clean
and useful. I see no need to make any significant changes in
this area.
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-19 12:59 +0200 |
| Message-ID | <11b4t5k$1q18k$3@dont-email.me> |
| In reply to | #403312 |
On 19/10/2026 12:50, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> I can appreciate wanting a syntax that is distinct from regular labels >> for "goto". > > So can I. The first language I used that had this kind of thing > was Ada. In the language's initial design, it was decided that > though goto statements were needed, the labels should stand out: > > <<LABEL>> > -- ... > goto LABEL; > > Names used for loops have a lighter-weight syntax: > > LOOP_NAME: > while condition loop > -- ... > end loop; > > I can't think of a better syntax for loop names than "NAME:" (used > by several other languages), but in C that syntax is already > taken for goto labels. The possibility of any ambiguity between > "goto NAME;" and "break NAME;" doesn't bother me enough to want > to invent something new. And I consider the fact that other > languages use the "NAME:" syntax for loop names to be another > point in its favor. > > The odd scoping rules for labels don't bother me either. They mean > you can't have two loops or switch statements with the same name in > the same function. I can barely imagine that being inconvenient. I can imagine that being a bit inconvenient in some cases, but I think the proposal in N3658 would simply and cleanly fix that. > > And it's already specified in the latest C2y draft, and implemented in > gcc and clang, which means there's already some inertia against any > major changes. Anything could happen between now and the publication > of the next C standard, but I don't see any need to make significant > changes in this area. > > I use Perl's equivalent of named break quite a lot. I found > 31 occurrences of "exit NAME" in a collection of Perl scripts > I've written. I'm a little surprised to find that none of these > break out of nested loops; I just like to name loops for clarity. > I even find that having to choose a name for something forces > me to think more clearly about it. > > The C2y proposed syntax and semantics for named loops and switch > statements is of course imperfect, but it's reasonably clean > and useful. I see no need to make any significant changes in > this area. > There are always going to be disagreements about language features and syntax - even more so when they are added late to a language, rather than part of the initial design. (Maybe if named loops and "defer" were part of the original C, it would never have needed "goto" and labels.) Changes and additions have to be of enough potential benefit, and low enough cost or potential confusion - they don't have to be "perfect" or suit the needs and preferences of everyone.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-19 15:28 -0700 |
| Message-ID | <11b65hn$2fcat$1@kst.eternal-september.org> |
| In reply to | #403313 |
David Brown <david.brown@hesbynett.no> writes:
> On 19/10/2026 12:50, Keith Thompson wrote:
[...]
>> The odd scoping rules for labels don't bother me either. They mean
>> you can't have two loops or switch statements with the same name in
>> the same function. I can barely imagine that being inconvenient.
>
> I can imagine that being a bit inconvenient in some cases, but I think
> the proposal in N3658 would simply and cleanly fix that.
[...]
*If* the fact that labels (which are now also loop/switch names)
follow strange scope rules is a real problem, N3658 is probably
the best practical solution. I'm slightly uncomfortable with the
idea of an entity's scope depending on how it's used, not just how
it's defined. I think it introduces a complication to the language
without much real benefit.
But cleaner solutions are impractical.
IMHO the only really clean solution would be to make labels and
loop/switch names distinct, keep the existing scoping rules for
labels, and use more normal scoping rules for loop/switch names.
And if the "while NAME (...)" proposal were accepted, that's probably
how it should work. (But I prefer having the name as a prefix of the
loop or switch statement.)
If N3658 were adopted, it wouldn't bother me much. I just don't
think it's necessary.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 8 of 22 — ← Prev page 1 … 6 7 [8] 9 10 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web