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 399 — 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 David Brown <david.brown@hesbynett.no> - 2026-10-19 11:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 03:50 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:59 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:28 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 14:35 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 18:31 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:34 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:18 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-18 23:51 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:56 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 19:37 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 23:56 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:15 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:33 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-19 08:47 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 18:28 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 16:11 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 19:39 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 18:23 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:36 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 21:03 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 10:30 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-17 10:54 -0700
Re: Taming The Switch-Statement 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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 17:22 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 20:34 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 00:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 13:22 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 14:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 17:09 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:09 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 23:20 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:26 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 15:46 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 22:28 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 08:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 15:00 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-19 16:55 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:24 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:58 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:26 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 18:11 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 19:32 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:44 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-19 22:35 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:29 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 00:57 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:55 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-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 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-19 14:35 +0000 |
| Message-ID | <11b59qq$7hk$1@reader2.panix.com> |
| In reply to | #403312 |
In article <11b4smj$1vt4q$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >The odd scoping rules for labels don't bother me either. They mean >you can't have two loops or switch statements with the same name in >the same function. I can barely imagine that being inconvenient. An issue is that one might generate such a named loop with a macro. I can imagine that being useful for `XIMPL` type constructs, but C's macros are unusually weak, and C doesn't have something like `(GENSYM)` in Lisp, so you've got to plumb the loop name through the macro invocation: mildly annoying, but not too bad. Then again, if a programmer is abusing macros like that to generate named loops multiple times in the same function, then perhaps the program needs a re-think, ximpl or no. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-19 18:31 +0200 |
| Message-ID | <11b5gl6$27la0$1@dont-email.me> |
| In reply to | #403324 |
On 19/10/2026 16:35, Dan Cross wrote: > In article <11b4smj$1vt4q$1@kst.eternal-september.org>, > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> The odd scoping rules for labels don't bother me either. They mean >> you can't have two loops or switch statements with the same name in >> the same function. I can barely imagine that being inconvenient. > > An issue is that one might generate such a named loop with a > macro. I can imagine that being useful for `XIMPL` type > constructs, but C's macros are unusually weak, and C doesn't > have something like `(GENSYM)` in Lisp, so you've got to plumb > the loop name through the macro invocation: mildly annoying, but > not too bad. Hopefully the N3658 fix for that will be in C2y. <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3658.htm> That will also let people - for better or worse - write things like: #define For Loop_label: for #define While Loop_label: while #define Switch Switch_label #define Break_Loop break Loop_label #define Break_Switch break Switch_label > > Then again, if a programmer is abusing macros like that to > generate named loops multiple times in the same function, > then perhaps the program needs a re-think, ximpl or no. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-18 18:34 -0700 |
| Message-ID | <11b3s3a$1lao8$2@kst.eternal-september.org> |
| In reply to | #403279 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> All I wanted to say is that I prefer label to be located at where the
> break goes. Or near this point. Within frame of current C syntax, I
> don't see how to achieve it, except for do-while. But it does not
> change the fact that I find it desirable.
There is a way to achieve it: "goto".
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 17:49 +0200 |
| Message-ID | <11b2pq5$3pvda$7@dont-email.me> |
| In reply to | #403270 |
On 2026-10-18 16:13, Michael S wrote:
> On Sun, 18 Oct 2026 14:34:28 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-10-18 14:09, David Brown wrote:
>>>
>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>>> rather than "do NAME { } while ( )". )
>>
>> Oh! - I can only think that it would then be (sort of) "consistent"
>> with the place of the label attacked in a 'while' loop; i.e. behind
>> the 'while' keyword. - It's inconsistent in another interpretation,
>> though; and I'd certainly have favored the latter form, to have the
>> label consistently attached at the loop-entry keyword.
>
> I'd prefer label consistently attached to the loop-exit keyword.
I can see that this might look appealing in case of 'break'. In
case of the same mechanism working also for 'continue' I'd then
think that it should generally better be an "attribute" of the
loop entry keyword, i.e. placed where loops start. (But that's
just my opinion.) Having it at a different place with a do-loop
I consider a really bad decision. It's advantageous to know the
direction in which to seek for the label if you inspect code. -
But okay, it's "C"; I won't heat up about some future C-release
that I'll never use (especially given that I'm not even be using
all of those more recent additions that are already available).
> Unfortunately, for() and while() loops have no such keyword.
Or fortunately. ;-)
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-18 22:18 +0000 |
| Message-ID | <11b3gkj$mt2$1@reader2.panix.com> |
| In reply to | #403281 |
In article <11b2pq5$3pvda$7@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-10-18 16:13, Michael S wrote:
>> On Sun, 18 Oct 2026 14:34:28 +0200
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 2026-10-18 14:09, David Brown wrote:
>>>>
>>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>>>> rather than "do NAME { } while ( )". )
>>>
>>> Oh! - I can only think that it would then be (sort of) "consistent"
>>> with the place of the label attacked in a 'while' loop; i.e. behind
>>> the 'while' keyword. - It's inconsistent in another interpretation,
>>> though; and I'd certainly have favored the latter form, to have the
>>> label consistently attached at the loop-entry keyword.
>>
>> I'd prefer label consistently attached to the loop-exit keyword.
>
>I can see that this might look appealing in case of 'break'. In
>case of the same mechanism working also for 'continue' I'd then
>think that it should generally better be an "attribute" of the
>loop entry keyword, i.e. placed where loops start. (But that's
>just my opinion.) Having it at a different place with a do-loop
>I consider a really bad decision. It's advantageous to know the
>direction in which to seek for the label if you inspect code. -
>But okay, it's "C"; I won't heat up about some future C-release
>that I'll never use (especially given that I'm not even be using
>all of those more recent additions that are already available).
I think colocating it with `do` might create a syntactic
ambiguity. In the case of `for`, `while`, and `select`, there
is a required token following the keyword (the `(`). However,
for a `do`/`while` loop, `do` is followed immediately by a,
`secondary-block` production. In particular, you do not _need_
braces to denote a compound statement after `do`; something like
`do i++; while (i < j);` is perfectly legal in C.
In the N3377 proposal, the new `block-name` is just an
identifier. If it were allowed immediately after the `do`, then
given, `do NAME statement; while(condition);` you can't tell
`NAME` from the name of the loop and a random identifier before
a statement; something like `do LOOP i++; while (i < j);`
appears as though it _would_ be be syntactically valid by N3377
as presently worked, but is the programmer's intent to create a
loop name, or should this just be a syntax error?
By requiring the block-name between a keyword and a
syntactically required `(`, you remove that ambiguity: if there
is an identifier there, then it is a `block-name`; if not, then
the block has no name.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-18 23:51 +0000 |
| Message-ID | <11b3m1r$3tp6p$1@paganini.bofh.team> |
| In reply to | #403295 |
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <11b2pq5$3pvda$7@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-10-18 16:13, Michael S wrote:
>>> On Sun, 18 Oct 2026 14:34:28 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>> On 2026-10-18 14:09, David Brown wrote:
>>>>>
>>>>> [...]Â (I don't know why N3377 proposed "do { } while NAME ( )"
>>>>> rather than "do NAME { } while ( )". )
>>>>
>>>> Oh! - I can only think that it would then be (sort of) "consistent"
>>>> with the place of the label attacked in a 'while' loop; i.e. behind
>>>> the 'while' keyword. - It's inconsistent in another interpretation,
>>>> though; and I'd certainly have favored the latter form, to have the
>>>> label consistently attached at the loop-entry keyword.
>>>
>>> I'd prefer label consistently attached to the loop-exit keyword.
>>
>>I can see that this might look appealing in case of 'break'. In
>>case of the same mechanism working also for 'continue' I'd then
>>think that it should generally better be an "attribute" of the
>>loop entry keyword, i.e. placed where loops start. (But that's
>>just my opinion.) Having it at a different place with a do-loop
>>I consider a really bad decision. It's advantageous to know the
>>direction in which to seek for the label if you inspect code. -
>>But okay, it's "C"; I won't heat up about some future C-release
>>that I'll never use (especially given that I'm not even be using
>>all of those more recent additions that are already available).
>
> I think colocating it with `do` might create a syntactic
> ambiguity. In the case of `for`, `while`, and `select`, there
> is a required token following the keyword (the `(`). However,
> for a `do`/`while` loop, `do` is followed immediately by a,
> `secondary-block` production. In particular, you do not _need_
> braces to denote a compound statement after `do`; something like
> `do i++; while (i < j);` is perfectly legal in C.
>
> In the N3377 proposal, the new `block-name` is just an
> identifier. If it were allowed immediately after the `do`, then
> given, `do NAME statement; while(condition);` you can't tell
> `NAME` from the name of the loop and a random identifier before
> a statement; something like `do LOOP i++; while (i < j);`
> appears as though it _would_ be be syntactically valid by N3377
> as presently worked, but is the programmer's intent to create a
> loop name, or should this just be a syntax error?
>
> By requiring the block-name between a keyword and a
> syntactically required `(`, you remove that ambiguity: if there
> is an identifier there, then it is a `block-name`; if not, then
> the block has no name.
AFAICS this is worse, both:
do (i++); while (i < j);
and
do LOOP(i++); while (i < j);
are currently legal (assuming that 'LOOP' is a function).
Writing statement with parentheses may look silly, but such code
may be easily produced due to use of macros.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-19 01:56 +0000 |
| Message-ID | <11b3tc5$1lgro$3@dont-email.me> |
| In reply to | #403299 |
On Sun, 18 Oct 2026 23:51:25 -0000 (UTC), Waldek Hebisch wrote: > Writing statement with parentheses may look silly, but such code may > be easily produced due to use of macros. Why do you need to distinguish between “statements” and “expressions”, anyway? By the way, the precursor of C, BCPL, allowed statement sequences inside expressions. For some reason this got dropped from C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-18 19:37 -0700 |
| Message-ID | <11b3vpg$1md9i$1@kst.eternal-september.org> |
| In reply to | #403304 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Sun, 18 Oct 2026 23:51:25 -0000 (UTC), Waldek Hebisch wrote:
>> Writing statement with parentheses may look silly, but such code may
>> be easily produced due to use of macros.
>
> Why do you need to distinguish between “statements” and “expressions”,
> anyway?
Because C strongly distinguishes between statements and expressions.
If you don't want to make that distinction, you'll need to use a
different language.
(The context was that a suggested change to C would be syntactically
ambiguous.)
> By the way, the precursor of C, BCPL, allowed statement sequences
> inside expressions. For some reason this got dropped from C.
Yes.
There is a proposal to add statement expressions to C, based on
the existing gcc extension. This is not reflected in the latest
C2y draft.
Note that statements and expressions are still distinct. An
expression statement can be formed from an expression by adding
a semicolon. A statement expression (given the extension) can be
formed from a compound statement by adding parentheses.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3643.htm
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-18 23:56 +0000 |
| Message-ID | <11b3mbv$3qr$1@reader2.panix.com> |
| In reply to | #403295 |
In article <11b3gkj$mt2$1@reader2.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <11b2pq5$3pvda$7@dont-email.me>,
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-10-18 16:13, Michael S wrote:
>>> On Sun, 18 Oct 2026 14:34:28 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>> On 2026-10-18 14:09, David Brown wrote:
>>>>>
>>>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>>>>> rather than "do NAME { } while ( )". )
>>>>
>>>> Oh! - I can only think that it would then be (sort of) "consistent"
>>>> with the place of the label attacked in a 'while' loop; i.e. behind
>>>> the 'while' keyword. - It's inconsistent in another interpretation,
>>>> though; and I'd certainly have favored the latter form, to have the
>>>> label consistently attached at the loop-entry keyword.
>>>
>>> I'd prefer label consistently attached to the loop-exit keyword.
>>
>>I can see that this might look appealing in case of 'break'. In
>>case of the same mechanism working also for 'continue' I'd then
>>think that it should generally better be an "attribute" of the
>>loop entry keyword, i.e. placed where loops start. (But that's
>>just my opinion.) Having it at a different place with a do-loop
>>I consider a really bad decision. It's advantageous to know the
>>direction in which to seek for the label if you inspect code. -
>>But okay, it's "C"; I won't heat up about some future C-release
>>that I'll never use (especially given that I'm not even be using
>>all of those more recent additions that are already available).
>
>I think colocating it with `do` might create a syntactic
>ambiguity. In the case of `for`, `while`, and `select`, there
>is a required token following the keyword (the `(`). However,
>for a `do`/`while` loop, `do` is followed immediately by a,
>`secondary-block` production. In particular, you do not _need_
>braces to denote a compound statement after `do`; something like
>`do i++; while (i < j);` is perfectly legal in C.
Rather, you _would_ need braces for a _compound statement_, but
a compound statement is not required here.
>In the N3377 proposal, the new `block-name` is just an
>identifier. If it were allowed immediately after the `do`, then
>given, `do NAME statement; while(condition);` you can't tell
>`NAME` from the name of the loop and a random identifier before
>a statement; something like `do LOOP i++; while (i < j);`
>appears as though it _would_ be be syntactically valid by N3377
>as presently worked, but is the programmer's intent to create a
>loop name, or should this just be a syntax error?
>
>By requiring the block-name between a keyword and a
>syntactically required `(`, you remove that ambiguity: if there
>is an identifier there, then it is a `block-name`; if not, then
>the block has no name.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 16:15 +0200 |
| Message-ID | <11b58md$1kr9u$4@dont-email.me> |
| In reply to | #403295 |
On 2026-10-19 00:18, Dan Cross wrote:
> In article <11b2pq5$3pvda$7@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-10-18 16:13, Michael S wrote:
>>> On Sun, 18 Oct 2026 14:34:28 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>> On 2026-10-18 14:09, David Brown wrote:
>>>>>
>>>>> [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>>>>> rather than "do NAME { } while ( )". )
>>>>
>>>> Oh! - I can only think that it would then be (sort of) "consistent"
>>>> with the place of the label attacked in a 'while' loop; i.e. behind
>>>> the 'while' keyword. - It's inconsistent in another interpretation,
>>>> though; and I'd certainly have favored the latter form, to have the
>>>> label consistently attached at the loop-entry keyword.
>>>
>>> I'd prefer label consistently attached to the loop-exit keyword.
>>
>> I can see that this might look appealing in case of 'break'. In
>> case of the same mechanism working also for 'continue' I'd then
>> think that it should generally better be an "attribute" of the
>> loop entry keyword, i.e. placed where loops start. [...]
>
> I think colocating it with `do` might create a syntactic
> ambiguity. In the case of `for`, `while`, and `select`, there
> is a required token following the keyword (the `(`). However,
> for a `do`/`while` loop, `do` is followed immediately by a,
> `secondary-block` production.
Good point!
> In particular, you do not _need_
> braces to denote a compound statement after `do`; something like
> `do i++; while (i < j);` is perfectly legal in C.
Yes.
>
> In the N3377 proposal, the new `block-name` is just an
> identifier. If it were allowed immediately after the `do`, then
> given, `do NAME statement; while(condition);` you can't tell
> `NAME` from the name of the loop and a random identifier before
> a statement; something like `do LOOP i++; while (i < j);`
> appears as though it _would_ be be syntactically valid by N3377
> as presently worked, but is the programmer's intent to create a
> loop name, or should this just be a syntax error?
>
> By requiring the block-name between a keyword and a
> syntactically required `(`, you remove that ambiguity: if there
> is an identifier there, then it is a `block-name`; if not, then
> the block has no name.
Thanks for your elaborations.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-18 18:33 -0700 |
| Message-ID | <11b3s0v$1lao8$1@kst.eternal-september.org> |
| In reply to | #403270 |
Michael S <already5chosen@yahoo.com> writes:
> On Sun, 18 Oct 2026 14:34:28 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-10-18 14:09, David Brown wrote:
>> >
>> > [...] (I don't know why N3377 proposed "do { } while NAME ( )"
>> > rather than "do NAME { } while ( )". )
>>
>> Oh! - I can only think that it would then be (sort of) "consistent"
>> with the place of the label attacked in a 'while' loop; i.e. behind
>> the 'while' keyword. - It's inconsistent in another interpretation,
>> though; and I'd certainly have favored the latter form, to have the
>> label consistently attached at the loop-entry keyword.
>
> I'd prefer label consistently attached to the loop-exit keyword.
> Unfortunately, for() and while() loops have no such keyword.
I see your point, but I disagree.
Let's say we have a language where the end of a loop is marked by a
keyword.
WHILE condition
statement;
statement;
ENDWHILE;
Now we want to add the ability to break out of a specified loop,
possibly from within a nested construct. With your preference:
WHILE condition
statement;
if (error) break OUTER; ENDIF;
statement;
OUTER: ENDWHILE;
Putting the label at the bottom of the loop does show more clearly
the point in the code to which the "break" transfers control. In my
opinion, that's not a good thing.
With the label name at the top:
OUTER:
WHILE condition
statement;
if (error) break OUTER; ENDIF;
statement;
ENDWHILE;
"OUTER" is *the name of the loop*, and the entire loop is the
construct to which "break OUTER" applies.
If the syntax emphasizes the point to which the break jumps, I
don't see much advantage over goto.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 13:39 +0200 |
| Message-ID | <11b2b6e$3pvda$4@dont-email.me> |
| In reply to | #403254 |
On 2026-10-18 12:48, David Brown wrote:
> On 17/10/2026 01:29, Janis Papanagnou wrote:
>> On 2026-10-17 00:00, Keith Thompson wrote:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> [...]
>>>>> There's a proposal for C2y to use goto labels as loop names, and a
>>>>> competing one to define a new syntax like "for NAME (;;)" :
>>>>> [...]
>>>>
>>>> I'm not particularly a fan of multi-level break/continue. But if
>>>> we're going to have one of these, the second ("for NAME (;;)") is
>>>> unquestionably better.
>>>
>>> Unquestionably? Why?
>>
>> Why would one question an opinion? ;-)
>
> Time didn't word it as a personal opinion - he made it clear that he
> doesn't think anyone else could have a different opinion.
You've noticed my smiley? (There was no need for an explanation.)
>
> The C standards committee collectively reached an agreement counter to
> Tim's thoughts, so clearly his preferred variant is /not/ unquestionably
> better.
"C" is "C", and Tim is Tim. (And we know both sufficiently.) :-)
>
>>
>>>
>>> I do like the fact that it doesn't conflate goto labels with loop
>>> names, but I still prefer the "NAME: for (;;)" form, partly because
>>> it's consistent with several other languages.
>>
>> I've no strong opinion on that, but I find the "for NAME (;;)" to
>> clearer express the _local scope_ of embedded breaks or continues.
>> (Just a matter of taste, and my appreciation for locality.)
>>
(I interpret your following explanations as additional information.)
> A main objection to "name: for ..." is that with function-scope labels,
> you need a new name for every labelled loop or switch. That may be an
> inconvenience, especially for macro with labelled loops, or for copy-
> and-paste code. There is a proposal to deal with that which basically
> says :
>
> 1. Any "break label;" or "continue label;" refers to the innermost
> containing loop or switch with that label.
>
> 2. Any "label" used in "goto label;" must be unique in the function.
>
> Those rules give a simple and intuitive fix without affecting existing
> code.
Yes.
>
> Beyond that, "name: for ..." or "for name ..." is, as you say, mostly a
> matter of taste. (There are proposals for both versions, and you can
> look them up to see the arguments.)
Thanks. I'm interested, but (given what I think about it) not that
much. :-)
>
>>
>> As far as I recall, in "C", the name of the function was often put
>> separately (first in the line) to have an easy method to find its
>> declaration by simple "grep ^fname". (With any sophisticated editor
>> this might be a weak argument, though.)
>>
>
> I think it was popularised with a shortcut in emacs.
Well, I don't know what Emacs supports, or what it doesn't support so
that it requires some workaround, or shortcut, or explicit help from
the programmers concerning the layout.
I was using Vi for decades and with a search command ('/') you can do
a regexp '/^fname' to find fname at the start of a line. But there's
also "ctags" that can be used to facilitate that (and more). Recently
(i.e. since 25+ years) I'm using Vim where there's additional facilities
like the commands 'gd' (and 'gD') to jump to the local (and "global")
declaration of an entity; the latter don't require a tags-database or
any specific source code formatting to find the names.
Personally I've never followed the function-type-on-an-own-line style.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-19 08:47 -0700 |
| Message-ID | <86y0btofoy.fsf@linuxsc.com> |
| In reply to | #403262 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-18 12:48, David Brown wrote:
>
>> On 17/10/2026 01:29, Janis Papanagnou wrote:
>>
>>> On 2026-10-17 00:00, Keith Thompson wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> [...]
>>>>>
>>>>>> There's a proposal for C2y to use goto labels as loop names, and a
>>>>>> competing one to define a new syntax like "for NAME (;;)" :
>>>>>> [...]
>>>>>
>>>>> I'm not particularly a fan of multi-level break/continue. But if
>>>>> we're going to have one of these, the second ("for NAME (;;)") is
>>>>> unquestionably better.
>>>>
>>>> Unquestionably? Why?
>>>
>>> Why would one question an opinion? ;-)
>>
>> Time didn't word it as a personal opinion - he made it clear that he
>> doesn't think anyone else could have a different opinion.
>
> You've noticed my smiley? (There was no need for an explanation.)
Anyone who thinks my statement "the second ("for NAME (;;)") is
unquestionably better" was meant as a statement of fact rather
than a statement of opinion is an idiot.
I think most people can see that I am careful in my writing, and
also that I make an effort to differentiate statements of opinion,
statements of belief, and statements of fact. My remark above is
no exception to that practice.
For the benefit of any other people who may have not seen the
distinction here, please remember this: any statement that uses
the word "better", when made without any reference to some sort of
objective metric, is inherently a subjective statement. Any
subjective statement (that does not fall into the category of
being a statement of belief) is a statement of opinion. It's easy
to see this simply by a process of elimination, because subjective
statements are not facts, and vice versa.
>> The C standards committee collectively reached an agreement counter
>> to Tim's thoughts, so clearly his preferred variant is /not/
>> unquestionably better.
>
> "C" is "C", and Tim is Tim. (And we know both sufficiently.) :-)
My confidence in the collective wisdom of the ISO C committee has
declined in recent years, and sadly for more than just the last
few years. So learning that they have settled (even if that might
change in the future) on the "label: for(...)" approach is
disappointing, but not surprising.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 18:28 +0200 |
| Message-ID | <11b5gfr$1kr9u$5@dont-email.me> |
| In reply to | #403325 |
[ with big snips of lots of irrelevant stuff ] On 2026-10-19 17:47, Tim Rentsch wrote: >> On 2026-10-18 12:48, David Brown wrote: >>> >>> The C standards committee collectively reached an agreement counter >>> to Tim's thoughts, so clearly his preferred variant is /not/ >>> unquestionably better. > > My confidence in the collective wisdom of the ISO C committee has > declined in recent years, and sadly for more than just the last > few years. So learning that they have settled (even if that might > change in the future) on the "label: for(...)" approach is > disappointing, but not surprising. I understand the disappointment when something evolves differently, where own opinions or own "educated or acquired wisdom" diverges. (Such expressed disappointment is observable with some other poster here as well.) Opinions are fine, arguments are better. The arguments (meanwhile) exchanged here let me come to another conclusion than you, though, concerning the competence or rather the thoughtfulness of the involved committee members. And, to come back to the primary topic; the "problems" adding such features to "C" (with all perceived sub-optimality of every option) is primarily based on how it had been designed back then. (It's not so much a problem of the specific "collective [committee] wisdom". IMHO and YMMV.) I don't think it makes sense to continue discussions on that level. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-19 16:11 -0700 |
| Message-ID | <11b683i$2fcat$3@kst.eternal-september.org> |
| In reply to | #403325 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-10-18 12:48, David Brown wrote:
>>> On 17/10/2026 01:29, Janis Papanagnou wrote:
>>>> On 2026-10-17 00:00, Keith Thompson wrote:
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>> [...]
>>>>>>> There's a proposal for C2y to use goto labels as loop names, and a
>>>>>>> competing one to define a new syntax like "for NAME (;;)" :
>>>>>>> [...]
>>>>>>
>>>>>> I'm not particularly a fan of multi-level break/continue. But if
>>>>>> we're going to have one of these, the second ("for NAME (;;)") is
>>>>>> unquestionably better.
>>>>>
>>>>> Unquestionably? Why?
>>>>
>>>> Why would one question an opinion? ;-)
>>>
>>> Time didn't word it as a personal opinion - he made it clear that he
>>> doesn't think anyone else could have a different opinion.
>>
>> You've noticed my smiley? (There was no need for an explanation.)
>
> Anyone who thinks my statement "the second ("for NAME (;;)") is
> unquestionably better" was meant as a statement of fact rather
> than a statement of opinion is an idiot.
"Better" is an opinion, and if you had just said that I wouldn't have
replied.
If you're saying that "unquestionably better" is merely an opinion,
I now accept that you meant it that way, but that's not the way I
interpreted it. It implies, not merely that something is better,
but that nobody could possibly question that it's better. I suggest
you write more clearly rather than insulting your readers, perhaps
by choosing a word other than "unquesionably" to denote emphasis.
When I asked you to explain, you responded by giving me a detailed
homework assignment as a prerequisite to answering my question.
Perhaps you weren't serious about that, but I couldn't tell.
To be clear, I am no longer asking you to explain what you meant by
"unquestionably better".
> I think most people can see that I am careful in my writing, and
> also that I make an effort to differentiate statements of opinion,
> statements of belief, and statements of fact. My remark above is
> no exception to that practice.
Apparently you didn't *intend* it to be an exception to that practice.
> For the benefit of any other people who may have not seen the
> distinction here, please remember this: any statement that uses
> the word "better", when made without any reference to some sort of
> objective metric, is inherently a subjective statement. Any
> subjective statement (that does not fall into the category of
> being a statement of belief) is a statement of opinion. It's easy
> to see this simply by a process of elimination, because subjective
> statements are not facts, and vice versa.
<sarcasm>Thank you for explaining that to us.</sarcasm>
You used the phrase "unquestionably better". I questioned that. If
your problem with my response was that you were merely expressing
an opinion, you could have just said that rather than wasting our
time by bloviating about the difference between opinions and facts.
[...]
> My confidence in the collective wisdom of the ISO C committee has
> declined in recent years, and sadly for more than just the last
> few years. So learning that they have settled (even if that might
> change in the future) on the "label: for(...)" approach is
> disappointing, but not surprising.
I acknowledge your opinion. I certainly do not share it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-18 22:33 +0000 |
| Message-ID | <11b3hfo$8vk$1@reader2.panix.com> |
| In reply to | #403254 |
In article <11b285v$121v2$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 17/10/2026 01:29, Janis Papanagnou wrote:
>> On 2026-10-17 00:00, Keith Thompson wrote:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> [...]
>>>>> There's a proposal for C2y to use goto labels as loop names, and a
>>>>> competing one to define a new syntax like "for NAME (;;)" :
>>>>> [...]
>>>>
>>>> I'm not particularly a fan of multi-level break/continue. But if
>>>> we're going to have one of these, the second ("for NAME (;;)") is
>>>> unquestionably better.
>>>
>>> Unquestionably? Why?
>>
>> Why would one question an opinion? ;-)
>
>Time didn't word it as a personal opinion - he made it clear that he
>doesn't think anyone else could have a different opinion.
Tim often makes it sound as though he believes that his opinions
are facts.
>> As far as I recall, in "C", the name of the function was often put
>> separately (first in the line) to have an easy method to find its
>> declaration by simple "grep ^fname". (With any sophisticated editor
>> this might be a weak argument, though.)
>
>I think it was popularised with a shortcut in emacs.
No, it was `grep`. The convention originated on Unix, but well
before there was a version of Emacs in widespread use on those
systems; most Unix programmers were using `ed` at the time, and
`vi` was still a few years away; `ctags` was not a thing yet.
Recall that early versions of C defaulted to `int` as a return
type if otherwise unspecified; there was no `void`, so if a
programmer had no intention of returning anything at all, they
would just omit the return type and the `return` statement. The
result was that there were many functions that declared no
return type, and just started with the function at the beginning
of the line; it was natural to use `grep ^name` to look for
those, and it was sufficiently useful that the convention stuck
even as we gained both more powerful editors and more stricter
versions of C.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-17 19:39 +0300 |
| Message-ID | <20261017193908.00000106@yahoo.com> |
| In reply to | #403224 |
On Fri, 16 Oct 2026 15:00:27 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >> I find "break NAME;", where "NAME" is the name of an enclosing
> >> construct, unambiguously better than "break N;", where N is the
> >> number of levels to break out of. [...]
> >
> > Definitely.
> >
> >> There's a proposal for C2y to use goto labels as loop names, and a
> >> competing one to define a new syntax like "for NAME (;;)" :
> >>
> >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
> >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
> >
> > I'm not particularly a fan of multi-level break/continue. But if
> > we're going to have one of these, the second ("for NAME (;;)") is
> > unquestionably better.
>
> Unquestionably? Why?
>
I don't know why Tim prefers it.
I prefer it (strongly) because it is different from regular label. So
reader that wants to understand a flow of the program should not be
concerned with possibility of jumping to it from places outside for().
> I do like the fact that it doesn't conflate goto labels with loop
> names, but I still prefer the "NAME: for (;;)" form, partly because
> it's consistent with several other languages.
>
You mentioned itself that in Ada loop labels are distinct from regular
labels. I would think that Ada alone easily outweighs "several other
languages" if we compare by number (and likely by quality) of man-hours
invested into thinking and discussion of syntactic features.
Anyway I value appeal to success more than appeal to authority so by my
own standards the argument above is weak.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-17 18:23 +0100 |
| Message-ID | <11b0av3$edsd$1@dont-email.me> |
| In reply to | #403239 |
On 17/10/2026 17:39, Michael S wrote:
> On Fri, 16 Oct 2026 15:00:27 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> I find "break NAME;", where "NAME" is the name of an enclosing
>>>> construct, unambiguously better than "break N;", where N is the
>>>> number of levels to break out of. [...]
>>>
>>> Definitely.
>>>
>>>> There's a proposal for C2y to use goto labels as loop names, and a
>>>> competing one to define a new syntax like "for NAME (;;)" :
>>>>
>>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
>>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
>>>
>>> I'm not particularly a fan of multi-level break/continue. But if
>>> we're going to have one of these, the second ("for NAME (;;)") is
>>> unquestionably better.
>>
>> Unquestionably? Why?
>>
>
> I don't know why Tim prefers it.
> I prefer it (strongly) because it is different from regular label. So
> reader that wants to understand a flow of the program should not be
> concerned with possibility of jumping to it from places outside for().
>
>> I do like the fact that it doesn't conflate goto labels with loop
>> names, but I still prefer the "NAME: for (;;)" form, partly because
>> it's consistent with several other languages.
>>
>
> You mentioned itself that in Ada loop labels are distinct from regular
> labels. I would think that Ada alone easily outweighs "several other
> languages" if we compare by number (and likely by quality) of man-hours
> invested into thinking and discussion of syntactic features.
> Anyway I value appeal to success more than appeal to authority so by my
> own standards the argument above is weak.
I was around when Ada was being developed and refined, a process that
took years.
By contrast, C looks like it was just thrown together with little
thought, and probably that is exactly what happened.
In the end, Ada was a language that you could admire, but you'd rather
other people used. It's a solid language but I found it too formal and
rather dull (not that it was available for me to use).
Still, I borrowed some syntactic features from it.
One interesting fact that people might forget is that it was
case-insensitive, a welcome difference IMV.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-17 17:36 +0000 |
| Message-ID | <11b0bn8$cq8$1@reader2.panix.com> |
| In reply to | #403240 |
In article <11b0av3$edsd$1@dont-email.me>, bart <bc@freeuk.com> wrote: >[snip] >I was around when Ada was being developed and refined, a process that >took years. > >By contrast, C looks like it was just thrown together with little >thought, and probably that is exactly what happened. >[snip] Oh put a sock in it, guy. No one here slavishly worships C or thinks it is perfect, but taking every little chance you can to throw barbs at it with otherwise utterly information-free posts like this, is merely noise. Honestly, the constant "notice me, senpai!" posts are just pathetic attention-seeking. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-17 21:03 +0300 |
| Message-ID | <20261017210359.00003dff@yahoo.com> |
| In reply to | #403240 |
On Sat, 17 Oct 2026 18:23:47 +0100
bart <bc@freeuk.com> wrote:
> On 17/10/2026 17:39, Michael S wrote:
> > On Fri, 16 Oct 2026 15:00:27 -0700
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >>>> I find "break NAME;", where "NAME" is the name of an enclosing
> >>>> construct, unambiguously better than "break N;", where N is the
> >>>> number of levels to break out of. [...]
> >>>
> >>> Definitely.
> >>>
> >>>> There's a proposal for C2y to use goto labels as loop names, and
> >>>> a competing one to define a new syntax like "for NAME (;;)" :
> >>>>
> >>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3355.htm
> >>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3377.pdf
> >>>
> >>> I'm not particularly a fan of multi-level break/continue. But if
> >>> we're going to have one of these, the second ("for NAME (;;)") is
> >>> unquestionably better.
> >>
> >> Unquestionably? Why?
> >>
> >
> > I don't know why Tim prefers it.
> > I prefer it (strongly) because it is different from regular label.
> > So reader that wants to understand a flow of the program should not
> > be concerned with possibility of jumping to it from places outside
> > for().
> >> I do like the fact that it doesn't conflate goto labels with loop
> >> names, but I still prefer the "NAME: for (;;)" form, partly because
> >> it's consistent with several other languages.
> >>
> >
> > You mentioned itself that in Ada loop labels are distinct from
> > regular labels. I would think that Ada alone easily outweighs
> > "several other languages" if we compare by number (and likely by
> > quality) of man-hours invested into thinking and discussion of
> > syntactic features. Anyway I value appeal to success more than
> > appeal to authority so by my own standards the argument above is
> > weak.
>
> I was around when Ada was being developed and refined, a process that
> took years.
>
> By contrast, C looks like it was just thrown together with little
> thought, and probably that is exactly what happened.
>
> In the end, Ada was a language that you could admire, but you'd
> rather other people used. It's a solid language but I found it too
> formal and rather dull (not that it was available for me to use).
>
I use Ada off-spring VHDL very regularly.
I prefer it over Verilog, but I do it due to semantics and mostly
despite [inherited from Ada] syntax.
> Still, I borrowed some syntactic features from it.
>
> One interesting fact that people might forget is that it was
> case-insensitive, a welcome difference IMV.
>
I don't like case-insensitivity, except, may be, for keywords.
I don't like begin..end.
Most of all, I don't like nested procedures that have visibility of
local variables of the parent (That's related to Ada, not significant
in context of VHDL).
I suppose, I don't like most of the thing that you like about
programming languages.
[toc] | [prev] | [next] | [standalone]
Page 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web