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 11 of 18 — ← Prev page 1 … 9 10 [11] 12 13 … 18 Next page →
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-16 15:24 +0000 |
| Message-ID | <11atfif$38b7p$1@paganini.bofh.team> |
| In reply to | #403128 |
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> 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.
Well, usually there is a lot of loops. Those with exit in the
middle are still significant.
Concernig 'return', having it in place where all work inside function
is done help me to see flow control and avoids complications. In
case of search functions it means return from the middle of the loop.
IMO possible alternatives like flag variables or break and retrun
after loop are worse.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-16 21:42 +0000 |
| Message-ID | <11au5ob$3m5co$2@dont-email.me> |
| In reply to | #403215 |
On Fri, 16 Oct 2026 15:24:01 -0000 (UTC), Waldek Hebisch wrote: > Concernig 'return', having it in place where all work inside > function is done help me to see flow control and avoids > complications. In case of search functions it means return from the > middle of the loop. IMO possible alternatives like flag variables or > break and retrun after loop are worse. Code tends to do a lot of dynamic resource allocation these days, and that requires cleanup. Doing a direct “return” from the middle of a function body doesn’t allow for that. Unless you use a GCC extension like “defer”, I suppose.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-16 21:46 +0000 |
| Message-ID | <OWwAS.61663$R0u.10250@fx07.iad> |
| In reply to | #403222 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
>On Fri, 16 Oct 2026 15:24:01 -0000 (UTC), Waldek Hebisch wrote:
>
>> Concernig 'return', having it in place where all work inside
>> function is done help me to see flow control and avoids
>> complications. In case of search functions it means return from the
>> middle of the loop. IMO possible alternatives like flag variables or
>> break and retrun after loop are worse.
>
>Code tends to do a lot of dynamic resource allocation these days, and
>that requires cleanup. Doing a direct “return” from the middle of a
>function body doesn’t allow for that.
>
>Unless you use a GCC extension like “defer”, I suppose.
Better to use the cleanup attribute (or RAII in C++).
#define RAII_CHM __attribute__((cleanup(auto_free_ptr)))
#define RAII_FILE __attribute__((cleanup(auto_close_file)))
int main(void) {
// Memory and file handles are bound to this block scope
RAII_CHM char *buffer = malloc(100);
RAII_FILE FILE *fp = fopen("example.txt", "w");
if (!buffer || !fp) {
return -1; // Even on early exit, validly opened resources are cleaned up!
}
fprintf(fp, "Hello, RAII in C!");
return 0; // Both buffer and fp are automatically freed/closed here
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 12:38 +0200 |
| Message-ID | <11b27js$121v2$1@dont-email.me> |
| In reply to | #403223 |
On 16/10/2026 23:46, Scott Lurndal wrote:
> Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
>> On Fri, 16 Oct 2026 15:24:01 -0000 (UTC), Waldek Hebisch wrote:
>>
>>> Concernig 'return', having it in place where all work inside
>>> function is done help me to see flow control and avoids
>>> complications. In case of search functions it means return from the
>>> middle of the loop. IMO possible alternatives like flag variables or
>>> break and retrun after loop are worse.
>>
>> Code tends to do a lot of dynamic resource allocation these days, and
>> that requires cleanup. Doing a direct “return” from the middle of a
>> function body doesn’t allow for that.
>>
>> Unless you use a GCC extension like “defer”, I suppose.
"defer" is not a gcc extension. You can "defer" macro, using gcc's
"cleanup" attribute (which /is/ an extension) :
<https://gustedt.gitlabpages.inria.fr/defer/>
As I understand it, "defer" is in the proposal stage and could make it
into C2y, but it is not yet in the draft standard. There are test
implementations in gcc, clang, and a couple of other compilers.
>
> Better to use the cleanup attribute (or RAII in C++).
>
> #define RAII_CHM __attribute__((cleanup(auto_free_ptr)))
> #define RAII_FILE __attribute__((cleanup(auto_close_file)))
>
> int main(void) {
> // Memory and file handles are bound to this block scope
> RAII_CHM char *buffer = malloc(100);
> RAII_FILE FILE *fp = fopen("example.txt", "w");
>
> if (!buffer || !fp) {
> return -1; // Even on early exit, validly opened resources are cleaned up!
> }
>
> fprintf(fp, "Hello, RAII in C!");
>
> return 0; // Both buffer and fp are automatically freed/closed here
> }
"defer" has a number of benefits over "cleanup", but "cleanup" has the
advantage that it is available now on gcc and clang - if portability is
not an issue.
Still, I would not write code like you show above - in C, people expect
more explicit code, and you are hiding non-standard C behaviour with
somewhat obscure names. (Obscurity is, of course, dependent on how much
you use the feature in your code.)
I'd rather have :
#define RAII(cleanup_func) __attribute__((cleanup(cleanup_func)))
RAII(auto_free_ptr) char * buffer = malloc(100);
RAII(auto_close_file) FILE * fp = fopen("example.txt", "w");
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-16 15:03 -0700 |
| Message-ID | <11au6v8$3mdne$2@kst.eternal-september.org> |
| In reply to | #403222 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
[...]
> Unless you use a GCC extension like “defer”, I suppose.
There is a proposal to add "defer" (or rather "_Defer") to C,
though it doesn't appear in the latest C2y draft.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3928.pdf
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-17 19:25 -0700 |
| Message-ID | <8633u3pwwd.fsf@linuxsc.com> |
| In reply to | #403215 |
antispam@fricas.org (Waldek Hebisch) writes: > Lawrence D?Oliveiro <ldo@nz.invalid> wrote: > >> 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. > > Well, usually there is a lot of loops. Those with exit in the > middle are still significant. > > Concernig 'return', having it in place where all work inside function > is done help me to see flow control and avoids complications. In > case of search functions it means return from the middle of the loop. > IMO possible alternatives like flag variables or break and retrun > after loop are worse. I rarely use 'break' to exit a loop. Part of this is that I try to write standard loops so that they complete as part of the loop test (i.e., in while() or for() control expressions). That isn't the whole story though so let me talk about 'return'. Most of the functions I write have exactly one return, at the end of the function. I estimate this pattern accounts for around 85% of all functions, let's say plus or minus 5%. Sometimes functions have early returns for errors or exceptional conditions. Early returns are easily seen to lie outside the main body of function processing so they don't interfere with understanding what the rest of the function is doing or how it works. A fairly common sub-pattern are functions most of whose body is a switch() statement, with all of the switch() cases being a simple return. It does sometimes happen that a function will have a loop with a return in the middle, and also a return at the end for what to do if the loop terminates. To me having an in-loop return looks better than using an assignment and a break. A fairly rare but important pattern is what I might call vectoring or decomposition. Here the function body serves to distinguish and separate out different regimes of subprocessing. To continue processing in a particular regime, a return is used not to directly yield a value but rather to call a further function to handle that sub-domain. The benefit here is both to keep function bodies small and to allow re-use of commonly called sub-functions. Two aspects are important for having these different styles work together. One is that it's easy to distinguish the different kinds of patterns, and by far the most simple pattern is the most common. The other is to be sure to keep function bodies small. Keeping function bodies small goes a long way in making them easy to understand, which obviously is a key property in writing good code. Also keeping function bodies small effectively prevents mixing different styles in a single function, serving to reinforce point one.
[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]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 10:58 +0000 |
| Message-ID | <11ann95$4sj$1@reader2.panix.com> |
| In reply to | #403138 |
In article <11amn48$7ell$1@news.xmission.com>, Kenny McCormack <gazelle@shell.xmission.com> wrote: >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. I mean...we've got a ton of those now. Go, Rust, Zig, Switch, and on and on. We don't really need to invent new languages. OCaml, Haskell, Julia, ad infinitum. In my view, the bigger impediments to moving off of C as the dominant systems programming language are two fold: 1. providing a clean path from C to the new language(s), and 2. overcoming the enormous inertia of decades of defaulting to C for systems programs. I love C, but I'm not in love with C anymore, and if I am starting a new project these days, it's not the first thing I reach for anymore. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-13 22:54 +0300 |
| Message-ID | <20261013225449.00005562@yahoo.com> |
| In reply to | #403105 |
On Tue, 13 Oct 2026 07:40:30 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > 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? > Of course, I never gathered exact statistics. My guts feeling is that among switches nested within loop it could be as high as one out of five. Not one out of five case labels, but one out of five switch statements. > 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? bart gave decent example. My own use cases are mostly related to processing of incoming network messages that are distinguished by opcode at the beginning of the message. But not just that. Generally, I like small functions that return specialized enum as result code. When such functions used within loop, it often leads to pattern in question. > 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. Sorry, right now I have no time for doing such analysis. It is not trivial exactly because 'C' has no such feature. So I don't know how to automate a search within codebases. > > 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. In this particular case Ritchie did not have to innovate in order to create this feature. Quite opposite, as others (Keith ?) mentioned, he had to innovate in order to merge distinct break-loop and break-switch features of ancestor language into unified break.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-13 16:45 -0700 |
| Message-ID | <86mrshgo73.fsf@linuxsc.com> |
| In reply to | #403119 |
Michael S <already5chosen@yahoo.com> writes: > On Tue, 13 Oct 2026 07:40:30 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> 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? > > Of course, I never gathered exact statistics. > My guts feeling is that among switches nested within loop it could be as > high as one out of five. Not one out of five case labels, but one out of > five switch statements. Gut feelings are fine. Thank you. >> 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? > > My own use cases are mostly related to processing of incoming network > messages that are distinguished by opcode at the beginning of the > message. Okay. Does this mean the loop exit indicates the end of the last packet so the last packet can be processed (and start another one presumably)? Or am I misunderstanding you? > But not just that. Generally, I like small functions that return > specialized enum as result code. When such functions used within > loop, it often leads to pattern in question. I expect this pattern leads to using switch() more often. So that could account for part of it. >> 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. > > Sorry, right now I have no time for doing such analysis. It is not > trivial exactly because 'C' has no such feature. So I don't know how > to automate a search within codebases. An approximate measure is how often 'goto' is used inside a switch() body. That would be interesting to know in any case. Whether it would be easy to do that heuristically probably depends on what code base is being processed. >> 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. > > In this particular case Ritchie did not have to innovate in order to > create this feature. Quite opposite, as others (Keith ?) mentioned, > he had to innovate in order to merge distinct break-loop and > break-switch features of ancestor language into unified break. Sorry, it seems my comment led you astray. I was talking about something else. In any case Ritchie was operating under very different circumstances, including in particular more severe memory constraints. At the time adding another keyword to the language may have seemed like an extravagance.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-13 18:34 -0700 |
| Message-ID | <11amm6k$12efg$2@kst.eternal-september.org> |
| In reply to | #403119 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> In this particular case Ritchie did not have to innovate in order to
> create this feature. Quite opposite, as others (Keith ?) mentioned, he
> had to innovate in order to merge distinct break-loop and break-switch
> features of ancestor language into unified break.
As Dan Cross pointed out, I didn't quite get this right. At the time
C was invented, BCPL didn't have ENDCASE. BCPL continued to evolve
independently after B and C were derived from it.
This information is from Ritchie's HOPL (History or Programming
Languages) paper, available at
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html
Not every difference between the BCPL language documented in
Richards's book [Richards 79] and B was deliberate; we started
from an earlier version of BCPL [Richards 67]. For example,
the endcase that escapes from a BCPL switchon statement was
not present in the language when we learned it in the 1960s,
and so the overloading of the break keyword to escape from the
B and C switch statement owes to divergent evolution rather
than conscious change.
--
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 | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-14 05:17 +0000 |
| Message-ID | <20261013221123.363@kylheku.com> |
| In reply to | #403119 |
On 2026-10-13, Michael S <already5chosen@yahoo.com> wrote:
> Of course, I never gathered exact statistics.
> My guts feeling is that among switches nested within loop it could be as
> high as one out of five. Not one out of five case labels, but one out of
> five switch statements.
Switches inside a loop are natural whenever a state machine is being
simulated which has acceptance/failulre states which indicate that the
simulation should end.
Switches inside a loop are also natural whenever a stream of
integer-tagged cases is being handled where a terminating sentinel is
also labeled.
There are at least two workarounds for writing this which avoid
duplicated testing or loop termination flags, gotos or such.
One is to make the loop the last statement of a function and use
"return" in the loop-terminating cases.
The other is to put a "break" at the bottom of the loop and
terminate all the loop-continuing cases with "continue",
the terminating cases with "break":
for (;;) {
int ch = getc(in);
switch (ch) {
case '\n':
lines++;
/* fallthrough */
default:
continue;
case EOF:
break;
}
break;
}
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 13:46 +0100 |
| Message-ID | <11antja$1fsul$1@dont-email.me> |
| In reply to | #403144 |
On 14/10/2026 06:17, Kaz Kylheku wrote:
> On 2026-10-13, Michael S <already5chosen@yahoo.com> wrote:
>> Of course, I never gathered exact statistics.
>> My guts feeling is that among switches nested within loop it could be as
>> high as one out of five. Not one out of five case labels, but one out of
>> five switch statements.
>
> Switches inside a loop are natural whenever a state machine is being
> simulated which has acceptance/failulre states which indicate that the
> simulation should end.
>
> Switches inside a loop are also natural whenever a stream of
> integer-tagged cases is being handled where a terminating sentinel is
> also labeled.
>
> There are at least two workarounds for writing this which avoid
> duplicated testing or loop termination flags, gotos or such.
>
> One is to make the loop the last statement of a function and use
> "return" in the loop-terminating cases.
>
> The other is to put a "break" at the bottom of the loop and
> terminate all the loop-continuing cases with "continue",
> the terminating cases with "break":
>
> for (;;) {
> int ch = getc(in);
> switch (ch) {
> case '\n':
> lines++;
> /* fallthrough */
> default:
> continue;
> case EOF:
> break;
> }
> break;
> }
>
Well, it's a novel workaround, but it is still a workaround if the logic
could have been more naturally expressed like this:
for (;;) {
switch (ch = getch()) { // I assume ch needed for other cases
case '\n':
lines++;
break;
case EOF:
BREAK;
}
}
BREAK represents loop exit. The point is to avoid having to restructure
your code just to get around a silly shortcoming. In practice, using
'goto' is the simplest workaround.
(This a pattern that is common enough for me to have a special syntax
for in my projects. Then it is expressed as:)
doswitch ch := getch(in)
when '\n' then
++lines
when EOF then
exit
end
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 07:05 +0200 |
| Message-ID | <11ahpqi$38ir0$2@dont-email.me> |
| In reply to | #402992 |
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. Other people may choose to intermingle switches and loops, and may then have issues as a result, but I have not seen this in real code. > That that happens and needs a workaround, is not satisfactory. The issue > exists 100% because of sharing the 'break' keyword for two different > purposes. > First, there is no indication that conflicts between switch and loop "break" occurs in real code, or what the nature of such issues are. (Michael's brief comments are not enough information.) Secondly, there is no indication that this "needs a workaround" - especially as there is no definition of what might be called a "workaround". Usually you use the term to mean C code that you want to complain about. Thirdly, the keyword "break" is not being used for two different purposes - it is being used for the same purpose in two different control structures. It is well established that there are occasions where you have nested control structures, where it would be useful to be able to break out of an outer structure. In C, "break" by itself does not handle such cases, and thus additional code is needed (what you call a "workaround", and other people call "writing code") - something people have managed to do for decades. It is well established that at least some programmers would find it convenient to have some kind of multi-level or labelled "break" to let such cases be handled in a neater way, and there are proposals to add such a feature to C. This is a general situation with nested control structures, and not in any way specific to switches or mixes of switches and loops - almost certainly, nested loops are the primary use-case.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-12 14:37 +0100 |
| Message-ID | <11ainqf$3kkvd$1@dont-email.me> |
| In reply to | #403025 |
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!
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; // ??
}
}
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.
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.
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.
>> That that happens and needs a workaround, is not satisfactory. The
>> issue exists 100% because of sharing the 'break' keyword for two
>> different purposes.
>>
> First, there is no indication that conflicts between switch and loop
> "break" occurs in real code, or what the nature of such issues are.
As I said, they CAN'T occur in finished code, since some other approach
has had to be used. You won't know if the conflicts have occurred!
> (Michael's brief comments are not enough information.) Secondly, there
> is no indication that this "needs a workaround" - especially as there is
> no definition of what might be called a "workaround". Usually you use
> the term to mean C code that you want to complain about. Thirdly, the
> keyword "break" is not being used for two different purposes - it is
> being used for the same purpose in two different control structures.
One is for loops to stop iteration, it is optional, and tends to be used
sparingly.
The other is for switch, it is nearly always necessary for the common
pattern of switch, and is needed because otherwise the language leaves
you stranded in the middle of a switch statement. There is no iteration
involved.
Does that sound about the same?
> It is well established that there are occasions where you have nested
> control structures, where it would be useful to be able to break out of
> an outer structure. In C, "break" by itself does not handle such cases,
> and thus additional code is needed (what you call a "workaround", and
> other people call "writing code")
People keep bringing this up. Yes, that's an annoyance too, but it is
genuinely rare.
BTW I looked at the sources for one of my projects (in my language) to
see whether breaking a loop from switch ever occurred. I found it the
very first instance! Then I kept finding more.
This is the outline of the first example:
while pmtype := nextcmdparam(paramno, name, value, "m") do
case pmtype
when pm_option then
when pm_sourcefile then
if passlevel in [run_pass, runpcl_pass] then
exit
'case' is a sister statement to 'switch' and has the same syntax. It's
used for more general cases usually with a small number of branches.
My 'break' statement is called 'exit'. Number two:
do
lex() !first symbol on line
case lx.symbol
when eofsym then
when kendsym then
exit
There are loads more. This next is an example of breaking out of two
loop levels:
while wt do
while w do
if ... then
exit all
It is nearly always all the loops, so I simply write 'all' (an alias for
0 which denotes the outermost loop without needing to count). There are
two such 'exit all' in this 35Kloc project; all other exits are for one
level only.
Here's one more loop/switch example, but with a twist:
docase flags^
when 'S' then
when 'U' then
else
exit
end
'docase' and 'doswitch' are looping forms, which are very common in my
programs. This one is the equivalent of this in C:
while (1) {
switch (*flags) {
case 'S': ...
case 'U': ...
default:
.... // NOW WHAT?
}
}
You can't express it. Sure you can get around it, but that is just
pandering to the issue, and it means you can't use what might be the
most natural and clearest way to do it.
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.
[toc] | [prev] | [next] | [standalone]
Page 11 of 18 — ← Prev page 1 … 9 10 [11] 12 13 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web