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 328 — 21 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +0200
Re: Taming The Switch-Statement 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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement 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 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 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 18:57 +0100 |
| Message-ID | <11agils$2s3tg$1@dont-email.me> |
| In reply to | #402990 |
On 11/10/2026 18:17, David Brown wrote:
> On 11/10/2026 18:01, Andrey Tarasevich wrote:
>> On Sun 10/11/2026 6:33 AM, David Brown wrote:
>>>
>>> It is quite obvious that it is easy to write code with loops + break
>>> within a switch. It is equally obvious that it is easy to avoid such
>>> constructs - there are always ways to avoid a "break" in a loop, and
>>> if the code run within a switch case is complex, it is often
>>> practical to refactor it into a separate function. But presumably
>>> Michael has reasons not do do that.
>>
>> Um... The common pattern for a "search"-style loop looks as follows
>>
>> for (/* domain condition */)
>> {
>> ...
>> if (/* search condition */)
>> break;
>> ...
>> }
>>
>> So, loops that terminate with `break` are the mainstay of every
>> competently written code. Moving the "early termination" condition
>> into the loop header (i.e. lumping the search condition with the
>> domain condition) is a very ugly anti-pattern in most cases. Moreover,
>> majority of the loops in an average C program are such "search"-style
>> loops, meaning that they do have an "early termination" condition.
>>
>> Now, while overwhelming majority of my loops would use `if` to check
>> the "early termination", I can imagine that there sill be cases where
>> `switch` is applicable and more appropriate than an `if`. Yes, a
>> `switch` can always be replaced with an `if` ladder, but being
>> _forced_ to do so by a language limitation doesn't look right.
>>
>> And writing a separate function just to work around a weird language
>> limitation... that doesn't look right either.
>>
>
> Certainly plenty of loops have "break" statements, especially as an
> early exit.
>
> Sometimes code is written with big switches in a function, and the cases
> might include loops, and those loops might have break statements. The
> question is why someone might consider this a very common situation, and
> why they might consider it a failing that the same keyword is used for a
> switch "break" and for a loop "break". There are two possibilities I
> can imagine, but Michael may have other things in mind. One is that the
> code is less clear than it might otherwise have been - if that is the
> case, then I think the code should be considered for re-factoring into
> separate functions if the inner loops are too complex. The other
> possibility is that the programmer wanted to break out of the switch
> from within the middle of the inner loop. I can imagine that happening,
> and it would currently need either a bit of extra code to do the
> "breaking" in two steps, a "goto", or refactoring into a separate
> function. But it seems strange to me that someone would feel that was a
> common enough problem to want to have "switch break" and "loop break" be
> separate keywords, rather than go straight to a "break <label>" solution
> that would be more general.
>
> Only Michael can, if he wants, explain what he was thinking.
It sounds like he's pressurised into doing so. Maybe so that he can be
lectured on how to it 'properly'.
'break' to quit a loop early is part of the language, so why shouldn't
someone make use it?
It just its use can be interfered with when 'switch' is involved.
That that happens and needs a workaround, is not satisfactory. The issue
exists 100% because of sharing the 'break' keyword for two different
purposes.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-11 14:28 -0700 |
| Message-ID | <11agv1t$30q22$2@kst.eternal-september.org> |
| In reply to | #402992 |
bart <bc@freeuk.com> writes:
[...]
> 'break' to quit a loop early is part of the language, so why shouldn't
> someone make use it?
Agreed. (There are coding styles that require loops to exit only at the
bottom, but that's not what we're talking about.)
> It just its use can be interfered with when 'switch' is involved.
Yes. Everyone here knows that, and knew it before you started talking
about it.
Michael S wrote above that "The cases where I want to break out of
the loop from the switch in the body of the loop are very common."
Tim Rentsch questioned the "very common" part of that, and asked
for an example. You jumped in and asserted that an example isn't
necessary, because you misunderstood what was being said. *Of
course* there are cases where someone might want to break out of
a loop from a nested switch.
> That that happens and needs a workaround, is not satisfactory. The
> issue exists 100% because of sharing the 'break' keyword for two
> different purposes.
Yes, the overloading of the "break" keyword can be inconvenient.
It makes it difficult to break out of a loop from within a switch
statement. Again, everyone here knows that.
Breaking out of an outer loop from within an inner loop is just
as much of a problem. "break NAME;" proposed for C2y, would solve
both problems. (I just found out that recent versions of gcc and
clang support this as an extension or with "-std=c2y".)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-11 23:02 +0100 |
| Message-ID | <11ah12b$320sj$1@dont-email.me> |
| In reply to | #403007 |
On 11/10/2026 22:28, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> 'break' to quit a loop early is part of the language, so why shouldn't >> someone make use it? > > Agreed. (There are coding styles that require loops to exit only at the > bottom, but that's not what we're talking about.) > >> It just its use can be interfered with when 'switch' is involved. > > Yes. Everyone here knows that, and knew it before you started talking > about it. > > Michael S wrote above that "The cases where I want to break out of > the loop from the switch in the body of the loop are very common." > Tim Rentsch questioned the "very common" part of that, and asked > for an example. You jumped in and asserted that an example isn't > necessary, because you misunderstood what was being said. *Of > course* there are cases where someone might want to break out of > a loop from a nested switch. You're missing the undercurrent, which is a tone of disapproval and disbelief. But we'll find out if and when examples are ever posted. However you may want to consider that examples are rare, or even non-existent, /because/ it's not possible to do! So using 'switch' is avoided or some other workaround is found. Michael S actually said this: "The cases where I want to break out of the loop from the switch in the body of the loop are very common." This expresses a desire to do so. > Breaking out of an outer loop from within an inner loop is just > as much of a problem. A less common one but when it happens it will be an actual problem and not an artificial one. > "break NAME;" proposed for C2y, would solve > both problems. (I just found out that recent versions of gcc and > clang support this as an extension or with "-std=c2y".) OK. I'd rather have a solution that doesn't involve inventing names. Does this also fix the break-out-of-a-loop-from-inside-switch issue? In that case just 'break for/while' might do! You know, a little bit like using a different keyword for loops/non-loops.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-11 16:29 -0700 |
| Message-ID | <11ah640$329bt$5@kst.eternal-september.org> |
| In reply to | #403009 |
bart <bc@freeuk.com> writes:
> On 11/10/2026 22:28, Keith Thompson wrote:
[...]
> You're missing the undercurrent, which is a tone of disapproval and
> disbelief.
I was responding to what you wrote, not to some "undercurrent".
Missing it? I'm practically drowning in it.
You're missing the fact that the problems you keep complaining
about are things that (essentially) everyone was already aware of.
You seem unable to understand that the rest of aren't as angry about
fallthrough as you are, and that we might have valid reasons for
not being angry about it. You seem to think that anyone who is not
outraged that C hasn't added a version of switch that doesn't have
fallthrough simply doesn't understand what you're saying.
[...]
>> Breaking out of an outer loop from within an inner loop is just
>> as much of a problem.
>
> A less common one but when it happens it will be an actual problem and
> not an artificial one.
>
>> "break NAME;" proposed for C2y, would solve
>> both problems. (I just found out that recent versions of gcc and
>> clang support this as an extension or with "-std=c2y".)
[...]
> Does this also fix the break-out-of-a-loop-from-inside-switch issue?
It fixes it in the sense that both loops and switch statements can be
named, and a break or continue can optionally refer to the name of the
targeted loop or switch statement. Of course it doesn't automatically
fix existing code.
> In that case just 'break for/while' might do!
That would work for a "for" within a "while", or a "while" within
a "for", but not for a "while" within a "while" or a "for" within
a "for".
There is ample precedent for named loops in other languages.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-12 04:03 -0700 |
| Message-ID | <86ik37i3kl.fsf@linuxsc.com> |
| In reply to | #403007 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > bart <bc@freeuk.com> writes: > [...] > >> 'break' to quit a loop early is part of the language, so why shouldn't >> someone make use it? > > Agreed. (There are coding styles that require loops to exit only at the > bottom, but that's not what we're talking about.) > >> It just its use can be interfered with when 'switch' is involved. > > Yes. Everyone here knows that, and knew it before you started talking > about it. > > Michael S wrote above that "The cases where I want to break out of > the loop from the switch in the body of the loop are very common." > Tim Rentsch questioned the "very common" part of that, and asked > for an example. [...] I didn't question it. I just said it surprised me.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-12 22:02 +0300 |
| Message-ID | <20261012220256.00003d07@yahoo.com> |
| In reply to | #403007 |
On Sun, 11 Oct 2026 14:28:29 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > bart <bc@freeuk.com> writes: > [...] > > 'break' to quit a loop early is part of the language, so why > > shouldn't someone make use it? > > Agreed. (There are coding styles that require loops to exit only at > the bottom, but that's not what we're talking about.) > > > It just its use can be interfered with when 'switch' is involved. > > Yes. Everyone here knows that, and knew it before you started talking > about it. > > Michael S wrote above that "The cases where I want to break out of > the loop from the switch in the body of the loop are very common." > Tim Rentsch questioned the "very common" part of that, and asked > for an example. You jumped in and asserted that an example isn't > necessary, because you misunderstood what was being said. > I didn't read the whole subthread, but from what I read it seems that the only reader that misunderstood my statement was David Brown. The rest, including bart, understood just fine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 21:09 +0200 |
| Message-ID | <11ajb95$3t8jj$1@dont-email.me> |
| In reply to | #403050 |
On 12/10/2026 21:02, Michael S wrote: > On Sun, 11 Oct 2026 14:28:29 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> bart <bc@freeuk.com> writes: >> [...] >>> 'break' to quit a loop early is part of the language, so why >>> shouldn't someone make use it? >> >> Agreed. (There are coding styles that require loops to exit only at >> the bottom, but that's not what we're talking about.) >> >>> It just its use can be interfered with when 'switch' is involved. >> >> Yes. Everyone here knows that, and knew it before you started talking >> about it. >> >> Michael S wrote above that "The cases where I want to break out of >> the loop from the switch in the body of the loop are very common." >> Tim Rentsch questioned the "very common" part of that, and asked >> for an example. You jumped in and asserted that an example isn't >> necessary, because you misunderstood what was being said. >> > > I didn't read the whole subthread, but from what I read it seems that > the only reader that misunderstood my statement was David Brown. The > rest, including bart, understood just fine. > If I have misunderstood, I would love to be corrected. In a number of my posts I said I was not sure what you were talking about, and would need more explanation.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-12 22:31 +0300 |
| Message-ID | <20261012223144.00000f95@yahoo.com> |
| In reply to | #403051 |
On Mon, 12 Oct 2026 21:09:25 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 12/10/2026 21:02, Michael S wrote: > > On Sun, 11 Oct 2026 14:28:29 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > > >> bart <bc@freeuk.com> writes: > >> [...] > >>> 'break' to quit a loop early is part of the language, so why > >>> shouldn't someone make use it? > >> > >> Agreed. (There are coding styles that require loops to exit only > >> at the bottom, but that's not what we're talking about.) > >> > >>> It just its use can be interfered with when 'switch' is involved. > >>> > >> > >> Yes. Everyone here knows that, and knew it before you started > >> talking about it. > >> > >> Michael S wrote above that "The cases where I want to break out of > >> the loop from the switch in the body of the loop are very common." > >> Tim Rentsch questioned the "very common" part of that, and asked > >> for an example. You jumped in and asserted that an example isn't > >> necessary, because you misunderstood what was being said. > >> > > > > I didn't read the whole subthread, but from what I read it seems > > that the only reader that misunderstood my statement was David > > Brown. The rest, including bart, understood just fine. > > > > If I have misunderstood, I would love to be corrected. In a number > of my posts I said I was not sure what you were talking about, and > would need more explanation. > I thought that my comment is hard to misunderstand, but you proved me wrong. So I'd try to elaborate: switch() nested within loop is very common in my practice and I suppose in practice of everybody else. In my practice, but obviously not in practice of Tim Rentsch, it is sufficiently common to want to transfer control from point within such nested switch to point immediately following the containing loop. If break out of loop and break out of switch were different keyword, it would be very easy to do. But since the keyword is shared I have to use workarounds. Many of them were mentioned in the sub-thread. All workarounds work. They are all less simple and less elegant than what would have been possible if break keyword was not shared.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-12 22:32 +0200 |
| Message-ID | <11ajg4d$286mm$5@dont-email.me> |
| In reply to | #403053 |
On 2026-10-12 21:31, Michael S wrote:
> On Mon, 12 Oct 2026 21:09:25 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>>> [...]
>>
>> If I have misunderstood, I would love to be corrected. In a number
>> of my posts I said I was not sure what you were talking about, and
>> would need more explanation.
>
> I thought that my comment is hard to misunderstand, but you proved
> me wrong. So I'd try to elaborate:
>
> switch() nested within loop is very common in my practice and I suppose
> in practice of everybody else.
Something on a level like that was that I recall you had originally
written. So this doesn't explain more than your original statement
about that. It is quite clear (and I'm positive that it's as clear
to David). As far as I'm concerned, and that was how I understood
David's question, I'd (also) be (but only mildly!) interested what
the *concrete* _application cases_ those actually are since they (as
you said) appear so dominantly in your C-programs. Not the technical
structure ("for() switch() break;") but which types of applications
or application-semantical code patterns would require those that it
appears so often in your context. - My own interest here is limited,
as said, since it certainly doesn't apply to my C-code, and I never
noticed that it would be predominantly a prominent pattern in others'
C-code, beyond being one specific C-patterns amongst hundreds other
common C-patterns. - If it were extraordinarily common in your case
I'd indeed have thought about employing some standard pattern as a
substitute (see one of I think Dan's recent posts), and as you also
confirmed in this post - I snipped it - to actually have done this.
I hope that clarifies what some readers felt was missing.
Myself I also think that both, switch()-loop() and loop()-switch(),
constructs are just _corner-cases_ where doubling the 'break' could
help people, but it wouldn't at all address the more general tasks,
where e.g. more than just one loop and switch is nested.[*] - Myself
I'd certainly expect a solution that is more generally applicable;
labelled control-constructs are one way, even numbered breaks would
be an IMO acceptable extension. - But "C" only supports a one-level
local 'break' and a non-local flexible/arbitrary 'goto'. Two distinct
breaks would just pollute the name-space and not address the inherent
and basic restriction of being still just one-level breaks. - And I'm
confident that even then there'd pop up some pathological person and
complain about these breaks addressing not more that one levels.
Janis
[*] Note the many conditions we have here; exactly two specific and
different constructs, exactly two and not one or more than two, and
the case that you want to leave not one but both. - Can you imagine
that folks are wondering about what application context that stems
from that it appears so often (in your domain). - I think that was
the question that David had. It was certainly the question that
manifested in my mind when I read your post; only that I'm not too
much interested about it if you're operating in a domain where that
is more common than usual (and also don't bother to answer that).
> [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 22:05 +0100 |
| Message-ID | <11aji3e$58b$1@dont-email.me> |
| In reply to | #403058 |
On 12/10/2026 21:32, Janis Papanagnou wrote:
> On 2026-10-12 21:31, Michael S wrote:
>> On Mon, 12 Oct 2026 21:09:25 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>>> [...]
>>>
>>> If I have misunderstood, I would love to be corrected. In a number
>>> of my posts I said I was not sure what you were talking about, and
>>> would need more explanation.
>>
>> I thought that my comment is hard to misunderstand, but you proved
>> me wrong. So I'd try to elaborate:
>>
>> switch() nested within loop is very common in my practice and I suppose
>> in practice of everybody else.
>
> Something on a level like that was that I recall you had originally
> written. So this doesn't explain more than your original statement
> about that. It is quite clear (and I'm positive that it's as clear
> to David). As far as I'm concerned, and that was how I understood
> David's question, I'd (also) be (but only mildly!) interested what
> the *concrete* _application cases_ those actually are since they (as
> you said) appear so dominantly in your C-programs. Not the technical
> structure ("for() switch() break;") but which types of applications
> or application-semantical code patterns would require those that it
> appears so often in your context. - My own interest here is limited,
> as said, since it certainly doesn't apply to my C-code, and I never
> noticed that it would be predominantly a prominent pattern in others'
> C-code, beyond being one specific C-patterns amongst hundreds other
> common C-patterns. - If it were extraordinarily common in your case
> I'd indeed have thought about employing some standard pattern as a
> substitute (see one of I think Dan's recent posts), and as you also
> confirmed in this post - I snipped it - to actually have done this.
>
> I hope that clarifies what some readers felt was missing.
>
> Myself I also think that both, switch()-loop() and loop()-switch(),
> constructs are just _corner-cases_ where doubling the 'break' could
> help people, but it wouldn't at all address the more general tasks,
> where e.g. more than just one loop and switch is nested.[*] - Myself
> I'd certainly expect a solution that is more generally applicable;
> labelled control-constructs are one way, even numbered breaks would
> be an IMO acceptable extension. - But "C" only supports a one-level
> local 'break' and a non-local flexible/arbitrary 'goto'. Two distinct
> breaks would just pollute the name-space and not address the inherent
> and basic restriction of being still just one-level breaks. - And I'm
> confident that even then there'd pop up some pathological person and
> complain about these breaks addressing not more that one levels.
>
> Janis
>
> [*] Note the many conditions we have here; exactly two specific and
> different constructs, exactly two and not one or more than two, and
> the case that you want to leave not one but both. - Can you imagine
> that folks are wondering about what application context that stems
> from that it appears so often (in your domain). - I think that was
> the question that David had. It was certainly the question that
> manifested in my mind when I read your post; only that I'm not too
> much interested about it if you're operating in a domain where that
> is more common than usual (and also don't bother to answer that).
Such a lot of words to say little, if anything, that is comprehensible.
Oh, it must be my 'mental block'!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 23:14 +0200 |
| Message-ID | <11ajika$37d$1@dont-email.me> |
| In reply to | #403053 |
On 12/10/2026 21:31, Michael S wrote: > On Mon, 12 Oct 2026 21:09:25 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 12/10/2026 21:02, Michael S wrote: >>> On Sun, 11 Oct 2026 14:28:29 -0700 >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> >>>> bart <bc@freeuk.com> writes: >>>> [...] >>>>> 'break' to quit a loop early is part of the language, so why >>>>> shouldn't someone make use it? >>>> >>>> Agreed. (There are coding styles that require loops to exit only >>>> at the bottom, but that's not what we're talking about.) >>>> >>>>> It just its use can be interfered with when 'switch' is involved. >>>>> >>>> >>>> Yes. Everyone here knows that, and knew it before you started >>>> talking about it. >>>> >>>> Michael S wrote above that "The cases where I want to break out of >>>> the loop from the switch in the body of the loop are very common." >>>> Tim Rentsch questioned the "very common" part of that, and asked >>>> for an example. You jumped in and asserted that an example isn't >>>> necessary, because you misunderstood what was being said. >>>> >>> >>> I didn't read the whole subthread, but from what I read it seems >>> that the only reader that misunderstood my statement was David >>> Brown. The rest, including bart, understood just fine. >>> >> >> If I have misunderstood, I would love to be corrected. In a number >> of my posts I said I was not sure what you were talking about, and >> would need more explanation. >> > > I thought that my comment is hard to misunderstand, but you proved > me wrong. So I'd try to elaborate: > > switch() nested within loop is very common in my practice and I suppose > in practice of everybody else. Okay. I am not sure it is that common, and it is not a combination I make much use of in my own code. Many people aim to keep their functions short, while switches can lead to long functions - I think it is quite common in such circumstances to put the switch inside a function of its own, called from within the loop. > > In my practice, but obviously not in practice of Tim Rentsch, it > is sufficiently common to want to transfer control from point within > such nested switch to point immediately following the containing loop. > I cannot remember ever having need of doing something like that - at least not so that I thought "it would be nice if there were a way to break out of the loop from here". Maybe that is an effect of the way I tend to structure my code, or split up my functions - but I do not split my functions to achieve this effect. And the other common resolution, using a goto, is also not something I have needed. Different people have different styles, and occasionally you come across a code structure that someone else thinks is common, while you have never needed it yourself. > If break out of loop and break out of switch were different keyword, it > would be very easy to do. Now that I know what you are talking about, I can see how that would have helped. However, to me, that would seem a very niche usage and not something to consider for an additional keyword in the language. Labelled breaks that can also handle nested loops would, I think, be of significantly wider use while also handling your situation. > > But since the keyword is shared I have to use workarounds. Many of them > were mentioned in the sub-thread. All workarounds work. They are all > less simple and less elegant than what would have been possible if break > keyword was not shared. > Only you know your own code, and what you judge as elegant, so there's no argument here. Perhaps I have written code that you would think could have been written more clearly with a switch within a loop if C had two different "break" statements - but it is not a feature that I could see myself making use of.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-13 07:23 +0000 |
| Message-ID | <11akm9q$29tpl$1@paganini.bofh.team> |
| In reply to | #403053 |
Michael S <already5chosen@yahoo.com> wrote:
> On Mon, 12 Oct 2026 21:09:25 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 12/10/2026 21:02, Michael S wrote:
>> > On Sun, 11 Oct 2026 14:28:29 -0700
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >
>> >> bart <bc@freeuk.com> writes:
>> >> [...]
>> >>> 'break' to quit a loop early is part of the language, so why
>> >>> shouldn't someone make use it?
>> >>
>> >> Agreed. (There are coding styles that require loops to exit only
>> >> at the bottom, but that's not what we're talking about.)
>> >>
>> >>> It just its use can be interfered with when 'switch' is involved.
>> >>>
>> >>
>> >> Yes. Everyone here knows that, and knew it before you started
>> >> talking about it.
>> >>
>> >> Michael S wrote above that "The cases where I want to break out of
>> >> the loop from the switch in the body of the loop are very common."
>> >> Tim Rentsch questioned the "very common" part of that, and asked
>> >> for an example. You jumped in and asserted that an example isn't
>> >> necessary, because you misunderstood what was being said.
>> >>
>> >
>> > I didn't read the whole subthread, but from what I read it seems
>> > that the only reader that misunderstood my statement was David
>> > Brown. The rest, including bart, understood just fine.
>> >
>>
>> If I have misunderstood, I would love to be corrected. In a number
>> of my posts I said I was not sure what you were talking about, and
>> would need more explanation.
>>
>
> I thought that my comment is hard to misunderstand, but you proved
> me wrong. So I'd try to elaborate:
>
> switch() nested within loop is very common in my practice and I suppose
> in practice of everybody else.
>
> In my practice, but obviously not in practice of Tim Rentsch, it
> is sufficiently common to want to transfer control from point within
> such nested switch to point immediately following the containing loop.
>
> If break out of loop and break out of switch were different keyword, it
> would be very easy to do.
>
> But since the keyword is shared I have to use workarounds. Many of them
> were mentioned in the sub-thread. All workarounds work. They are all
> less simple and less elegant than what would have been possible if break
> keyword was not shared.
I think there is still not clear what "common" in your text above
means. To clarify a bit, I have a non-C codebase where one can
use 'break' within equivalent of 'switch'. My gut feelings were
that such use is reasonably common (I certainly remeber such uses
in the codebase). But counting kerwords shows that I have 6053
occurences of keyword indicating loop (some may be in comments,
but that should not affect statistics too much), 223 occurences
of 'break', 197 occurences of equivalet of 'continue', 2390
occurences of 'return'. In this language 'return' is only
used for ealy returns, otherwise last value computed (which
may be void) is returned.
So what those counts indicate: majority of loops is simple, that
is have no early exit. Vast majority of early exits is done
via 'return'. "Interesting" loop control is relatively rare.
Checking which 'break'-s are within equivalent of 'switch' would
require manual inspection and that would be too much work. But
reasonable guestimate to that there are tens such uses. In
a sense that is common, that is significantly more than one
case. If my guestimate is correct, then this may be nontrivial
fraction of all uses of 'break'. OTOH that is tiny fraction
of all loops.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 12:12 +0200 |
| Message-ID | <11al05t$4o6l$1@dont-email.me> |
| In reply to | #403081 |
On 2026-10-13 09:23, Waldek Hebisch wrote:
> [...]
> So what those counts indicate: majority of loops is simple, that
> is have no early exit. Vast majority of early exits is done
> via 'return'. "Interesting" loop control is relatively rare.
> Checking which 'break'-s are within equivalent of 'switch' would
> require manual inspection and that would be too much work. But
> reasonable guestimate to that there are tens such uses. In
> a sense that is common, that is significantly more than one
> case. If my guestimate is correct, then this may be nontrivial
> fraction of all uses of 'break'. OTOH that is tiny fraction
> of all loops.
From my (personal) perspective, I commonly have two types of
such specific constructs; a very common one is iterating over
options
while ((opt = getopts (...)) != -1)
switch (opt) ...
where, of course, and quite naturally, always the whole loop
is iterated, with no early leaving. And the second common loop
type is those where the switched data comes from the function
as well
while ((token = parse (...)) != END_TOKEN)
switch (token) ...
I'm aware that one might wants to pass and process two values
from a function (as I interpreted one of bart's recent code
fragments), but then, and if it would be "impossible" to avoid
that pattern, I'd just add a condition
int leaving = 0;
while ((token = parse (&token...)) != ERROR && !leaving)
switch (token)
case END_TOKEN: leaving = 1; ...
that's really trivial and straightforward, and it's beyond me
why anyone (but bart, of course) would see a problem here.
Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 11:26 +0100 |
| Message-ID | <11al10u$eiet$1@dont-email.me> |
| In reply to | #403086 |
On 13/10/2026 11:12, Janis Papanagnou wrote: > On 2026-10-13 09:23, Waldek Hebisch wrote: >> [...] >> So what those counts indicate: majority of loops is simple, that >> is have no early exit. Vast majority of early exits is done >> via 'return'. "Interesting" loop control is relatively rare. >> Checking which 'break'-s are within equivalent of 'switch' would >> require manual inspection and that would be too much work. But >> reasonable guestimate to that there are tens such uses. In >> a sense that is common, that is significantly more than one >> case. If my guestimate is correct, then this may be nontrivial >> fraction of all uses of 'break'. OTOH that is tiny fraction >> of all loops. > > From my (personal) perspective, I commonly have two types of > such specific constructs; a very common one is iterating over > options > > while ((opt = getopts (...)) != -1) > switch (opt) ... > > where, of course, and quite naturally, always the whole loop > is iterated, with no early leaving. And the second common loop > type is those where the switched data comes from the function > as well > > while ((token = parse (...)) != END_TOKEN) > switch (token) ... > > I'm aware that one might wants to pass and process two values > from a function (as I interpreted one of bart's recent code > fragments), but then, and if it would be "impossible" to avoid > that pattern, I'd just add a condition > > int leaving = 0; > while ((token = parse (&token...)) != ERROR && !leaving) > switch (token) > case END_TOKEN: leaving = 1; ... > > that's really trivial and straightforward, and it's beyond me > why anyone (but bart, of course) would see a problem here. Because it's a hack. But if this is acceptable, then why does C even have loop-break? Since there is always some workaround (or 'writing code' as David Brown puts it.) What would be the consequences of C not having it: would they be positive or negative overall? Now apply the same analysis to a hypothetical loop-break that works inside switch.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-10-13 12:10 +0100 |
| Message-ID | <11al3jt$fig1$1@dont-email.me> |
| In reply to | #403090 |
On 13/10/2026 11:26, bart wrote: > On 13/10/2026 11:12, Janis Papanagnou wrote: >> On 2026-10-13 09:23, Waldek Hebisch wrote: >>> [...] >>> So what those counts indicate: majority of loops is simple, that >>> is have no early exit. Vast majority of early exits is done >>> via 'return'. "Interesting" loop control is relatively rare. >>> Checking which 'break'-s are within equivalent of 'switch' would >>> require manual inspection and that would be too much work. But >>> reasonable guestimate to that there are tens such uses. In >>> a sense that is common, that is significantly more than one >>> case. If my guestimate is correct, then this may be nontrivial >>> fraction of all uses of 'break'. OTOH that is tiny fraction >>> of all loops. >> >> From my (personal) perspective, I commonly have two types of >> such specific constructs; a very common one is iterating over >> options >> >> while ((opt = getopts (...)) != -1) >> switch (opt) ... >> >> where, of course, and quite naturally, always the whole loop >> is iterated, with no early leaving. And the second common loop >> type is those where the switched data comes from the function >> as well >> >> while ((token = parse (...)) != END_TOKEN) >> switch (token) ... >> >> I'm aware that one might wants to pass and process two values >> from a function (as I interpreted one of bart's recent code >> fragments), but then, and if it would be "impossible" to avoid >> that pattern, I'd just add a condition >> >> int leaving = 0; >> while ((token = parse (&token...)) != ERROR && !leaving) >> switch (token) >> case END_TOKEN: leaving = 1; ... >> >> that's really trivial and straightforward, and it's beyond me >> why anyone (but bart, of course) would see a problem here. > Because it's a hack. But if this is acceptable, then why does C even > have loop-break? Since there is always some workaround (or 'writing > code' as David Brown puts it.) > > What would be the consequences of C not having it: would they be > positive or negative overall? > > Now apply the same analysis to a hypothetical loop-break that works > inside switch. > You could argue that 'break' is just syntactical sugar for 'goto label'. If you want to break out of multiple levels, then just use a goto. Some people have a pathological hatred of 'goto', sure. There's alway a way to avoid goto, if that's what you really want. That the code, and it's intention, is clear is the important thing. I really don't see the issue. It's a style thing at most.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-13 06:55 -0700 |
| Message-ID | <864iepiu2t.fsf@linuxsc.com> |
| In reply to | #403095 |
Richard Harnden <richard.nospam@gmail.invalid> writes: > On 13/10/2026 11:26, bart wrote: > >> On 13/10/2026 11:12, Janis Papanagnou wrote: >> >>> On 2026-10-13 09:23, Waldek Hebisch wrote: >>> >>>> [...] >>>> So what those counts indicate: majority of loops is simple, >>>> that is have no early exit. Vast majority of early exits is >>>> done via 'return'. "Interesting" loop control is relatively >>>> rare. Checking which 'break'-s are within equivalent of >>>> 'switch' would require manual inspection and that would be too >>>> much work. But reasonable guestimate to that there are tens >>>> such uses. In a sense that is common, that is significantly >>>> more than one case. If my guestimate is correct, then this may >>>> be nontrivial fraction of all uses of 'break'. OTOH that is >>>> tiny fraction of all loops. >>> >>> From my (personal) perspective, I commonly have two types of >>> such specific constructs; a very common one is iterating over >>> options >>> >>> while ((opt = getopts (...)) != -1) >>> switch (opt) ... >>> >>> where, of course, and quite naturally, always the whole loop >>> is iterated, with no early leaving. And the second common loop >>> type is those where the switched data comes from the function >>> as well >>> >>> while ((token = parse (...)) != END_TOKEN) >>> switch (token) ... >>> >>> I'm aware that one might wants to pass and process two values >>> from a function (as I interpreted one of bart's recent code >>> fragments), but then, and if it would be "impossible" to avoid >>> that pattern, I'd just add a condition >>> >>> int leaving = 0; >>> while ((token = parse (&token...)) != ERROR && !leaving) >>> switch (token) >>> case END_TOKEN: leaving = 1; ... >>> >>> that's really trivial and straightforward, and it's beyond me >>> why anyone (but bart, of course) would see a problem here. >> >> Because it's a hack. But if this is acceptable, then why does C >> even have loop-break? Since there is always some workaround (or >> 'writing code' as David Brown puts it.) >> >> What would be the consequences of C not having it: would they be >> positive or negative overall? >> >> Now apply the same analysis to a hypothetical loop-break that >> works inside switch. > > You could argue that 'break' is just syntactical sugar for > 'goto label'. > > If you want to break out of multiple levels, then just use a > goto. > > Some people have a pathological hatred of 'goto', sure. > There's alway a way to avoid goto, if that's what you really > want. That the code, and it's intention, is clear is the > important thing. > > I really don't see the issue. It's a style thing at most. Very pragmatic. This pretty much matches my sentiments.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 13:33 +0200 |
| Message-ID | <11al4u0$4o6m$3@dont-email.me> |
| In reply to | #403090 |
On 2026-10-13 12:26, bart wrote:
> On 13/10/2026 11:12, Janis Papanagnou wrote:
>> [...]
>> I'm aware that one might wants to pass and process two values
>> from a function (as I interpreted one of bart's recent code
>> fragments), but then, and if it would be "impossible" to avoid
>> that pattern, I'd just add a condition
>>
>> int leaving = 0;
>> while ((token = parse (&token...)) != ERROR && !leaving)
>> switch (token)
>> case END_TOKEN: leaving = 1; ...
I just wrote that down without thinking, so I take the opportunity
to correct that. In practice you would better swap the conditions
and name the return code variable correctly
while (!leaving && (rc = parse (&token...)) != ERROR)
>>
>> that's really trivial and straightforward, and it's beyond me
>> why anyone (but bart, of course) would see a problem here.
>
> Because it's a hack.
Your "definitions" are generally very peculiar, and they regularly
have been considered here to not reflect what typical sane people
would say about standard code patterns and programming. - I can
only explain your personal valuation if I assume that your thinking
is working in an extremely narrow corridor.
> But if this is acceptable, then why does C even
> have loop-break? Since there is always some workaround (or 'writing
> code' as David Brown puts it.)
This has already been explained so often, implicitly and explicitly,
that I don't know why you're asking it again and again. - Are you
really interested to hear all that again?! - Your perception and
comprehension appears to be like a human /dev/null. - Okay, again...
There are two principal and common "operation modes" with branches
of switch-like constructs; to leave after the the tagged commands
have been processed or to continue with the subsequent commands
("fall-through"). Various (also historic) languages do not support
a fall-through but have even more limits on their counterpart of
switch. The "C" designers decided to support both. Being a low-level
language they designed it with primitive semantics but to allow full
expressive flexibility. There are a few options how to distinguish
the switch "operation-modes". Some languages indicated both cases
(Kornshell, for example with ';;' and ';&' respectively). "C" has
decided to indicate syntactically just one of the cases explicitly,
_the case when the linear control flow is disrupted_; that thought
makes also sense since it matches the other possible "jumps", that
are existing with 'continue', 'return', 'exit()', 'goto'.
This should (again) explain what you asked with your question. (But
we also know that you aren't really interested in the answer; your
questions are obviously and mostly just your expression of "I don't
like the situation with C".)
>
> What would be the consequences of C not having it: would they be
> positive or negative overall?
Before I "met" you, bart, I would have guessed that any other
choice of implementation of 'switch' in "C" would not have made
and significant difference. Now I'd say, if the design would have
been different then it would be much better, since then we could
spare us all the pointless posts with you. (But of course you'd
then find other complaints and in practice nothing would change
anyway.)
>
> Now apply the same analysis to a hypothetical loop-break that works
> inside switch.
I (and others) have explicitly answered that in other posts. - I'm
sorry that you were incapable of understanding those explanations.
No; I won't repeat it once again. - As homework I ask you to pick
all those posts, read them, try to understand them, and create a
written summary. (By that process pupils usually learn something.)
Janis
PS: Note that I usually completely skip your posts - that's why you
only very rarely see a reply unless I see you quoted in another post
- and I've opened this post of you only because I thought you might
have commented on my little mistake above that I intended to correct.
So generally you can spare your meaningless replies to my posts and
save your (and others') time.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 13:41 +0100 |
| Message-ID | <11al8uc$hk7a$1@dont-email.me> |
| In reply to | #403097 |
On 13/10/2026 12:33, Janis Papanagnou wrote:
> On 2026-10-13 12:26, bart wrote:
>> On 13/10/2026 11:12, Janis Papanagnou wrote:
>>> [...]
>>> I'm aware that one might wants to pass and process two values
>>> from a function (as I interpreted one of bart's recent code
>>> fragments), but then, and if it would be "impossible" to avoid
>>> that pattern, I'd just add a condition
>>>
>>> int leaving = 0;
>>> while ((token = parse (&token...)) != ERROR && !leaving)
>>> switch (token)
>>> case END_TOKEN: leaving = 1; ...
>
> I just wrote that down without thinking, so I take the opportunity
> to correct that. In practice you would better swap the conditions
> and name the return code variable correctly
>
> while (!leaving && (rc = parse (&token...)) != ERROR)
So your workaround had an error. That's what happens.
>>>
>>> that's really trivial and straightforward, and it's beyond me
>>> why anyone (but bart, of course) would see a problem here.
>>
>> Because it's a hack.
>
> Your "definitions" are generally very peculiar, and they regularly
> have been considered here to not reflect what typical sane people
> would say about standard code patterns and programming. - I can
> only explain your personal valuation if I assume that your thinking
> is working in an extremely narrow corridor.
Jesus. I take it that you don't agree it is a hack then?
(From Google AI: "In coding, a hack can mean a quick, inelegant
workaround to fix a problem". Other definitions are given, but this what
I have in mind.)
>> But if this is acceptable, then why does C even have loop-break? Since
>> there is always some workaround (or 'writing code' as David Brown puts
>> it.)
>
> This has already been explained so often, implicitly and explicitly,
> that I don't know why you're asking it again and again. - Are you
> really interested to hear all that again?! - Your perception and
> comprehension appears to be like a human /dev/null. - Okay, again...
Just answering my question would be fewer words!
> There are two principal and common "operation modes" with branches
> of switch-like constructs; to leave after the the tagged commands
> have been processed or to continue with the subsequent commands
> ("fall-through"). Various (also historic) languages do not support
> a fall-through but have even more limits on their counterpart of
> switch. The "C" designers decided to support both. Being a low-level
> language they designed it with primitive semantics but to allow full
> expressive flexibility. There are a few options how to distinguish
> the switch "operation-modes". Some languages indicated both cases
> (Kornshell, for example with ';;' and ';&' respectively). "C" has
> decided to indicate syntactically just one of the cases explicitly,
> _the case when the linear control flow is disrupted_; that thought
> makes also sense since it matches the other possible "jumps", that
> are existing with 'continue', 'return', 'exit()', 'goto'.
You have a peculiar, dense, machine-like writing style. I'm fairly
certain you are a real human, but this is impenetrable, sorry.
> This should (again) explain what you asked with your question. (But
> we also know that you aren't really interested in the answer; your
> questions are obviously and mostly just your expression of "I don't
> like the situation with C".)
>
>>
>> What would be the consequences of C not having it: would they be
>> positive or negative overall?
>
> Before I "met" you, bart, I would have guessed that any other
> choice of implementation of 'switch' in "C" would not have made
> and significant difference. Now I'd say, if the design would have
> been different then it would be much better, since then we could
> spare us all the pointless posts with you. (But of course you'd
> then find other complaints and in practice nothing would change
> anyway.)
If you aren't going to engage, why bother posting?
> PS: Note that I usually completely skip your posts
And I usually don't bother replying to yours since all you do is
personal insults, when I can understand what you're on about.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-13 14:38 +0000 |
| Message-ID | <11alfq3$ia7$1@reader2.panix.com> |
| In reply to | #403101 |
In article <11al8uc$hk7a$1@dont-email.me>, bart <bc@freeuk.com> wrote: >[snip] >So your workaround had an error. That's what happens. There is no programming that prevents all errors. >[snip] >Jesus. I take it that you don't agree it is a hack then? I'll admit it's a hack, but I just don't care. It's certainly not worth expending as much effort as even this thread alone has taken. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 18:04 +0200 |
| Message-ID | <11alkqa$4o6l$3@dont-email.me> |
| In reply to | #403104 |
On 2026-10-13 16:38, Dan Cross wrote: > In article <11al8uc$hk7a$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> [snip] >> So your workaround had an error. That's what happens. I could foresee such a stupid response! - You're a hopeless case. Given that you've had even stupid syntax errors in your original code I'm astonished that you even dare to get into such argument. > > There is no programming that prevents all errors. (That was not even programming; it was a quick write down for the post as an example structure to explain what's to be visualized.) > >> [snip] >> Jesus. I take it that you don't agree it is a hack then? Writing a loop with a predicate that is composed by an 'and' is certainly not a "hack" but usual programming. Nowadays you learn such things in kindergarten. Janis > [...]
[toc] | [prev] | [next] | [standalone]
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web