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-22 09:51 +0200 |
| Articles | 20 on this page of 479 — 24 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 David Brown <david.brown@hesbynett.no> - 2026-10-20 09:05 +0200
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 Bob Duff <invalid@invalid.com> - 2026-10-19 19:38 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 17:03 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:45 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 05:01 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 00:45 -0700
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-20 01:02 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:18 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 02:53 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 12:22 +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 Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-19 23:41 +0000
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 antispam@fricas.org (Waldek Hebisch) - 2026-10-20 00:16 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 16:10 -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 antispam@fricas.org (Waldek Hebisch) - 2026-10-20 01:03 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 15:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:02 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:07 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 11:20 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:29 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 16:40 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 23:33 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 00:01 +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 David Brown <david.brown@hesbynett.no> - 2026-10-20 10:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 12:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 14:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 17:05 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 12:45 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 13:21 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 11:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:21 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 15:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:36 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 15:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 17:22 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 17:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 19:04 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:36 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:36 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 23:10 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 22:55 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 17:19 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 19:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:56 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 19:24 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:30 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 21:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 23:43 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 00:56 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:55 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-21 07:22 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 01:56 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:10 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:17 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 13:22 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:29 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:43 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-21 13:02 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 08:57 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-22 12:56 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 17:00 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 16:54 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 21:09 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-22 12:46 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 01:18 +0200
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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:40 +0000
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-20 10:25 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 16:56 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:32 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:23 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:28 +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
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-21 11:19 +0200
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-21 09:29 -0600
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-22 00:33 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 09:51 +0200
Page 20 of 24 — ← Prev page 1 … 18 19 [20] 21 22 … 24 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 17:29 +0200 |
| Message-ID | <11balos$1042$2@dont-email.me> |
| In reply to | #403416 |
On 21/10/2026 15:22, Dan Cross wrote:
> In article <11baah2$3te3v$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 20/10/2026 21:24, Dan Cross wrote:
>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>> [snip]
>>>> (There was a LOT of antipathy towards my idea to fix the common case of
>>>> 'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
>>>> problem of nested loop-break, which is uncommon, even though that wasn't
>>>> the aim.)
>>>
>>> Those are two different things. No one disagrees with you that
>>> "nested break from a switch inside of a loop" is relatively more
>>> common than other variants.
>>
>> Quibble - that is not established to my satisfaction. I am not
>> convinced that wanting a nested break for "switch inside loop" is more
>> common than wanting it for "loop inside loop". So I neither agree nor
>> disagree with that claim. I don't, however, think it matters much -
>> both are situations that turn up sometimes in code, and definitive
>> answers are neither possible nor useful.
>
> Ok, that's fair; I shouldn't say "no one disagrees".
And I didn't say I /did/ disagree - merely that I don't feel I have the
information to disagree or agree.
We all over-generalise, and that's always bad!
>
>>> [snip]
>>> There are plenty of languages that can do this kind of thing
>>> that are not C and have syntax and semantics closer to what you
>>> seem to want. Here's an example in Rust:
>>>
>>> pub trait TimerHandle { ... }
>>>
>>> fn CreateTimer<T>(
>>> timer_name: &str,
>>> period: std::time::Duration,
>>> auto_reload: bool,
>>> timer_id: T,
>>> handler: fn(&dyn TimerHandle),
>>> ) -> Result<Timer<T>, TimerError>
>>>
>>> I didn't know what an `UBaseType_t` is, and while "autoreload"
>>> sounded pretty intuitive, I wasn't sure about the semantics, so
>>> I looked it up (the example comes from `FreeRTOS`). In this
>>> context, it is a boolean saying whether the timer should repeat
>>> with the given periodicity, or whether it is a one-shot.
>>
>> FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
>> bool. Instead, it uses constants pdTRUE and pdFALSE of type
>> UBaseType_t. UBaseType_t is a type that is dependent on the target -
>> usually it is either 16-bit or 32-bit. But of course it doesn't matter
>> what the underlying types are - you use the typedef names, and the
>> documented constants.
>
> Thanks for the context. Your point that the underlying type
> doesn't matter is salient: it's opaque to the programmer, but
> 99% of the time the programmer doesn't need to worry about the
> details.
Yes.
>
>>> The timer_id is opaque to the timer, and it looks like it's used
>>> to facilitating the handler accessing timer-specific data. In
>>> C, passing it as a `void *` is used as a way to get a poor-man's
>>> overloading. But Rust has generics, I just made it generic over
>>> some type T.
>>
>> FreeRTOS uses "void *" to mean "pointer to internal structure that you
>> shouldn't be messing with". It uses this far too often, and is, IMHO, a
>> poor design choice. (I also dislike the silly Hungarian naming.) I
>> would much preferred if there had been :
>>
>> struct Internal_Timer_Struct;
>> typedef struct Internal_Timer_Struct * timer_id_t;
>>
>> and then the parameter "timer_id_t timer_id". So in a re-write, it
>> would not be a generic. (You might choose to use a generic for the
>> handler function type, so that handler callbacks could have parameters
>> of other types, but not for the timer id.)
>>
>> I am using these declarations from FreeRTOS (and LWIP) to demonstrate
>> the use of function typedefs in massively popular codebases, not to
>> claim FreeRTOS is a paradigm of C code design!
>
> Oh interesting; in this case, I had assumed it was treated as
> a callback-specific type so one could plumb extra context into
> the handler; the documentation I saw suggested it could be used
> by the handler to disambiguate several timers reusing the same
> handler function.
Actually, I have mixed these up, and you are correct - the void* id is
user-assigned, and you use it as you wish. There are other places in
FreeRTOS where pointer types get "erased" and reduced to void*
unnecessarily, but this was not one of them. (In my poor defence, the
FreeRTOS code I have doesn't use timers, and the bits it does use -
threads and queues, mainly - is abstracted to a C++ interface.)
>
>>> For example:
>>>
>>> [snip]
>>>
>>> Note this is decently complex behavior, but it's actually quite
>>> intuitive from the name and the type.
>>
>> You have got a very clear picture here, much of it from the names of the
>> types. For a Rust programmer, you give a good impression of experience
>> with C :-)
>
> I've been known to dabble.
>
>> The only mistake you made is that programmers working on systems using
>> FreeRTOS and the like, have a fear and loathing of "malloc", have never
>> heard of "abort()", and do not join our threads because they all run
>> until the power is switched off.
>
> Ha, fair; that was just a made-up example, based on other thread
> libraries I have used (in C). I didn't mean for it to be
> interpreted strictly in the context of FreeRTOS! :-D
>
>> [snip]
>>
>> Or just have :
>>
>> fnptr pc = first;
>> fnptr *pcptr = &pc;
>>
>> I don't see a need for "uintptr_t", except so that you have to have
>> casts like Bart had.
>
> Yes. But I wanted to remain faithful to his original, to show
> that one could write a more-or-less exact transliteration in C
> that was extremely similar to his chosen syntax.
>
>>> [Snip a bunch of Rust code; the point of which being that
>>> bart need not complain about lack of an alternative to C]
>
It was interesting to see the Rust code, but it made one thing clear to
me - Rust should be used for writing Rust code, and not for writing C
code in Rust syntax.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 18:43 +0000 |
| Message-ID | <11bb15a$mif$1@reader2.panix.com> |
| In reply to | #403421 |
In article <11balos$1042$2@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 21/10/2026 15:22, Dan Cross wrote: >[snip] >Actually, I have mixed these up, and you are correct - the void* id is >user-assigned, and you use it as you wish. There are other places in >FreeRTOS where pointer types get "erased" and reduced to void* >unnecessarily, but this was not one of them. (In my poor defence, the >FreeRTOS code I have doesn't use timers, and the bits it does use - >threads and queues, mainly - is abstracted to a C++ interface.) No problem! >It was interesting to see the Rust code, but it made one thing clear to >me - Rust should be used for writing Rust code, and not for writing C >code in Rust syntax. Yes. When we started working with Rust, most of us had a lot of experience in C, C++, etc, and we brought a lot of inherited bad habits to our Rust code. At one point, a colleague quipped that we were writing, "crust: C in Rust syntax!" We all thought that was a great play on words, and adopted it in self-deprecating terms. Some people get pretty insulted by it, but it was never intended that way. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-21 13:02 -0700 |
| Message-ID | <11bb5ou$8nfg$2@dont-email.me> |
| In reply to | #403412 |
On 10/21/2026 5:17 AM, David Brown wrote: [...] *_t intrudes into POSIX.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-22 08:57 +0200 |
| Message-ID | <11bcc4o$jt81$1@dont-email.me> |
| In reply to | #403434 |
On 21/10/2026 22:02, Chris M. Thomasson wrote: > On 10/21/2026 5:17 AM, David Brown wrote: > [...] > > *_t intrudes into POSIX. I don't program for POSIX, so I don't care. The same applies to most code that is used in connection with FreeRTOS, or LWIP. (Of course there will be some overlap - bits of code that are intended to run on a microcontroller but tested with code running native on a PC.) I don't know if the "_t" convention for type identifiers started with POSIX, but it has certainly far outgrown POSIX. And I think the smart folks behind POSIX know this, and will not assume that just because they pick a new type name ending in _t, it will not conflict with some user code. As C doesn't have namespaces, there is always a risk of conflicting names - you just have to try to avoid clashes in things you are likely to see.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-22 12:56 +0000 |
| Message-ID | <11bd15t$6dj$1@reader2.panix.com> |
| In reply to | #403441 |
In article <11bcc4o$jt81$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 21/10/2026 22:02, Chris M. Thomasson wrote: >> On 10/21/2026 5:17 AM, David Brown wrote: >> [...] >> >> *_t intrudes into POSIX. > >I don't program for POSIX, so I don't care. The same applies to most >code that is used in connection with FreeRTOS, or LWIP. (Of course >there will be some overlap - bits of code that are intended to run on a >microcontroller but tested with code running native on a PC.) > >I don't know if the "_t" convention for type identifiers started with >POSIX, but it has certainly far outgrown POSIX. And I think the smart >folks behind POSIX know this, and will not assume that just because they >pick a new type name ending in _t, it will not conflict with some user >code. As C doesn't have namespaces, there is always a risk of >conflicting names - you just have to try to avoid clashes in things you >are likely to see. It definitely predates POSIX. `typdef` appears to have come into the language with "Typesetter C", which first shipped in 7th Edition research Unix, and 7th Ed had types ending in `_t`; so 1979 or thereabouts. For instance, `daddr_t`, `time_t`, and `caddr_t` to represent disk block addresses, times, and generic addresses, respectively. Curiously, `size_t` isn't there yet, and appears to arrive in 3bsd (also 1979, but based on 32/V), where it is sized (it's just a typedef for `int`). `size_t` makes it back into Research Unix with the 8th Edition, based on 4BSD; probably 4.1. It is signed in 8th Ed, and is a typedef for `long`. My notes put it into AT&T Unix with System V Release 3, where it is unsigned. POSIX started in 1984, building on work done by /usr/group, and the first issue of POSIX was released in 1988. Anyway, the point is that the `_t` convention predates POSIX (and ANSI C) by about a decade. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-22 17:00 +0000 |
| Message-ID | <20261022095509.357@kylheku.com> |
| In reply to | #403443 |
On 2026-10-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote: > Anyway, the point is that the `_t` convention predates POSIX > (and ANSI C) by about a decade. Speaking of caddr_t, that one was spread outside of Unix. I remember caddr_t cropping up when I was working with Microsoft C on DOS in 1990. ANSI/ISO C and its void * were still new, and caddr_t was one of the conventions for a pointer-to-anything. -- 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 | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-22 16:54 +0000 |
| Message-ID | <20261022094427.210@kylheku.com> |
| In reply to | #403441 |
On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: > On 21/10/2026 22:02, Chris M. Thomasson wrote: >> On 10/21/2026 5:17 AM, David Brown wrote: >> [...] >> >> *_t intrudes into POSIX. > > I don't program for POSIX, so I don't care. The same applies to most > code that is used in connection with FreeRTOS, or LWIP. (Of course > there will be some overlap - bits of code that are intended to run on a > microcontroller but tested with code running native on a PC.) > > I don't know if the "_t" convention for type identifiers started with > POSIX, but it has certainly far outgrown POSIX. And I think the smart > folks behind POSIX know this, and will not assume that just because they > pick a new type name ending in _t, it will not conflict with some user > code. As C doesn't have namespaces, there is always a risk of > conflicting names - you just have to try to avoid clashes in things you > are likely to see. These namespace declarations are really just a "heads up". POSIX isn't saying, don't have an identifier ending in _t in a namespace shared by typedefs. Rather, it is saying that new typedefs appearing in POSIX will be in that namespace. Consider this argument: whenever POSIX or ISO C introduces a new public identifier, it's necessarily going to start with "a", or else if not, then with "b", or else with "c", ... or else with "z" or perhaps the underscore. That doesn't mean you stop using identifiers in programming. "nullptr" is now a keyword, previously a valid identifier not in any proclaimed reserved namespace. Progrems which used it have to be changed to work with the newer language. Avoiding proclaimed namespaces will not protect you from clashes; only from clashes that would occur in those namespaces. Some spaces like _t are too attractive to avoid, because they are tied to an important, popular convention that everyone understands, and the benefits outweigh the unrealized risk of a future clash. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-22 21:09 +0200 |
| Message-ID | <11bdn1j$14p5v$1@dont-email.me> |
| In reply to | #403450 |
On 22/10/2026 18:54, Kaz Kylheku wrote: > On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>> On 10/21/2026 5:17 AM, David Brown wrote: >>> [...] >>> >>> *_t intrudes into POSIX. >> >> I don't program for POSIX, so I don't care. The same applies to most >> code that is used in connection with FreeRTOS, or LWIP. (Of course >> there will be some overlap - bits of code that are intended to run on a >> microcontroller but tested with code running native on a PC.) >> >> I don't know if the "_t" convention for type identifiers started with >> POSIX, but it has certainly far outgrown POSIX. And I think the smart >> folks behind POSIX know this, and will not assume that just because they >> pick a new type name ending in _t, it will not conflict with some user >> code. As C doesn't have namespaces, there is always a risk of >> conflicting names - you just have to try to avoid clashes in things you >> are likely to see. > > These namespace declarations are really just a "heads up". POSIX > isn't saying, don't have an identifier ending in _t in a namespace > shared by typedefs. Rather, it is saying that new typedefs appearing > in POSIX will be in that namespace. > > Consider this argument: whenever POSIX or ISO C introduces a new > public identifier, it's necessarily going to start with "a", or else if > not, then with "b", or else with "c", ... or else with "z" > or perhaps the underscore. > > That doesn't mean you stop using identifiers in programming. > > "nullptr" is now a keyword, previously a valid identifier not in > any proclaimed reserved namespace. Progrems which used it have > to be changed to work with the newer language. > > Avoiding proclaimed namespaces will not protect you from clashes; > only from clashes that would occur in those namespaces. > > Some spaces like _t are too attractive to avoid, because they are tied > to an important, popular convention that everyone understands, > and the benefits outweigh the unrealized risk of a future clash. > I agree entirely.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-22 12:46 -0700 |
| Message-ID | <11bdp73$15nor$1@dont-email.me> |
| In reply to | #403450 |
On 10/22/2026 9:54 AM, Kaz Kylheku wrote: > On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>> On 10/21/2026 5:17 AM, David Brown wrote: >>> [...] >>> >>> *_t intrudes into POSIX. >> >> I don't program for POSIX, so I don't care. The same applies to most >> code that is used in connection with FreeRTOS, or LWIP. (Of course >> there will be some overlap - bits of code that are intended to run on a >> microcontroller but tested with code running native on a PC.) >> >> I don't know if the "_t" convention for type identifiers started with >> POSIX, but it has certainly far outgrown POSIX. And I think the smart >> folks behind POSIX know this, and will not assume that just because they >> pick a new type name ending in _t, it will not conflict with some user >> code. As C doesn't have namespaces, there is always a risk of >> conflicting names - you just have to try to avoid clashes in things you >> are likely to see. > > These namespace declarations are really just a "heads up". POSIX > isn't saying, don't have an identifier ending in _t in a namespace > shared by typedefs. Rather, it is saying that new typedefs appearing > in POSIX will be in that namespace. > > Consider this argument: whenever POSIX or ISO C introduces a new > public identifier, it's necessarily going to start with "a", or else if > not, then with "b", or else with "c", ... or else with "z" > or perhaps the underscore. > > That doesn't mean you stop using identifiers in programming. > > "nullptr" is now a keyword, previously a valid identifier not in > any proclaimed reserved namespace. Progrems which used it have > to be changed to work with the newer language. > > Avoiding proclaimed namespaces will not protect you from clashes; > only from clashes that would occur in those namespaces. > > Some spaces like _t are too attractive to avoid, because they are tied > to an important, popular convention that everyone understands, > and the benefits outweigh the unrealized risk of a future clash. > Touche. How about _this vs this_. I just use self and be done with it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-19 15:48 -0700 |
| Message-ID | <11b66ng$2fcat$2@kst.eternal-september.org> |
| In reply to | #403317 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-18 21:09, David Brown wrote:
>> On 18/10/2026 18:09, bart wrote:
>>> [...]
> [ declaration syntax ]
>
> (I just want to comment on a [not unimportant] detail...)
>
>> You need to give things in the right order, or use parentheses, to
>> get the right "type expression". It's just like any other kind of
>> expression.
>> The intention of the declaration syntax in C is that the declaration
>> order follows usage. [...]
>
> I think the first part is downplaying that languages typically indeed
> make a distinction between parenthesized expressions and declarations.
> Quite some other languages [not from the C-heritage] that I used all
> did not need to introduce "expression"-grouping for _declarations_ in
> the first place given their more consistent ways to declare entities.
Just one quibble. C's declaration syntax *is* consistent. Its
rules are rigorously specified by the standard, particularly by
the grammar.
Many of us (myself included) don't particularly like it, but that
doesn't mean it's inconsistent.
My own take on all this is that having declaration syntax follow usage
was a very clever idea, where "clever" is not necessarily a compliment.
It was IMHO unsuccessful in the sense that it can lead to confusing
and overly complicated declarations. (Other languages don't have tools
corresponding to cdecl for much the same reason that Spanish-speaking
countries don't have spelling bees.) But it was extraordinarily
successful in the sense that, even if you think it was a bad idea,
it wasn't bad enough to keep C from becoming one of the most popular
programming languages.
(I wonder if keeping the declaration-follows-use principle while
making "*" a postfix operator might have improved things.)
--
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-20 01:18 +0200 |
| Message-ID | <11b68gm$1kr9u$9@dont-email.me> |
| In reply to | #403344 |
On 2026-10-20 00:48, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-10-18 21:09, David Brown wrote: >>> On 18/10/2026 18:09, bart wrote: >>>> [...] >> [ declaration syntax ] >> >> (I just want to comment on a [not unimportant] detail...) >> >>> You need to give things in the right order, or use parentheses, to >>> get the right "type expression". It's just like any other kind of >>> expression. >>> The intention of the declaration syntax in C is that the declaration >>> order follows usage. [...] >> >> I think the first part is downplaying that languages typically indeed >> make a distinction between parenthesized expressions and declarations. >> Quite some other languages [not from the C-heritage] that I used all >> did not need to introduce "expression"-grouping for _declarations_ in >> the first place given their more consistent ways to declare entities. > > Just one quibble. C's declaration syntax *is* consistent. Its > rules are rigorously specified by the standard, particularly by > the grammar. Yes, sure. It's well defined and all that. - What I tried to express by that is that the building rules are not... - coherent, consistent? Well, I think on that level speaking about "inconsistency" is fine. But okay. I think we all know what we have with C's declaration syntax. (And we all, but maybe one, can live with it.) > > Many of us (myself included) don't particularly like it, but that > doesn't mean it's inconsistent. > > My own take on all this is that having declaration syntax follow usage > was a very clever idea, where "clever" is not necessarily a compliment. Well, to return the quibble, clever is a compliment (while "clever" in quotes is obviously not). :-) I don't consider it to have been a clever idea. (No quotes.) But I had mentioned that elsethread already before, and it's IMO not worth a dispute. > It was IMHO unsuccessful in the sense that it can lead to confusing > and overly complicated declarations. And that's the essence of the criticism, I think. > (Other languages don't have tools > corresponding to cdecl for much the same reason that Spanish-speaking > countries don't have spelling bees.) But it was extraordinarily > successful in the sense that, even if you think it was a bad idea, > it wasn't bad enough to keep C from becoming one of the most popular > programming languages. Undoubtedly. (It wasn't bad enough.) - Now imagine if it were better! Would have all folks using - what-do-I-know, say, Java - then have settled with "C"? - I'm just kidding. > > (I wonder if keeping the declaration-follows-use principle while > making "*" a postfix operator might have improved things.) I'm confused about the recent emphasis of such a change; it very much sounds to me like: "we have a problem lets try fixing it by changing something else [instead of addressing the problem]"; both are useless thoughts. (Yes, I understand that you think about it academically.) Janis
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-19 08:46 +0000 |
| Message-ID | <11b4le0$4fik$1@paganini.bofh.team> |
| In reply to | #403282 |
bart <bc@freeuk.com> wrote:
> On 18/10/2026 15:27, David Brown wrote:
>> On 18/10/2026 15:33, bart wrote:
>>> On 18/10/2026 12:22, David Brown wrote:
>
>>>> To me, that is just as much gibberish as the original C.
>>>
>>> That doesn't matter - the problem is not even knowing what it represents.
>>
>> That is, shall we say, a strange attitude. Gibberish (since that seems
>> to be the preferred term here) is gibberish, no matter the language or
>> representation, and is equally meaningless and useless.
>
> 'Gibberish' here refers to the representation, whether the type being
> described is made-up nonsense or real.
>
> You may want to know what some complex type is for many reasons, you
> don't necessarily need to understand what it means or why it was used.
>
> (For example I might come across a type in a C API that I want to
> convert to another language.)
You say that you had commercial product, but you are apparently not
aware of basic marketing principles. You do not win in the market
by making easy switch from your product to competitor product. You
may want to make it easy to switch _to_ your product. But you want
to make switching to competing products as hard as possible. Of
course there are constraints on this, in the process you do not want
to deteriorate quality of your product too much and you have finite
development resources.
Judging on this criteria you should admit that C is pretty good:
people wrote translators from various languages to C, but there
seem to be no success story going in opposite direction. C++
managed to take over nontrivial part of market previously occupied
by C, but they did this by embedding largish subset of C and by
massvie pileup of extra features.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-19 15:00 +0100 |
| Message-ID | <11b57p2$246h2$1@dont-email.me> |
| In reply to | #403308 |
On 19/10/2026 09:46, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 18/10/2026 15:27, David Brown wrote: >>> On 18/10/2026 15:33, bart wrote: >>>> On 18/10/2026 12:22, David Brown wrote: >> >>>>> To me, that is just as much gibberish as the original C. >>>> >>>> That doesn't matter - the problem is not even knowing what it represents. >>> >>> That is, shall we say, a strange attitude. Gibberish (since that seems >>> to be the preferred term here) is gibberish, no matter the language or >>> representation, and is equally meaningless and useless. >> >> 'Gibberish' here refers to the representation, whether the type being >> described is made-up nonsense or real. >> >> You may want to know what some complex type is for many reasons, you >> don't necessarily need to understand what it means or why it was used. >> >> (For example I might come across a type in a C API that I want to >> convert to another language.) > > You say that you had commercial product, but you are apparently not > aware of basic marketing principles. You do not win in the market > by making easy switch from your product to competitor product. You > may want to make it easy to switch _to_ your product. But you want > to make switching to competing products as hard as possible. Of > course there are constraints on this, in the process you do not want > to deteriorate quality of your product too much and you have finite > development resources. > > Judging on this criteria you should admit that C is pretty good: > people wrote translators from various languages to C, but there > seem to be no success story going in opposite direction. There are lots of reasons why not. C is popular as a compiler target because it is lower level than the source language. It has a weak type system which is easy to circumvent. It has 'goto'! (Many languages don't) There are well established, ubiquitous optimising compilers for it. Now, what would be the reasons for going the other way? There aren't any! (Well, some languages may have a feature to translate C programs into their syntax so that development can proceed in the new language. But the start point here is not C code being used for development, with some other HLL as an intermediate form.) So for that purpose, C is probably the most practical of current HLLs. Even if it is still not ideal and there are features which are awkward to express as C. C's UBs also get in the way. I've tried several times myself both with high-level and low-level generated C. (However, as a target language, I recently tried my own for that purpose, and it worked perfectly! Some features such as out-of-order definitions made it easier than C. Of course, my product does not have optimising compilers and very limited targets, due to not having an army of 1000s taking care of that as happens with C. But it shows that the creating such a suitable language design is not hard.) > C++ > managed to take over nontrivial part of market previously occupied > by C, but they did this by embedding largish subset of C and by > massvie pileup of extra features. So why IS C still around given that C++ compiler can build C programs, more or less?
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-10-19 16:55 +0100 |
| Message-ID | <11b5eic$26rua$1@dont-email.me> |
| In reply to | #403321 |
On 19/10/2026 15:00, bart wrote: > > So why IS C still around given that C++ compiler can build C programs, > more or less? Because it's typically less. I see C and C++ as very different.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-20 02:40 +0000 |
| Message-ID | <11b6kav$2kohl$1@dont-email.me> |
| In reply to | #403308 |
On Mon, 19 Oct 2026 08:46:58 -0000 (UTC), Waldek Hebisch wrote: > You do not win in the market by making easy switch from your product > to competitor product. You may want to make it easy to switch _to_ > your product. But you want to make switching to competing products > as hard as possible. “Vendor lock-in” -- that’s the old proprietary-software model. Customers are growing savvy to that sort of trick, which is why open-source software has become so popular. The most insidious form isn’t so much about the software, but about the proprietary data formats. If competitors’ software cannot read files containing the customers’ precious data accumulated over years of using a product, then the customer cannot switch to the competitor, even if they wanted to.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 17:24 +0300 |
| Message-ID | <20261018172446.00002d43@yahoo.com> |
| In reply to | #403261 |
On Sun, 18 Oct 2026 13:22:52 +0200 David Brown <david.brown@hesbynett.no> wrote: > > To me, that is just as much gibberish as the original C. No syntax > is going to make sense of it - no amount of "ref" or "func" or > pre-fix array notation will help. > [O.T.] Prefix array notation would not. But postfix * notation would, somewhat. It would be interesting to find out why designers of C, or of one of its ancestors decided that * as prefix is preferable to * as postfix. Were they afraid of confusion with usage of * as multiplication? Probably not, because confusion can arise about equally both for prefix and for postfix.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:58 +0200 |
| Message-ID | <11b2mqu$16mof$3@dont-email.me> |
| In reply to | #403271 |
On 18/10/2026 16:24, Michael S wrote: > On Sun, 18 Oct 2026 13:22:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> To me, that is just as much gibberish as the original C. No syntax >> is going to make sense of it - no amount of "ref" or "func" or >> pre-fix array notation will help. >> > > [O.T.] > Prefix array notation would not. But postfix * notation would, somewhat. > I can agree that notational changes might make it marginally easier to understand complex declarations - or mean that declarations could be marginally more complex while still being easily understood. But nothing can make Bart's exaggerated examples meaningful. > It would be interesting to find out why designers of C, or of one of its > ancestors decided that * as prefix is preferable to * as postfix. > Were they afraid of confusion with usage of * as multiplication? > Probably not, because confusion can arise about equally both for prefix > and for postfix. > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 18:26 +0300 |
| Message-ID | <20261018182627.00001934@yahoo.com> |
| In reply to | #403277 |
On Sun, 18 Oct 2026 16:58:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 18/10/2026 16:24, Michael S wrote: > > On Sun, 18 Oct 2026 13:22:52 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> To me, that is just as much gibberish as the original C. No syntax > >> is going to make sense of it - no amount of "ref" or "func" or > >> pre-fix array notation will help. > >> > > > > [O.T.] > > Prefix array notation would not. But postfix * notation would, > > somewhat. > > I can agree that notational changes might make it marginally easier > to understand complex declarations - or mean that declarations could > be marginally more complex while still being easily understood. But > nothing can make Bart's exaggerated examples meaningful. > > > It would be interesting to find out why designers of C, or of one > > of its ancestors decided that * as prefix is preferable to * as > > postfix. Were they afraid of confusion with usage of * as > > multiplication? Probably not, because confusion can arise about > > equally both for prefix and for postfix. > > > > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" > and similar expressions, felt "(p++)* = (q++)*" was unclear? > Why would it require parentheses?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 18:11 +0200 |
| Message-ID | <11b2r36$3pvda$8@dont-email.me> |
| In reply to | #403280 |
On 2026-10-18 17:26, Michael S wrote: > On Sun, 18 Oct 2026 16:58:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 18/10/2026 16:24, Michael S wrote: [...] >>> It would be interesting to find out why designers of C, or of one >>> of its ancestors decided that * as prefix is preferable to * as >>> postfix. Because it is more "natural" when read, easier to grasp? Simpler for compilers? More consistent if all other, especially standard operators known from daily use are used in prefix-form (-5, +42, !false, ~bitset) in expressions? I don't recall to have used any language with infix-expressions that would have their monadic operators defined in postfix form. The only exception was "C" (and C-oriented languages) with their special case of post-increment/post-decrement operators. (Think also about the quirk in C++ to define monadic postfix operators that require a syntactic dummy type argument). (In low-level RPN systems it may appear more "natural", but that just aside.) >>> Were they afraid of confusion with usage of * as >>> multiplication? Probably not, because confusion can arise about >>> equally both for prefix and for postfix. >> >> I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" >> and similar expressions, felt "(p++)* = (q++)*" was unclear? > > Why would it require parentheses? Not necessarily (I think). Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 19:32 +0300 |
| Message-ID | <20261018193201.00000b13@yahoo.com> |
| In reply to | #403283 |
On Sun, 18 Oct 2026 18:11:18 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-10-18 17:26, Michael S wrote: > > On Sun, 18 Oct 2026 16:58:38 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/10/2026 16:24, Michael S wrote: > [...] > >>> It would be interesting to find out why designers of C, or of one > >>> of its ancestors decided that * as prefix is preferable to * as > >>> postfix. > > Because it is more "natural" when read, easier to grasp? IMHO, no. >Simpler for compilers? 100% no. > More consistent if all other, especially standard > operators known from daily use are used in prefix-form (-5, +42, > !false, ~bitset) in expressions? Unary * is more similar in function to postfix operators like [] and () than to those you mentioned. > > I don't recall to have used any language with infix-expressions > that would have their monadic operators defined in postfix form. I am a Bear of Very Little Brain, and long words Bother Me. By chance, did you never use Pascal? > The only exception was "C" (and C-oriented languages) with their > special case of post-increment/post-decrement operators. (Think > also about the quirk in C++ to define monadic postfix operators > that require a syntactic dummy type argument). (In low-level RPN > systems it may appear more "natural", but that just aside.) > > >>> Were they afraid of confusion with usage of * as > >>> multiplication? Probably not, because confusion can arise about > >>> equally both for prefix and for postfix. > >> > >> I don't know why it is prefix. Maybe they were keen on "*p++ = > >> *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear? > >> > > > > Why would it require parentheses? > > Not necessarily (I think). > > Janis >
[toc] | [prev] | [next] | [standalone]
Page 20 of 24 — ← Prev page 1 … 18 19 [20] 21 22 … 24 Next page →
Back to top | Article view | comp.lang.c
csiph-web