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 356 — 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 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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +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 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 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 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 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 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 12 of 18 — ← Prev page 1 … 10 11 [12] 13 14 … 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 16:12 +0200 |
| Message-ID | <11aipsc$3kr94$1@dont-email.me> |
| In reply to | #403032 |
On 12/10/2026 15:37, bart wrote:
> On 12/10/2026 06:05, David Brown wrote:
>> On 11/10/2026 19:57, bart wrote:
>>> On 11/10/2026 18:17, David Brown wrote:
>>
>>>> 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'.
>>
>> The "pressure" is just because people are curious for more detail.
>> Michael is an experienced C programmer, but we all work in slightly
>> different ways on slightly different kinds of code bases. I can't
>> think why breaking out of loops within switch cases would be "very
>> common", but I have no reason to suspect Michael was not writing code
>> "properly". I can't think why such code - common or not - would be
>> problematic, or why having two different "break" keywords or
>> constructs would be better for his code. That's why I would like
>> Michael to give more details - not to tell him his "wrong", but to
>> learn more about his coding.
>>
>>>
>>> 'break' to quit a loop early is part of the language, so why
>>> shouldn't someone make use it?
>>
>> I think most C programmers do, at least occasionally.
>>
>>>
>>> It just its use can be interfered with when 'switch' is involved.
>>>
>>
>> I personally have never found an issue there. "break" breaks out of
>> the innermost loop or switch. If you write switch statements that are
>> intermingled with loops in a non-structured manner, I am sure things
>> get difficult and unclear. Since I do not write code with such
>> intermingling, I have not had any such problems.
>
> What do mean by 'intermingled' - nested? That's how structured
> programming works!
>
No - if I had meant "nested", I would have written "nested". In C,
switch statements are not fully structured. That's why I wrote
"intermingled". I had assumed the meaning was clear, but there is no
standard definition of "intermingled" code.
You can write things like :
int foo(int x) {
int y = x;
switch (x) {
case 0 :
y++;
break;
case 1 :
for (y = 0; y < x; y++) {
case 2:
x++;
}
}
return y;
}
That is obviously a silly, invented example. But it is possible to jump
into loops with an outer switch. Such things may be of use to some
people - just as "goto" jumping around might be of use. It is of no
interest to me, and I don't write code that intermingles switches and
loops (or conditionals). I limit my switch statements to having clear
structure - using braces to create blocks within cases if I have local
variables.
In the hypothetical example above, if there was a "break" after "x++;",
it could easily be unclear to the reader if it applied to the loop, or
to the switch. Having separate "break_switch" and "break_for" keywords
or constructs would make that difference clear - but I cannot think of a
real example where it would not be clearer to have the entire loop
within one case and avoid the issue altogether.
> Otherwise there is no intermingling in this example:
>
> for (i=0; i < N; ++i) {
> x = A[i];
> if (x == 5 || x == 6 || x == 10 || x == 11) break;
>
> switch (A[i]) {
> case 5: case 6: case 10: case 11: break; // ??
> }
> }
That is not "intermingling", as I used the word - it is just a switch
nested inside a loop.
>
> The loop body shows two ways of aborting the loop when an exit condition
> is detected:
>
> * Using an if-statement and 'break'
>
> * Using a switch-statement and ... break?
>
> The second doesn't work because 'break' now shadows its outer meaning.
> Both would otherwise be reasonable choices for this logic.
No, they would not be reasonable choices. It is very, /very/ simple, as
long as your code is written in a structured manner - nesting the
constructs as you did above. "break" applies to the innermost loop or
switch. That's the rule.
>
> Here's another example:
>
> for (i=0; i < N; ++i) {
> if (A[i] == 1)
> if (!f()) break;
> else if (A[i] == 2)
> if (!g()) break;
> else
> if (!h()) break;
> }
>
> Here, someone might notice that 'switch' suits this pattern better than
> an if-else chain. So they try this:
>
> for (i=0; i < N; ++i) {
> switch (A[i]) {
> case 1:
> if (!f()) break;
> case 2:
> if (!g()) break;
> default:
> if (!h()) break;
> }
> }
>
> This is valid C still, but it doesn't have the same behaviour.
Surprise! Someone changed the code, and the behaviour changed! Who
could have imagined that might happen?
> In my language and in my programs,
No one else cares. Your language is your own, and not relevant outside
of your bubble. You keep thinking it somehow "proves" your points, or
that it shows how "wrong" C is - it does not. There is no need to waste
your time or other readers' time by writing about it. Stick to writing
about C here.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 16:32 +0100 |
| Message-ID | <11aiui8$3nisn$1@dont-email.me> |
| In reply to | #403033 |
On 12/10/2026 15:12, David Brown wrote:
> On 12/10/2026 15:37, bart wrote:
> That is obviously a silly, invented example.
Yes, but I am not discussing that in this post. The subthread is
switch-break interfering with loop-break.
>>
>> The loop body shows two ways of aborting the loop when an exit
>> condition is detected:
>>
>> * Using an if-statement and 'break'
>>
>> * Using a switch-statement and ... break?
>>
>> The second doesn't work because 'break' now shadows its outer meaning.
>> Both would otherwise be reasonable choices for this logic.
>
> No, they would not be reasonable choices.
Why not? You seem to be talking about both IF and SWITCH here; are there
any other conditional control-flow statements that I'm not aware of?
Or is your more reasonable approach involving superfluous loops or
superfluous functions (just to score some point)?
We're trying to avoid convoluted code.
> It is very, /very/ simple, as
> long as your code is written in a structured manner - nesting the
> constructs as you did above. "break" applies to the innermost loop or
> switch. That's the rule.
Yes, we know that's rule! And that is the problem: the break of switch
interferes with normal loop break, which means that forces your hand
whenever you'd prefer to use the more apt 'switch' construct.
>> This is valid C still, but it doesn't have the same behaviour.
>
> Surprise! Someone changed the code, and the behaviour changed! Who
> could have imagined that might happen?
Now you're being facetious. THE BEHAVIOUR SHOULD BE EXACTLY THE SAME:
Loop
....
Break when some condition is true
....
You should be able to choose how you write your conditions. So the fact
that the behaviour changes while expressing the same logic IS THE PROBLEM.
I mean, why on earth should it? Just because some numskull decided to
use the same fucking keyword for two different things?
Now, everyone is trying to suggest it was in fact a wonderful idea, you
save one whole keyword, and that it's SO easy to try and avoid the
ensuing mess by programming your way around it or avoiding certain
statement combos.
>> In my language and in my programs,
>
> No one else cares. Your language is your own, and not relevant outside
> of your bubble. You keep thinking it somehow "proves" your points, or
> that it shows how "wrong" C is - it does not.
Then you've just got your head in the sand, sorry.
People have been asking about examples of exiting a loop from within
switch, and in my code there are myriad such examples, even more than
I'd thought (I guess I don't even think about it).
That they're in a different language doesn't matter: it shows the idiom,
that code-pattern, can be useful and can be the more natural and
intuitive choice.
Of course you won't find such examples in C because the language doesn't
allow it!
Oh, and I also showed an easy solution to the nested loops issue.
> There is no need to waste
> your time or other readers' time by writing about it. Stick to writing
> about C here.
The subject is Taming the Switch-Statement, and the opening post was
ways to forget writing that famous 'break'.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 19:05 +0200 |
| Message-ID | <11aj41i$3oq6i$1@dont-email.me> |
| In reply to | #403036 |
On 12/10/2026 17:32, bart wrote: > On 12/10/2026 15:12, David Brown wrote: >> On 12/10/2026 15:37, bart wrote: > >> That is obviously a silly, invented example. > > Yes, but I am not discussing that in this post. The subthread is switch- > break interfering with loop-break. > "Switch break" does not in any sense interfere with "loop break". There is no interference, no conflict, no confusion. "break" leaves the current innermost switch or loop. It is simple and obvious. And while I agree that occasionally you might want a want to break out of an outer switch or loop from within an inner one, it applies equally to two nested loops, two nested switches, a switch containing a nested loop, and a loop containing a nested switch. > >>> >>> The loop body shows two ways of aborting the loop when an exit >>> condition is detected: >>> >>> * Using an if-statement and 'break' >>> >>> * Using a switch-statement and ... break? >>> >>> The second doesn't work because 'break' now shadows its outer >>> meaning. Both would otherwise be reasonable choices for this logic. >> >> No, they would not be reasonable choices. > > Why not? You seem to be talking about both IF and SWITCH here; are there > any other conditional control-flow statements that I'm not aware of? I am sure you have read the C standards, so that you know the answer to that. > > Or is your more reasonable approach involving superfluous loops or > superfluous functions (just to score some point)? > > We're trying to avoid convoluted code. > No, I don't think "we" are trying to do anything. /You/ are trying to invent problems, and to persuade others that the confusions in your own mind are real issues for C programmers. I am explaining that there is no special challenge here. >> It is very, /very/ simple, as long as your code is written in a >> structured manner - nesting the constructs as you did above. "break" >> applies to the innermost loop or switch. That's the rule. > > Yes, we know that's rule! So we are done, then? One simple rule to learn - and a pretty obvious rule at that. Now you know the answer, you can stop worrying about it. > And that is the problem: the break of switch > interferes with normal loop break, which means that forces your hand > whenever you'd prefer to use the more apt 'switch' construct. There is no interference. There is a /limitation/ - "break" only exits the innermost structure, and cannot break out of outer structures. It's like "return" only returns from the current function, not the function that called it. > >>> This is valid C still, but it doesn't have the same behaviour. >> >> Surprise! Someone changed the code, and the behaviour changed! Who >> could have imagined that might happen? > > Now you're being facetious. THE BEHAVIOUR SHOULD BE EXACTLY THE SAME: > Only in your mind. You changed the code significantly, and the behaviour changes. > Loop > .... > Break when some condition is true > .... > > You should be able to choose how you write your conditions. So the fact > that the behaviour changes while expressing the same logic IS THE PROBLEM. You can often express the same logic in many different ways in code, and the details of how you write the code need to be changed to match. Why should anyone expect that an "if" statement can be changed to a "switch" statement and everything else should remain the same? If I change a "while" loop to a "do" loop, it's still a loop - but the contents must be changed if I want the same behaviour. You are inventing things that don't exist outside your imagination, and then complaining that C was not designed specifically to suit the rules you just made up. > > I mean, why on earth should it? Just because some numskull decided to > use the same fucking keyword for two different things? > > Now, everyone is trying to suggest it was in fact a wonderful idea, you > save one whole keyword, and that it's SO easy to try and avoid the > ensuing mess by programming your way around it or avoiding certain > statement combos. > Again, I can't speak for anyone else. But the very idea that any of this should be difficult or an issue for any normal (not psychotic) C programmer had never occurred to me until it was brought up in this thread. > >>> In my language and in my programs, >> >> No one else cares. Your language is your own, and not relevant >> outside of your bubble. You keep thinking it somehow "proves" your >> points, or that it shows how "wrong" C is - it does not. > > Then you've just got your head in the sand, sorry. > > People have been asking about examples of exiting a loop from within > switch, and in my code there are myriad such examples, even more than > I'd thought (I guess I don't even think about it). > > That they're in a different language doesn't matter: it shows the idiom, > that code-pattern, can be useful and can be the more natural and > intuitive choice. > > Of course you won't find such examples in C because the language doesn't > allow it! > > Oh, and I also showed an easy solution to the nested loops issue. > > >> There is no need to waste your time or other readers' time by >> writing about it. Stick to writing about C here. > The subject is Taming the Switch-Statement, and the opening post was > ways to forget writing that famous 'break'. We all know that some people sometimes forget "break" statements in their switches. Mistakes and typos happen to the best of us, in all programming languages, and every programming language has its own selection of "archetypical" mistakes, and tools to help catch or avoid them.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 19:15 +0100 |
| Message-ID | <11aj844$3rt9c$1@dont-email.me> |
| In reply to | #403041 |
On 12/10/2026 18:05, David Brown wrote: > On 12/10/2026 17:32, bart wrote: >>>> The loop body shows two ways of aborting the loop when an exit >>>> condition is detected: >>>> >>>> * Using an if-statement and 'break' >>>> >>>> * Using a switch-statement and ... break? >>>> >>>> The second doesn't work because 'break' now shadows its outer >>>> meaning. Both would otherwise be reasonable choices for this logic. >>> >>> No, they would not be reasonable choices. >> >> Why not? You seem to be talking about both IF and SWITCH here; are >> there any other conditional control-flow statements that I'm not aware >> of? > > I am sure you have read the C standards, so that you know the answer to > that. I still don't know what you mean. So, using 'if' for conditional exit from a loop is unreasonable. But so is 'switch', even putting aside the issue with break. It seems to me that you are just gaslighting now. >> Yes, we know that's rule! > > So we are done, then? One simple rule to learn - and a pretty obvious > rule at that. Now you know the answer, you can stop worrying about it. What? Having a stupid rule in place doesn't mean it hasn't caused issues! >> And that is the problem: the break of switch interferes with normal >> loop break, which means that forces your hand whenever you'd prefer to >> use the more apt 'switch' construct. > > There is no interference. There is a /limitation/ - "break" only exits > the innermost structure, and cannot break out of outer structures. It's > like "return" only returns from the current function, not the function > that called it. It's a good thing that they didn't choose to use 'return' for both loop exit and switch-break then! But if they had: * You couldn't use early return from inside a loop * Nor from inside a switch * You still couldn't exit early from a loop from inside switch * 'return' would do three different things depending on context, but none interfere with each other Obviously this wouldn't be a problem for you either? After all that would be the rule, still a fairly simple one. And it would have saved one more keyword which is really, really important. Yeah, I think now we're done.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 16:43 -0700 |
| Message-ID | <11ajraq$28f2$3@kst.eternal-september.org> |
| In reply to | #403046 |
bart <bc@freeuk.com> writes:
[...]
> Yeah, I think now we're done.
Promise?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-12 16:45 -0700 |
| Message-ID | <11ajrf0$28f2$4@kst.eternal-september.org> |
| In reply to | #403046 |
bart <bc@freeuk.com> writes:
[...]
> Yeah, I think now we're done.
You've posted 5 more articles in this thread after the above.
Does "done" mean something else in your language?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 23:46 +0000 |
| Message-ID | <11ajrh8$i6g$1@reader2.panix.com> |
| In reply to | #403072 |
In article <11ajrf0$28f2$4@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >bart <bc@freeuk.com> writes: >[...] >> Yeah, I think now we're done. > >You've posted 5 more articles in this thread after the above. >Does "done" mean something else in your language? It's how you terminate the scope introduced by a looping construct in bart's language; it doesn't mean that the loop is finished iterating. ;-P - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 00:56 +0100 |
| Message-ID | <11ajs3a$382u$2@dont-email.me> |
| In reply to | #403072 |
On 13/10/2026 00:45, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> Yeah, I think now we're done. > > You've posted 5 more articles in this thread after the above. > Does "done" mean something else in your language? > Other people than David Brown post remarks and it is polite to respond. As I did to you a few minutes ago.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 17:58 +0000 |
| Message-ID | <11aj73v$c2u$1@reader2.panix.com> |
| In reply to | #403032 |
In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 12/10/2026 06:05, David Brown wrote:
>> On 11/10/2026 19:57, bart wrote:
>>> On 11/10/2026 18:17, David Brown wrote:
>>
>>>> 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'.
>>
>> The "pressure" is just because people are curious for more detail.
>> Michael is an experienced C programmer, but we all work in slightly
>> different ways on slightly different kinds of code bases. I can't think
>> why breaking out of loops within switch cases would be "very common",
>> but I have no reason to suspect Michael was not writing code "properly".
>> I can't think why such code - common or not - would be problematic, or
>> why having two different "break" keywords or constructs would be better
>> for his code. That's why I would like Michael to give more details -
>> not to tell him his "wrong", but to learn more about his coding.
>>
>>>
>>> 'break' to quit a loop early is part of the language, so why shouldn't
>>> someone make use it?
>>
>> I think most C programmers do, at least occasionally.
>>
>>>
>>> It just its use can be interfered with when 'switch' is involved.
>>>
>>
>> I personally have never found an issue there. "break" breaks out of the
>> innermost loop or switch. If you write switch statements that are
>> intermingled with loops in a non-structured manner, I am sure things get
>> difficult and unclear. Since I do not write code with such
>> intermingling, I have not had any such problems.
>
>What do mean by 'intermingled' - nested? That's how structured
>programming works!
Keith explained this already, but I feel obligated to respond to
a point....
>Otherwise there is no intermingling in this example:
>
> for (i=0; i < N; ++i) {
> x = A[i];
> if (x == 5 || x == 6 || x == 10 || x == 11) break;
>
> switch (A[i]) {
> case 5: case 6: case 10: case 11: break; // ??
> }
> }
for (i = 0; i < N; i++) {
x = A[i];
switch (x) {
case 5: case 6: case 10: case 11: goto out;
}
}
out:
>The loop body shows two ways of aborting the loop when an exit condition
>is detected:
>
>* Using an if-statement and 'break'
>
>* Using a switch-statement and ... break?
Goto.
"If you want to go somewhere, goto is the best way to get
there." -- Ken Thompson, via the Plan 9 `fortune` file.
Alternatively, one might extract the loop into its own little
function, and use an early `return` to break out of it:
static inline void
loop(void)
{
for (i = 0; i < N; i++) {
x = a[i];
switch (x) {
case 5: case 6: case 10: case 11: return;
}
// Do whatever here.
}
}
...and back in the caller:
loop();
>The second doesn't work because 'break' now shadows its outer meaning.
>Both would otherwise be reasonable choices for this logic.
>
>Here's another example:
>
> for (i=0; i < N; ++i) {
> if (A[i] == 1)
> if (!f()) break;
> else if (A[i] == 2)
> if (!g()) break;
> else
> if (!h()) break;
> }
>
>Here, someone might notice that 'switch' suits this pattern better than
>an if-else chain. So they try this:
>
> for (i=0; i < N; ++i) {
> switch (A[i]) {
> case 1:
> if (!f()) break;
> case 2:
> if (!g()) break;
> default:
> if (!h()) break;
> }
> }
```
for (i = 0; i < N; i++) {
switch (A[i]) {
case 1: if (!f()) goto out;
case 2: if (!g()) goto out;
default: if (!h()) goto out;
}
}
out:
```
>This is valid C still, but it doesn't have the same behaviour.
Yes. I guess I fail to see the point of these, as what you are
trying to show seems obvious to me, and I strongly suspect it is
obvious to others, as well.
Are you suggesting that people are unaware of how `break`
interacts with `switch` inside of a loop? I don't think that is
true; I think people are well aware, but know how to work around
it and don't see it as a huge impediment; more of a mild
inconvenience.
Or are you suggesting that they are trying to defend the design
of the language in this regard? I similarly don't think that is
true; I have certainly been annoyed by this, and I suspect
others have as well. But again, people know how to work around
it.
C is not anyone's mother; I doubt anyone who is not a kook feels
like they need to rise to the defense of its honor when it is
criticized.
What I think some people are sort of mystified by is this idea
that this one thing is such a deal-breaker as to render the
language unuseable. That is certainly not true; whatever its
deficiencies, C has become fundamental to the working of the
modern world, and one avails oneself of considerable networking
effects if one uses it.
>Maybe, some compilers with certain options may point out something about
>fall-through, so you're aware something's amiss, but it doesn't get
>around the problem: you can't simply swap if-else chains with switch
>even when the latter is a better fit.
>
>This is a definite flaw in the language.
It _can be_ an _annoyance_ in the language, sure. Is it a,
"definite flaw"? That is subjective. You clearly feel that it
is. I couldn't say whether anyone else feels that way; I think
it's too minor to matter for most programmers.
>[snip]
>In my language and in my programs, breaking out of a loop from within a
>multi-way case/switch selection is a very, very common idiom which is
>denied to C users.
And yet, C is used successfully by millions of programmers
around the world, the results of which are used by billions of
users daily.
So is it flawed? By the designer's own account, yes. Is it
workable? Obviously.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 20:38 +0100 |
| Message-ID | <11ajcv8$3u33s$1@dont-email.me> |
| In reply to | #403045 |
On 12/10/2026 18:58, Dan Cross wrote:
> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>> This is valid C still, but it doesn't have the same behaviour.
>
> Yes. I guess I fail to see the point of these, as what you are
> trying to show seems obvious to me, and I strongly suspect it is
> obvious to others, as well.
>
> Are you suggesting that people are unaware of how `break`
> interacts with `switch` inside of a loop? I don't think that is
> true; I think people are well aware, but know how to work around
> it and don't see it as a huge impediment; more of a mild
> inconvenience.
>
> Or are you suggesting that they are trying to defend the design
> of the language in this regard?
That's what it seems like: obstinately trying to pretend it is not a
flaw, that it makes perfect sense, then you never want to do any of the
stuff where it causes problems anyway etc.
There are several issues discussed regarding switch:
* That its structure is totally chaotic (there /is/ no structure)
* That 'break' is needed to escape from the middle of that statement to
the end
* That that 'break' happens also to clash, needlessly, with loop-break
* And also with 'case' only doing one label at a time, instead of
being able to do, for example: 'case a, b, c:' or 'case x...y',
although some of this is taken care of via extensions.
There's quite a lot that could have been done much better!
> I similarly don't think that is
> true; I have certainly been annoyed by this, and I suspect
> others have as well. But again, people know how to work around
> it.
Yes, various workarounds are needed, such as the gotos in your examples.
But if we're going to use 'goto', then why bother with 'break' at all?
Presumably it is to make life easier.
> C is not anyone's mother; I doubt anyone who is not a kook feels
> like they need to rise to the defense of its honor when it is
> criticized.
Defending every shortcoming or quirk to the death seems common here. And
there will always be people to whom they are an invaluable feature (see
SL's recent post).
> What I think some people are sort of mystified by is this idea
> that this one thing is such a deal-breaker as to render the
> language unuseable.
In my case I would find it unusable for major projects if I had to code
manually. I'm just to spoilt for one, but always I'm a terrible typist
and C needs a LOT of fiddly typing.
>> Maybe, some compilers with certain options may point out something about
>> fall-through, so you're aware something's amiss, but it doesn't get
>> around the problem: you can't simply swap if-else chains with switch
>> even when the latter is a better fit.
>>
>> This is a definite flaw in the language.
>
> It _can be_ an _annoyance_ in the language, sure. Is it a,
> "definite flaw"? That is subjective. You clearly feel that it
> is. I couldn't say whether anyone else feels that way; I think
> it's too minor to matter for most programmers.
It's minor until it bites - see the example below.
>> [snip]
>> In my language and in my programs, breaking out of a loop from within a
>> multi-way case/switch selection is a very, very common idiom which is
>> denied to C users.
>
> And yet, C is used successfully by millions of programmers
> around the world, the results of which are used by billions of
> users daily.
This is my first example expressed in C (note those first three args are
passed by reference):
while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
switch (pmtype)
case pm_option: ...; break;
case pm_sourcefile:
if (passlevel == run_pass || passlevel == runpcl_pass) {
break;
Except I can't use break like that. So I have to find a workaround.
This is also 30% more tokens than my original, and that's before I fix
this problem.
So I'm sure C is perfectly usable, what we can't quantity easily is how
much extra effort is needed to get things done compared to a more
amenable syntax.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-12 19:52 +0000 |
| Message-ID | <GTazS.183760$ygUb.176068@fx23.iad> |
| In reply to | #403054 |
bart <bc@freeuk.com> writes:
>On 12/10/2026 18:58, Dan Cross wrote:
>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>This is my first example expressed in C (note those first three args are
>passed by reference):
>
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> switch (pmtype)
> case pm_option: ...; break;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break;
Aside from the incorrect syntax, it's really difficult to
determine your intent from this code fragment.
It's likely that folks here could provide more idiomatic
C if you described the problem you're attempting to solve
rather than providing an incomplete and incorrect code
fragment.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-12 22:56 +0200 |
| Message-ID | <11ajhhk$286mm$6@dont-email.me> |
| In reply to | #403057 |
On 2026-10-12 21:52, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/10/2026 18:58, Dan Cross wrote:
>>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>
>> This is my first example expressed in C (note those first three args are
>> passed by reference):
>>
>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>> switch (pmtype)
>> case pm_option: ...; break;
>> case pm_sourcefile:
>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>> break;
>
> Aside from the incorrect syntax, it's really difficult to
> determine your intent from this code fragment.
Well, to me it's clear what he meant by this code.
But it's unimportant since it doesn't add anything to what he has
repeated countless times; that in a loop()-switch() structure the
inner 'break' in the 'switch' would not leave the loop().
Such code exists in various forms, it's not something "strange".
It's also no problem that couldn't be addressed by other patterns.
(But he refuses to use them, or he's just blind to not see them.)
A loop()-specific 'break' would serve him (if he wants to abstain
from 'goto', or is refusing from doing just a slight code change).
(Maybe if he'd just hold his breath long enough something would
happen?)
>
> It's likely that folks here could provide more idiomatic
> C if you described the problem you're attempting to solve
> rather than providing an incomplete and incorrect code
> fragment.
I think it's sufficiently idiomatic. And I don't think that he could
provide anything where the answers would pass though the mental block
he obviously has. The thread was (by content) dead already very soon.
IMO it makes no sense to continue arguing with him.
Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 21:57 +0100 |
| Message-ID | <11ajhka$3vuli$1@dont-email.me> |
| In reply to | #403057 |
On 12/10/2026 20:52, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/10/2026 18:58, Dan Cross wrote:
>>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>
>> This is my first example expressed in C (note those first three args are
>> passed by reference):
>>
>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>> switch (pmtype)
>> case pm_option: ...; break;
>> case pm_sourcefile:
>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>> break;
>
> Aside from the incorrect syntax, it's really difficult to
> determine your intent from this code fragment.
Really? It's attempting to break out of the while-loop from inside that
switch statement. What we've been discussing at length.
But it won't work like this because in this context, that 'break' is
switch-break not loop-break.
> It's likely that folks here could provide more idiomatic
> C if you described the problem you're attempting to solve
> rather than providing an incomplete and incorrect code
> fragment.
I'd be interested in the idiomatic C that doesn't involve rewriting my
code or adding complexity in order to get around that silly clash.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-12 21:21 +0000 |
| Message-ID | <rbczS.252606$ITPb.1159@fx05.iad> |
| In reply to | #403060 |
bart <bc@freeuk.com> writes:
>On 12/10/2026 20:52, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/10/2026 18:58, Dan Cross wrote:
>>>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>
>>
>>> This is my first example expressed in C (note those first three args are
>>> passed by reference):
>>>
>>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>>> switch (pmtype)
>>> case pm_option: ...; break;
>>> case pm_sourcefile:
>>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>>> break;
>>
>> Aside from the incorrect syntax, it's really difficult to
>> determine your intent from this code fragment.
>
>Really? It's attempting to break out of the while-loop from inside that
>switch statement. What we've been discussing at length.
It's not clear from the context within the code fragment that
you intended the second break to terminate the while loop,
or for the first break to terminate the while loop (or
for neither to continue the switch).
>
>But it won't work like this because in this context, that 'break' is
>switch-break not loop-break.
Which break? There are two.
>
>
>> It's likely that folks here could provide more idiomatic
>> C if you described the problem you're attempting to solve
>> rather than providing an incomplete and incorrect code
>> fragment.
>
>I'd be interested in the idiomatic C that doesn't involve rewriting my
>code or adding complexity in order to get around that silly clash.
>
Describe the problem the code is intended to
address. Rather than a very small fragment
of code without any context. It appears to be parsing
a command line, something done quite frequently in C.
e.g.
/*
* Process the input parameters.
*/
while ((c = getopt(argc, argv, "al:t:L:e:vV")) != EOF) {
switch (c) {
case 'a':
level = c_mp::REV_A; // Select revision A behavior
break;
case 'l':
logfile = optarg;
break;
case 't':
tracefile = optarg;
break;
case 'L':
libpath = optarg;
break;
case 'e':
startupfile = optarg;
break;
case 'v':
verbose = true;
break;
case 'V':
lp->log("%s\n", vsim_built);
exit(EXIT_SUCCESS);
}
}
The remaining arguments in argv[] are are application dependent,
and don't need to be handled in the body of the switch or the
while loop. They can easily be handled in a subsequent loop
over the remaining arguments.
In any case, using goto to leave a switch statement nested
in a loop is certainly an idiomatic construct that is widely
used to leave the outer loop early. Another option is to declare
a local bool before the switch in the while loop, initialized to false.
Set it to true when you want to bail early:
while (condition)
bool bail = false;
switch (blah) {
case 1:
break;
case 2:
if (fred == name) bail = true;
break;
}
if (bail) break;
do_something();
}
Whether that is beautiful or ugly is a matter of opinion,
and you've made yours very clear.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 22:46 +0100 |
| Message-ID | <11ajkev$v8c$1@dont-email.me> |
| In reply to | #403063 |
On 12/10/2026 22:21, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/10/2026 20:52, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/10/2026 18:58, Dan Cross wrote:
>>>>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>>
>>>
>>>> This is my first example expressed in C (note those first three args are
>>>> passed by reference):
>>>>
>>>> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
>>>> switch (pmtype)
>>>> case pm_option: ...; break;
>>>> case pm_sourcefile:
>>>> if (passlevel == run_pass || passlevel == runpcl_pass) {
>>>> break;
>>>
>>> Aside from the incorrect syntax, it's really difficult to
>>> determine your intent from this code fragment.
>>
>> Really? It's attempting to break out of the while-loop from inside that
>> switch statement. What we've been discussing at length.
>
> It's not clear from the context within the code fragment that
> you intended the second break to terminate the while loop,
> or for the first break to terminate the while loop (or
> for neither to continue the switch).
>
>>
>> But it won't work like this because in this context, that 'break' is
>> switch-break not loop-break.
>
> Which break? There are two.
Oh, OK. The original didn't need switch-break, it only had loop-break.
I added switch-break for the C version; that is the first 'break' above.
But loop-break is also 'break'. So it is still wreaking confusion!
For the same reason too: the intent in each case is different.
>
>>
>>
>>> It's likely that folks here could provide more idiomatic
>>> C if you described the problem you're attempting to solve
>>> rather than providing an incomplete and incorrect code
>>> fragment.
>>
>> I'd be interested in the idiomatic C that doesn't involve rewriting my
>> code or adding complexity in order to get around that silly clash.
>>
>
> Describe the problem the code is intended to
> address. Rather than a very small fragment
> of code without any context. It appears to be parsing
> a command line, something done quite frequently in C.
(Yes. It is normally parsing '[options] file [options]', but when a
filename is seen and that file is to be run immediately, it needs to
stop parsing as those trailing options will be processed by the
application that is run.
Maybe I should have used the simpler example.)
> In any case, using goto to leave a switch statement nested
> in a loop is certainly an idiomatic construct that is widely
> used to leave the outer loop early. Another option is to declare
> a local bool before the switch in the while loop, initialized to false.
>
> Set it to true when you want to bail early:
>
> while (condition)
> bool bail = false;
> switch (blah) {
> case 1:
> break;
> case 2:
> if (fred == name) bail = true;
> break;
> }
> if (bail) break;
> do_something();
> }
>
> Whether that is beautiful or ugly is a matter of opinion,
> and you've made yours very clear.
Using my proposal, that would look like:
while (condition)
newswitch (blah) {
case 1: # this is an empty block
case 2: # this is separate
if (fred == name) break;
}
do_something();
}
No 'break' is routinely needed for the switch. 'break' here exits the loop.
Not that this was serious, but probably 'case' would need a new keyword
since the meaning of 'case 1: case 2:' is significantly different
between old and new switch contexts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-13 09:27 +0200 |
| Message-ID | <11akmgh$9uvd$1@dont-email.me> |
| In reply to | #403066 |
On 12/10/2026 23:46, bart wrote:
> On 12/10/2026 22:21, Scott Lurndal wrote:
>
>> In any case, using goto to leave a switch statement nested
>> in a loop is certainly an idiomatic construct that is widely
>> used to leave the outer loop early. Another option is to declare
>> a local bool before the switch in the while loop, initialized to false.
>>
>> Set it to true when you want to bail early:
>>
>> while (condition)
>> bool bail = false;
>> switch (blah) {
>> case 1:
>> break;
>> case 2:
>> if (fred == name) bail = true;
>> break;
>> }
>> if (bail) break;
>> do_something();
>> }
Alternatively :
bool looping = true;
while (looping && condition)
switch (blah) {
case 1:
break;
case 2:
if (fred == name) looping = false;
break;
}
do_something();
}
(The semantics for when "do_something()" is called is slightly different
here, but that depends on what something you want to do.)
Or you put your loop in a function - and then "return" breaks out of
everything. There are plenty of ways to structure the code.
Like every programming language, C provides some features and not
others. You use the features the language has in the way that gives the
best results for your code. There are /always/ going to be some
mismatches - features that you think are unnecessary, and things that
you think would be convenient if they existed. No two programmers are
going to agree on those mismatches, though they might have some overlap
of opinion.
Trying to invent a new special syntax just for one particular use-case
is absurd. It might make sense in a little private language, but not
for a mainstream programming language.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-13 12:18 +0200 |
| Message-ID | <11al0h6$4o6l$2@dont-email.me> |
| In reply to | #403082 |
On 2026-10-13 09:27, David Brown wrote: > [...] > > Trying to invent a new special syntax just for one particular use-case > is absurd. That's the point! > It might make sense in a little private language, but not > for a mainstream programming language. Such dubious designs might not even make sense in a "private language"; but no one would notice such a design decision, and that is the crucial (and positive) aspect of "private languages". Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 11:33 +0100 |
| Message-ID | <11al1eh$enb3$1@dont-email.me> |
| In reply to | #403082 |
On 13/10/2026 08:27, David Brown wrote:
> On 12/10/2026 23:46, bart wrote:
>> On 12/10/2026 22:21, Scott Lurndal wrote:
>>
>>> In any case, using goto to leave a switch statement nested
>>> in a loop is certainly an idiomatic construct that is widely
>>> used to leave the outer loop early. Another option is to declare
>>> a local bool before the switch in the while loop, initialized to false.
>>>
>>> Set it to true when you want to bail early:
>>>
>>> while (condition)
>>> bool bail = false;
>>> switch (blah) {
>>> case 1:
>>> break;
>>> case 2:
>>> if (fred == name) bail = true;
>>> break;
>>> }
>>> if (bail) break;
>>> do_something();
>>> }
>
> Alternatively :
>
> bool looping = true;
> while (looping && condition)
> switch (blah) {
> case 1:
> break;
> case 2:
> if (fred == name) looping = false;
> break;
> }
> do_something();
> }
>
> (The semantics for when "do_something()" is called is slightly different
> here, but that depends on what something you want to do.)
>
> Or you put your loop in a function - and then "return" breaks out of
> everything. There are plenty of ways to structure the code.
Sometimes you just want to write the simplest, more direct and most
intuitive code.
/Having/ to invent functions, and a special interface, to get around a
language issue is always a code smell.
> Like every programming language, C provides some features and not
> others. You use the features the language has in the way that gives the
> best results for your code. There are /always/ going to be some
> mismatches - features that you think are unnecessary, and things that
> you think would be convenient if they existed. No two programmers are
> going to agree on those mismatches, though they might have some overlap
> of opinion.
>
> Trying to invent a new special syntax just for one particular use-case
> is absurd. It might make sense in a little private language, but not
> for a mainstream programming language.
In my language (and others which don't have C's quirk) there is no
special syntax needed. You just write 'exit' or 'break', as the case may
be, oblivious to whether you are inside switch or not.
This is less 'cognitive load' than the calamity of having one extra
keyword, that C would have needed.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-13 00:25 +0300 |
| Message-ID | <20261013002531.000025b8@yahoo.com> |
| In reply to | #403060 |
On Mon, 12 Oct 2026 21:57:46 +0100
bart <bc@freeuk.com> wrote:
> On 12/10/2026 20:52, Scott Lurndal wrote:
> > bart <bc@freeuk.com> writes:
> >> On 12/10/2026 18:58, Dan Cross wrote:
> >>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com>
> >>> wrote:
> >>
> >
> >> This is my first example expressed in C (note those first three
> >> args are passed by reference):
> >>
> >> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> >> switch (pmtype)
> >> case pm_option: ...; break;
> >> case pm_sourcefile:
> >> if (passlevel == run_pass || passlevel ==
> >> runpcl_pass) { break;
> >
> > Aside from the incorrect syntax, it's really difficult to
> > determine your intent from this code fragment.
>
> Really? It's attempting to break out of the while-loop from inside
> that switch statement. What we've been discussing at length.
>
Thank you. You correctly identified the most common of the patterns
that triggered my response to Janis that started this particular
sub-thread.
The important part missing in your excerpt is that there are several
variables declared and initialized before loop and further processed
both within and after the loop.
> But it won't work like this because in this context, that 'break' is
> switch-break not loop-break.
>
>
> > It's likely that folks here could provide more idiomatic
> > C if you described the problem you're attempting to solve
> > rather than providing an incomplete and incorrect code
> > fragment.
>
> I'd be interested in the idiomatic C that doesn't involve rewriting
> my code or adding complexity in order to get around that silly clash.
>
As far as I am concerned, my most common workaround is goto. Others can
have other preferences.
It works well, but the need to invent the name of the label is a bit
annoying.
BTW, Ada/VHDL solution, with optional label before the loop also
suffers from this particular defect. Yes, it is more "structural" than
goto. It is considered important by many people, supposedly including
yourself. But on my personal ladder of preferences "structureness" by
itself is not particularly high as long as it does not bring another
benefits, like, for example, locality=reduced scope.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 22:20 +0000 |
| Message-ID | <11ajmfe$mfc$1@reader2.panix.com> |
| In reply to | #403054 |
In article <11ajcv8$3u33s$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 12/10/2026 18:58, Dan Cross wrote:
>> In article <11ainqf$3kkvd$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>>> This is valid C still, but it doesn't have the same behaviour.
>>
>> Yes. I guess I fail to see the point of these, as what you are
>> trying to show seems obvious to me, and I strongly suspect it is
>> obvious to others, as well.
>>
>> Are you suggesting that people are unaware of how `break`
>> interacts with `switch` inside of a loop? I don't think that is
>> true; I think people are well aware, but know how to work around
>> it and don't see it as a huge impediment; more of a mild
>> inconvenience.
>>
>> Or are you suggesting that they are trying to defend the design
>> of the language in this regard?
>
>That's what it seems like: obstinately trying to pretend it is not a
>flaw, that it makes perfect sense, then you never want to do any of the
>stuff where it causes problems anyway etc.
I think that may be your interpretation of what others are
saying, but that is not necessarily what they _are_ saying.
>There are several issues discussed regarding switch:
>
>* That its structure is totally chaotic (there /is/ no structure)
I think Keith said exactly that; it mixes structure and no
structure.
>* That 'break' is needed to escape from the middle of that statement to
> the end
I think the discussion is mostly you saying that this is
terrible, and others shrugging with their workarounds.
>* That that 'break' happens also to clash, needlessly, with loop-break
Yeah, I also think that's annoying.
>* And also with 'case' only doing one label at a time, instead of
> being able to do, for example: 'case a, b, c:' or 'case x...y',
> although some of this is taken care of via extensions.
That's also kind of irritating.
>There's quite a lot that could have been done much better!
I mean, yes. But as I said before, C is the language that it
is; I will acknowledge that it could have been better, but here
we are. Aside from that acknowledgement, what more is there to
actually do about it at this point?
>> I similarly don't think that is
>> true; I have certainly been annoyed by this, and I suspect
>> others have as well. But again, people know how to work around
>> it.
>
>Yes, various workarounds are needed, such as the gotos in your examples.
>But if we're going to use 'goto', then why bother with 'break' at all?
>
>Presumably it is to make life easier.
I don't know. I wasn't in the room when it was invented; its
immediate predecessor, BCPL, had no way to mark the end of a
`case` in a `switchon` at all (BCPL grew `ENDCASE` later),
though did have `valof` and `resultis` for obtaining the values
of _blocks_. So, one could write something like:
let howmany = valof switchon n into
$( case 0: resultis "zero"
case 1: resultis "one"
case 2: resultis "two"
default resultis "many"
$)
And so on; something one cannot do in C (but can in Rust).
Why did C bother with `break;` to end a `case` and not something
unique, like `ENDCASE` in later versions of BCPL?
I'm speculating, but I suspect it was because they wanted to
minimize the _need_ for `goto`; that unlike in BCPL blocks could
not return values; that `break` already existed to break out of a
loop and the control flow is not dissimilar conceptually; and
perhaps more importantly they were building a compiler intended
to run on a very, very small machine, shared by others, and ran
out of space to build something more elaborate. By the time
they had a bigger computer that could compile a better language,
the construct and its consequences were well understood and
there was a body of code that would have to change, and they did
not feel it was worth it.
At least, I imagine it was something like that.
>> C is not anyone's mother; I doubt anyone who is not a kook feels
>> like they need to rise to the defense of its honor when it is
>> criticized.
>
>Defending every shortcoming or quirk to the death seems common here. And
>there will always be people to whom they are an invaluable feature (see
>SL's recent post).
I don't think that anyone is doing that. I suspect it is the
opposite: others wonder why you latch onto every quirk or
shortcoming as evidence for your ultimately subjective opinion
that C is a bad language.
It is clear that you do not like C; you are not exactly hiding
it. But there is no C language politburo; no one will denounce
you for dreaming different dreams about the poor structure of
`switch`, and no one is going to challenge you to a duel over
your criticism of C.
But it is also clear that much of your dislike is opinion, based
on things that most others here just don't care about; the
pecularities of the `switch` statement are a good example. I
occasionally find it irritating, but 99% of the time I just
don't care; one learns to write `break` and one moves on with
one's life. Life is too short as it is to get worked up over
the `break` statement.
Others also point out that your criticism is often rooted in
misconceptions or misunderstandings of the language, and that is
fair: if you say something that is technically wrong about C as
evidence in support of your opinion about it, then you _should_
expect pushback. That's not anyone picking on you, it's them
holding you to a standard.
>> What I think some people are sort of mystified by is this idea
>> that this one thing is such a deal-breaker as to render the
>> language unuseable.
>
>In my case I would find it unusable for major projects if I had to code
>manually. I'm just to spoilt for one, but always I'm a terrible typist
>and C needs a LOT of fiddly typing.
Ok.
>>> Maybe, some compilers with certain options may point out something about
>>> fall-through, so you're aware something's amiss, but it doesn't get
>>> around the problem: you can't simply swap if-else chains with switch
>>> even when the latter is a better fit.
>>>
>>> This is a definite flaw in the language.
>>
>> It _can be_ an _annoyance_ in the language, sure. Is it a,
>> "definite flaw"? That is subjective. You clearly feel that it
>> is. I couldn't say whether anyone else feels that way; I think
>> it's too minor to matter for most programmers.
>
>It's minor until it bites - see the example below.
>
>[snip]
>This is my first example expressed in C (note those first three args are
>passed by reference):
>
> while (pmtype = nextcmdparam(¶mno, &name, &value, "m") {
> switch (pmtype)
> case pm_option: ...; break;
> case pm_sourcefile:
> if (passlevel == run_pass || passlevel == runpcl_pass) {
> break;
>
>Except I can't use break like that. So I have to find a workaround.
>
>This is also 30% more tokens than my original, and that's before I fix
>this problem.
The obvious syntax error aside, I'll wager that, to most C
programmers, this is still minor. I won't belabor the
workarounds as those are both well-known and have already been
discussed several times in this thread, alone. The only part
that bears mentioning here is that 99% of C programmers know
perfectly well how to deal with this and, frankly, just don't
find it that much of an imposition.
I think the impedence mismatch with what you're saying is that,
because it is so minor to so many people, it seems mystifying
that you think it's such a big deal.
>So I'm sure C is perfectly usable, what we can't quantity easily is how
>much extra effort is needed to get things done compared to a more
>amenable syntax.
That may be true. But I suspect that if you took a survey of,
say, 1000 C programmers, this would be unlikely to enter the top
10 complaints of more than a handful of them.
- Dan C.
[toc] | [prev] | [next] | [standalone]
Page 12 of 18 — ← Prev page 1 … 10 11 [12] 13 14 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web