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 262 — 20 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement 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 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-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 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| 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]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-13 20:52 +0000 |
| Message-ID | <11am5lk$53i$1@reader2.panix.com> |
| In reply to | #403111 |
In article <11alkqa$4o6l$3@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >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. Were you referring to me, Janis? Or to bart? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 22:24 +0100 |
| Message-ID | <11am7i3$u28q$1@dont-email.me> |
| In reply to | #403123 |
On 13/10/2026 21:52, Dan Cross wrote: > In article <11alkqa$4o6l$3@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> 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. > > Were you referring to me, Janis? Or to bart? If there's any insult implied then it will have been me.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-14 00:03 +0200 |
| Message-ID | <11am9r9$4o6m$4@dont-email.me> |
| In reply to | #403123 |
On 2026-10-13 22:52, Dan Cross wrote: > > Were you referring to me, Janis? Or to bart? You can identify the association of the answers by its attribution indent level. - Most was attributed to bart's text that was quoted. The only part that was attributed to what you said was this: Dan wrote: >> >> There is no programming that prevents all errors. I commented that, in parenthesis (i.e. just as a side remark): > > (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.) Bart perceived my program text as a "programming error", I explained that it was just a sloppy "Usenet-posting writing error". Of course programming errors can happen. As can writing errors happen. Given his text in your post gave the impression that he considers my sloppy code-writing in my post as a problem of the technical language design of "C"; it wasn't, IMO. - That was all I tried to communicate. While we seem to have a different view on whether the C-code is to be considered a "hack" (or as I see it, just typical programming) I didn't think that this difference in views is worth discussing since that's just (our personal) opinions. Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 11:16 +0100 |
| Message-ID | <11al0dn$ebog$1@dont-email.me> |
| In reply to | #403081 |
On 13/10/2026 08:23, Waldek Hebisch wrote: > Michael S <already5chosen@yahoo.com> wrote: >> 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. These are my stats across 3 of my non-C non-scripting apps, some 80Kloc (other apps share modules so would duplicate): Loops 997 Exit (1 level) 257 (ie. 'break' in C) Exit (All levels) 4 Exit (other) 0 Switch 814 (Looping switch 33 included also in Loops and Switch counts) Explicit return 1920 (Non-early returns are optional) So on average, 25% of all loops have early exits (your figures show about 4%). There's no analysis of whether they are inside switch or whatever, but observation yesterday suggested it was common. Switch is used so heavily (and there is Looping Switch which needs an explicit way to terminate!) then it's likely it is all mixed up. This is really the point - it shouldn't be necessary to care. The point has been made several times that loop-break clashing with switch-break is no different from a multi-level loop break (or even a multi-level switch break, whatever that even means). Well, it /is/ very different, and in my code-base, is infrequent. This is just playing down the consequences of the choices made in C. They are not serious, but they are not ideal, nor elegant, and involve workarounds that are a distraction. People should also be able to want to break out of enclosing loops from inside 'switch' without having to defend their choices!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-13 21:54 +0000 |
| Message-ID | <11am99u$ul56$2@dont-email.me> |
| In reply to | #403081 |
On Tue, 13 Oct 2026 07:23:40 -0000 (UTC), 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'. My experience in my own C code is quite the opposite. Lots of loops have exits in the middle, leading me to use forms like “for (;;)”. I also try to avoid putting “return” anywhere other than the end of a function, to make it easier to see the flow of control. *cough* Nassi-Shneiderman diagrams *cough*
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-13 07:40 -0700 |
| Message-ID | <86zewhhdep.fsf@linuxsc.com> |
| In reply to | #403053 |
Michael S <already5chosen@yahoo.com> writes: > 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. Let me clarify my earlier comment. I'm not surprised that people routinely use switch() inside of loops. What did surprise me is the statement that wanting to break out of the loop from inside the switch() is "very common". Not happens occasionally; not happens commonly or even just sufficiently commonly; not happens routinely; but "very common". I am wondering now how common it actually is, for switch() in general and for switch() inside of a loop. Is it one in a hundred? One in ten? One in two? More than that? I asked for an example because I am curious about what the proximate cause of such commonality might be. Is it a general style matter? Is it that you are used to certain patterns of local control flow? Is it that some use cases are more common in the kinds of programs you deal with? It would be good to get some data here, even just ad hoc data. In my own experience, wanting to escape multiple levels (including the case of provoking a loop exit from inside a switch()) doesn't happen often enough to merit considering a language change. But I would like to know more about the experiences of other people. I'm reminded of a quote from (if memory serves) Tony Hoare, about language design. Paraphrasing: A programming language should not reflect the union of all the features proposed by its designers; rather it should reflect the union of the designers' prejudices about what features should NOT be put into the language.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 16:46 +0100 |
| Message-ID | <11aljoo$m15u$1@dont-email.me> |
| In reply to | #403105 |
On 13/10/2026 15:40, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> 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.
>
> Let me clarify my earlier comment. I'm not surprised that people
> routinely use switch() inside of loops. What did surprise me is the
> statement that wanting to break out of the loop from inside the
> switch() is "very common". Not happens occasionally; not happens
> commonly or even just sufficiently commonly; not happens routinely;
> but "very common". I am wondering now how common it actually is,
> for switch() in general
For switch in general is not meaningful: since this is about breaking
out of a loop: a loop needs to be involved!
> and for switch() inside of a loop. Is it
> one in a hundred? One in ten? One in two? More than that?
These are some stats for 5 of my non-C projects:
All All Of which,
Project Loops Breaks Breaks inside Switch
A 538 131 72
B 438 103 62
C 412 132 58
D 216 57 34
E 47 20 7
These are averages. It is conceivable all those 72 breaks on the first
line are within one Switch statement, but it is unlikely.
I can't do the same exercise for C examples, since that language doesn't
allow breaks inside 'switch'. (All breaks I'm talking about are
loop-breaks.)
Not sure what percentages you are after: how many loops have at least
one break within switch? That might be around 1 in 7 (14%).
What proportion of all breaks are inside switch? That would be about half.
> I asked for an example because I am curious about what the proximate
> cause of such commonality might be. Is it a general style matter?
Since this is something C doesn't directly support, getting stats is
tricky. People will use workarounds and you'd have to analyse those to
try and infer what they're trying to achieve. (Humans have to do the
same exercise; that is the problem.)
My view is that using distinct keywords for loop-break and switch-break
(accepting that the language wants the latter) would have had pretty
much zero costs, but worthwhile benefits.
> In my own experience, wanting to escape multiple levels (including
> the case of provoking a loop exit from inside a switch())
No it doesn't, but this is not about that; here we just want to break
out of one loop level!
> I'm reminded of a quote from (if memory serves) Tony Hoare, about
> language design. Paraphrasing: A programming language should not
> reflect the union of all the features proposed by its designers;
> rather it should reflect the union of the designers' prejudices
> about what features should NOT be put into the language.
Perhaps C could have done without switch-break then.
A very rough survey suggests that about 1% of lines of code in a project
are purely switch-breaks. How many billions of lines of C are there...?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-13 09:10 -0700 |
| Message-ID | <86qzhth98c.fsf@linuxsc.com> |
| In reply to | #403109 |
bart <bc@freeuk.com> writes: > On 13/10/2026 15:40, Tim Rentsch wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> > > >>> 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. >> >> Let me clarify my earlier comment. I'm not surprised that people >> routinely use switch() inside of loops. What did surprise me is the >> statement that wanting to break out of the loop from inside the >> switch() is "very common". Not happens occasionally; not happens >> commonly or even just sufficiently commonly; not happens routinely; >> but "very common". I am wondering now how common it actually is, >> for switch() in general > > For switch in general is not meaningful: since this is about breaking > out of a loop: a loop needs to be involved! Please don't make the mistake of thinking the question I am asking is the same as the question you are interested in answering.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-13 18:15 +0100 |
| Message-ID | <11alovc$o7ef$1@dont-email.me> |
| In reply to | #403112 |
On 13/10/2026 17:10, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> On 13/10/2026 15:40, Tim Rentsch wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >> >> >>>> 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. >>> >>> Let me clarify my earlier comment. I'm not surprised that people >>> routinely use switch() inside of loops. What did surprise me is the >>> statement that wanting to break out of the loop from inside the >>> switch() is "very common". Not happens occasionally; not happens >>> commonly or even just sufficiently commonly; not happens routinely; >>> but "very common". I am wondering now how common it actually is, >>> for switch() in general >> >> For switch in general is not meaningful: since this is about breaking >> out of a loop: a loop needs to be involved! > > Please don't make the mistake of thinking the question I am > asking is the same as the question you are interested in > answering. This is what you said: > What did surprise me is the > statement that wanting to break out of the loop from inside the > switch() is "very common". So you're talking about breaking out of a loop from inside switch? > Not happens occasionally; not happens > commonly or even just sufficiently commonly; not happens routinely; > but "very common". > I am wondering now how common it actually is, 'it' is still breaking out a loop from inside switch? > for switch() in general > and for switch() inside of a loop. So if this covers 'breaking out of a loop from inside switch', then what on earth is meant by: > for switch() in general ? Please enlighten us.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 18:27 -0700 |
| Message-ID | <11amlq9$12efg$1@kst.eternal-september.org> |
| In reply to | #403109 |
bart <bc@freeuk.com> writes:
[...]
> My view is that using distinct keywords for loop-break and
> switch-break (accepting that the language wants the latter) would have
> had pretty much zero costs, but worthwhile benefits.
I agree, and I don't think that's particularly controversial.
The point on which we disagree is what can and should be done about
it now.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-10-14 01:50 +0000 |
| Message-ID | <11amn48$7ell$1@news.xmission.com> |
| In reply to | #403135 |
In article <11amlq9$12efg$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >bart <bc@freeuk.com> writes: >[...] >> My view is that using distinct keywords for loop-break and >> switch-break (accepting that the language wants the latter) would have >> had pretty much zero costs, but worthwhile benefits. > >I agree, and I don't think that's particularly controversial. > >The point on which we disagree is what can and should be done about >it now. The answer to that is: Invent new languages with C-like syntax, but better. You can't do anything about C, but you can do better as long as you call the result something else. Like C#. Like C++. Like Swift. -- People seem to think that Youtube (and Facebook and Twitter and so on) is (are) some sort of resource created for the public good. Why they delude themselves into believing this is beyond my ability to comprehend. Usenet will always be here. Longer than people remember what port 80 was for.
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web