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-21 11:19 +0200 |
| Articles | 20 on this page of 446 — 23 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 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 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 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-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
Page 18 of 23 — ← Prev page 1 … 16 17 [18] 19 20 … 23 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 16:03 +0200 |
| Message-ID | <11b57vh$1kr9u$3@dont-email.me> |
| In reply to | #403319 |
On 2026-10-19 15:46, David Brown wrote: > On 19/10/2026 15:16, Janis Papanagnou wrote: >> [...] >> > There are a number of things that I don't particularly like about C's > declaration syntax, or where I think it would have been better if it > were different. But the "inside-to-outside" ordering is not one of > them. That is not because I think it is better or clearer than left-to- > right ordering, but because when I compare to, say, Pascal, it's not a > big issue for me. Far bigger are : > > 1. People put too much into a single type declaration, rather than > building types out of logical parts with a purpose and a name. Yes, that can be regularly observed, and not only in case of the declaration but generally; with known building blocks you can construct arbitrary complex expressions incrementally, so it might not appear as a problem at the time one writes it. But then parsing complex expressions - say, if that code is from another person or source - it gets difficult. (Topic reminds me Regexp expressions.) But also program composition in general is sometimes following an incremental growing process. Structuring is the key. > They > don't do it as much as Bart likes to pretend, but some people do it too > much for my liking. The language doesn't force you to do that - it's > programmer style. IMHO there is never a reason for a "pointer to an > array of function pointers taking int and returning void" - no matter > what syntax is used. Give a name to the function pointer type that > reflects the usage (/not/ a name that reflects the definition), and > build up from there. I fully agree. Where I obviously have a different valuation is that I saw in other languages' contexts that there's less issues with this topic. > > 2. Being able to declare variables and functions with different types in > the same declaration. Very occasionally, I find it convenient to > declare more than one variable at once - "int a, b, c;". It is rare in > my code - generally it is one variable with an initialiser (and perhaps > a comment) at a time. Absolutely the same for me. > But it is - IMHO - a bad thing that you can write > "int a, xs[20], *p, (*f)(void);" in one declaration. I agree. - But as opposed to other posters that's no serious problem; "if it hurts, just don't do it". > > Both of these are overcome by simply not writing code that way. (I should have read your post to the end before my previous statement.) > Obviously that is easy to achieve in my own code, but other people may > use a different style. And that's why companies instantiate coding standards. Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-19 22:28 +0100 |
| Message-ID | <11b6224$2ejik$1@dont-email.me> |
| In reply to | #403319 |
On 19/10/2026 14:46, David Brown wrote:
> On 19/10/2026 15:16, Janis Papanagnou wrote:
>> 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.
>>
>> The second part is, as I had understood C's history, the idea behind
>> how it got defined; needless to say that I think that was a bad idea.
>> But that's what we've got! If they had dropped that requirement/idea
>> the declaration syntax could have become "better" (more consistent,
>> less cryptic, less convoluted, clearer). Now, after half a century,
>> we just have to live with that, and folks who have "problems" with it
>> should better not touch this language (or maybe not doing programming
>> at all). The somewhat tragic aspect is that the "declaration follows
>> use" idea was (IIRC) intended to _simplify_ the understanding of its
>> concepts and use of the language; the consequences were seemingly not
>> valued correctly.
>>
> There are a number of things that I don't particularly like about C's
> declaration syntax, or where I think it would have been better if it
> were different. But the "inside-to-outside" ordering is not one of
> them. That is not because I think it is better or clearer than left-to-
> right ordering, but because when I compare to, say, Pascal, it's not a
> big issue for me. Far bigger are :
>
> 1. People put too much into a single type declaration, rather than
> building types out of logical parts with a purpose and a name. They
> don't do it as much as Bart likes to pretend, but some people do it too
> much for my liking. The language doesn't force you to do that - it's
> programmer style. IMHO there is never a reason for a "pointer to an
> array of function pointers taking int and returning void" - no matter
> what syntax is used.
Then you have a peculiar and restricted coding style.
(Funny that when I suggest that nested loop breaks are uncommon,
everyone says I'm wrong! Some even write 200-line made-up examples to
prove their point.)
These are two actual function pointer arrays from my projects (not C):
[]ref proc hosthandlers = ...
[pclnames.len]ref proc(pcl) px_handlertable
There is no reason to abstract away that function pointer type.
You probably do so in C /because/ the type involves * () and [] but have
somehow persuaded yourself that it just better that way.
Note that 'pcl' in my example /is/ a typedef; here it makes sense as it
is used in 100s of places. This function pointer occurs in only one place.
(The C version looks like: 'void (*name[N]))T)'. I used a tool and
transcribed it, then I double-checked and found I'd written '(*name)[N]'
not '(*name[N])'; I wouldn't have noticed.)
BTW what name would be given to such a function pointer type? There is
nothing obvious other than 'funcptr', but suppose there is more than one
in scope?
Something else strikes me about breaking up a complex type-decl sequence
into a chain of typedefs: if you take that list of typedefs, and rotate
it 90 degrees c/w, you have something that resembles the LTR representation!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-20 10:01 +0200 |
| Message-ID | <11b774o$2m8c9$3@dont-email.me> |
| In reply to | #403339 |
On 19/10/2026 23:28, bart wrote:
> On 19/10/2026 14:46, David Brown wrote:
>> On 19/10/2026 15:16, Janis Papanagnou wrote:
>>> 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.
>>>
>>> The second part is, as I had understood C's history, the idea behind
>>> how it got defined; needless to say that I think that was a bad idea.
>>> But that's what we've got! If they had dropped that requirement/idea
>>> the declaration syntax could have become "better" (more consistent,
>>> less cryptic, less convoluted, clearer). Now, after half a century,
>>> we just have to live with that, and folks who have "problems" with it
>>> should better not touch this language (or maybe not doing programming
>>> at all). The somewhat tragic aspect is that the "declaration follows
>>> use" idea was (IIRC) intended to _simplify_ the understanding of its
>>> concepts and use of the language; the consequences were seemingly not
>>> valued correctly.
>>>
>> There are a number of things that I don't particularly like about C's
>> declaration syntax, or where I think it would have been better if it
>> were different. But the "inside-to-outside" ordering is not one of
>> them. That is not because I think it is better or clearer than left-
>> to- right ordering, but because when I compare to, say, Pascal, it's
>> not a big issue for me. Far bigger are :
>>
>> 1. People put too much into a single type declaration, rather than
>> building types out of logical parts with a purpose and a name. They
>> don't do it as much as Bart likes to pretend, but some people do it
>> too much for my liking. The language doesn't force you to do that -
>> it's programmer style. IMHO there is never a reason for a "pointer to
>> an array of function pointers taking int and returning void" - no
>> matter what syntax is used.
>
> Then you have a peculiar and restricted coding style.
I don't believe so, no - at least, not compared to other code in my
field. It /is/ restricted, but so is everyone's coding style.
>
> (Funny that when I suggest that nested loop breaks are uncommon,
> everyone says I'm wrong! Some even write 200-line made-up examples to
> prove their point.)
I don't remember "everyone" saying you were wrong to say that nested
loop breaks are uncommon - in fact, I don't remember /anyone/ saying
that was wrong. A few people have suggested that they personally would
often find some kind of multi-level break useful, but I do not believe
many people think it is common, as a fraction of all C code they write.
(You really should cut down on the paranoia and the exaggerations.)
>
> These are two actual function pointer arrays from my projects (not C):
>
> []ref proc hosthandlers = ...
>
> [pclnames.len]ref proc(pcl) px_handlertable
>
> There is no reason to abstract away that function pointer type.
>
> You probably do so in C /because/ the type involves * () and [] but have
> somehow persuaded yourself that it just better that way.
Do you hear that whooshing noise? It is the sound of the point flying
far above your head.
Here is an example of some sensible function typedefs, all from
third-party code (so not my "peculiar" style)
struct tmrTimerControl;
typedef struct tmrTimerControl * TimerHandle_t;
typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
TimerHandle_t xTimerCreate( const char * const pcTimerName,
TickType_t xTimerPeriodInTicks,
UBaseType_t uxAutoReload,
void * pvTimerID,
TimerCallbackFunction_t pxCallbackFunction );
typedef void (*TaskFunction_t)( void * );
typedef BaseType_t (*TaskHookFunction_t)( void * );
typedef void (*altcp_err_fn)(void *arg, err_t err);
typedef void (*lwip_thread_fn)(void *arg);
typedef void (*tcpip_init_done_fn)(void *arg);
typedef void (*tcpip_callback_fn)(void *ctx);
typedef void (* sys_timeout_handler)(void *arg);
typedef void (*dns_found_callback)(const char *name,
const ip_addr_t *ipaddr, void *callback_arg);
Ask yourself why the typedefs are used. Look at the /names/. Those
last four are all from the same network stack library, and are all
typedefs for "void (*)(void*)". That function type could easily have
been written out in full in each declaration that used them. Yet the
actual functions using them specifically choose to use the type names
that are relevant at the time.
Do you really need me to spoon-feed you the reasons why this is all a
good idea? People name types because it makes their code clearer, more
robust, more flexible, more portable.
>
> Note that 'pcl' in my example /is/ a typedef; here it makes sense as it
> is used in 100s of places. This function pointer occurs in only one place.
I'm sorry, I had mistaken you for a programmer who wanted to write good,
clear programs. Naming things is not a shortcut to save keypresses.
>
> (The C version looks like: 'void (*name[N]))T)'. I used a tool and
> transcribed it, then I double-checked and found I'd written '(*name)[N]'
> not '(*name[N])'; I wouldn't have noticed.)
>
> BTW what name would be given to such a function pointer type? There is
> nothing obvious other than 'funcptr', but suppose there is more than one
> in scope?
I have no idea what your code is supposed to do, so I have no idea what
names would be good. Presumably you /do/ know what it is for - such as
what "pcl" means - so /you/ pick good names. Maybe "host_handler_fn" ?
>
> Something else strikes me about breaking up a complex type-decl sequence
> into a chain of typedefs: if you take that list of typedefs, and rotate
> it 90 degrees c/w, you have something that resembles the LTR
> representation!
>
If the details of the declaration syntax matter, you are doing it wrong.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 12:41 +0100 |
| Message-ID | <11b7k22$2v8e5$1@dont-email.me> |
| In reply to | #403370 |
On 20/10/2026 09:01, David Brown wrote:
> On 19/10/2026 23:28, bart wrote:
>> (Funny that when I suggest that nested loop breaks are uncommon,
>> everyone says I'm wrong! Some even write 200-line made-up examples to
>> prove their point.)
>
> I don't remember "everyone" saying you were wrong to say that nested
> loop breaks are uncommon - in fact, I don't remember /anyone/ saying
> that was wrong.
(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.)
>> There is no reason to abstract away that function pointer type.
>>
>> You probably do so in C /because/ the type involves * () and [] but
>> have somehow persuaded yourself that it just better that way.
>
> Do you hear that whooshing noise? It is the sound of the point flying
> far above your head.
>
> Here is an example of some sensible function typedefs, all from third-
> party code (so not my "peculiar" style)
>
> typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
>
> TimerHandle_t xTimerCreate( const char * const pcTimerName,
> TickType_t xTimerPeriodInTicks,
> UBaseType_t uxAutoReload,
> void * pvTimerID,
> TimerCallbackFunction_t pxCallbackFunction );
>
> typedef void (*lwip_thread_fn)(void *arg);
> typedef void (*tcpip_init_done_fn)(void *arg);
> typedef void (*tcpip_callback_fn)(void *ctx);
> typedef void (* sys_timeout_handler)(void *arg);
> typedef void (*dns_found_callback)(const char *name,
> const ip_addr_t *ipaddr, void *callback_arg);
This is the kind of C I find hard to read. There are lots of typedefs
but few uses of those typedefs that I can see, so I don't know how much
difference they make.
Except here:
typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
TimerHandle_t xTimerCreate( const char * const pcTimerName,
TickType_t xTimerPeriodInTicks,
UBaseType_t uxAutoReload,
void * pvTimerID,
TimerCallbackFunction_t pxCallbackFunction );
Without the typedef, I believe it would just be this:
TimerHandle_t xTimerCreate( const char * const pcTimerName,
TickType_t xTimerPeriodInTicks,
UBaseType_t uxAutoReload,
void * pvTimerID,
void (*pxCallbackFunction)(TimerHandle_t));
(I've left out the parameter name of the callback function, as I don't
believe it is that useful.
I've left in the regular parameter names, even though C doesn't need
them, but they are quite heavy - you don't really need those
Hungarian-style prefixes.)
Well, I guess this buys you one thing: the parameter name for the last
parameter is to the right of its type, rather than be inside it. But a C
expert should not be fazed by that.
Here is the same function as I might write it in an alternative syntax.
I've kept the same names, but changed case-style and removed prefixes
and suffixes. I've capitalised user-type names:
func TimerCreate( # (retain case if FFI import)
ichar timername,
Ticktype timerperiodinticks,
Ubasetype autoreload,
ref void timerid,
ref proc(Timerhandle) callbackfn)
In this form, it's hard to see what benefit a typedef would give for
that last parameter; it is simple enough.
> Ask yourself why the typedefs are used. Look at the /names/. Those
> last four are all from the same network stack library, and are all
> typedefs for "void (*)(void*)".
Until you mentioned it, I hadn't noticed. So typedef has done a good job
of hiding that useful fact! But looking more closely, it is the first
four of the last five.
Let's take one:
typedef void (*lwip_thread_fn)(void *arg);
That 'arg' is not much use for a start (other than being a hint that
this particular (...) is where the parameters go).
So, maybe this is used like this:
void F(lwip_thread_fn lwip_thread_callback);
Here you have two identifiers imparting the sort kind of information; a
tautology.
If that function pointer pattern is common, or recurs in a suite of
functions, I might also have used a typedef, but with a common name.
Then only one would be needed, say:
typedef void (*stack_callbackfn)(void);
I might have done the same in that alternate syntax as it would start to
get cluttery: 'ref proc(ref void)', but also in order to define that
common pattern in one place.
>> Note that 'pcl' in my example /is/ a typedef; here it makes sense as
>> it is used in 100s of places. This function pointer occurs in only one
>> place.
>
> I'm sorry, I had mistaken you for a programmer who wanted to write good,
> clear programs. Naming things is not a shortcut to save keypresses.
Isn't that one of the main uses of typedefs? So as to give a handy,
'euphonious' one-token alias to an elaborate typedef.
It also allows you to change the type in one place without having to
update hundreds of instances.
It also allows the type to be opaque.
Saving keypresses is bonus benefit, but if it is shorter, then it can
also help readability as other critical elements are not overshadowed.
So I'm not sure what objection you have to this particular use of it.
Here is the one place I do remember using typedef for a function pointer
(from an old project, not in C):
type fnptr = ref proc
repeat
(fnptr(pcptr^))^()
until stopped
It's used as a cast, but reason I have it is because with simple cast
syntax, which is 'T(X)', the meaning without it would be ambiguous (a
grammar issue that I might fix one day).
Rather than fallback to standard cast syntax (which is 'cast(X, T)'),
this was tidier.
>> BTW what name would be given to such a function pointer type?
> I have no idea what your code is supposed to do,
It's a table of function pointers! All sharing the same signature.
That's pretty generic. Is it really that hard to guess? You don't need
to know what they do, other than at some point they will be called as
handlertable[i](arg).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-20 14:58 +0200 |
| Message-ID | <11b7ogt$2m8c9$5@dont-email.me> |
| In reply to | #403374 |
On 20/10/2026 13:41, bart wrote:
> On 20/10/2026 09:01, David Brown wrote:
>> On 19/10/2026 23:28, bart wrote:
>
>>> (Funny that when I suggest that nested loop breaks are uncommon,
>>> everyone says I'm wrong! Some even write 200-line made-up examples to
>>> prove their point.)
>>
>> I don't remember "everyone" saying you were wrong to say that nested
>> loop breaks are uncommon - in fact, I don't remember /anyone/ saying
>> that was wrong.
>
> (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.)
It is correct that the idea of having a "loop-break" statement was
considered and quickly rejected by people looking at multi-level breaks.
It would be silly, when first making a language change to handle one
type of coding situation, to pick a special case when a more general
solution could be used. I don't think anyone was arguing that the
desire for breaking out of nested loops was /common/, but I don't think
many people felt breaking out of a switch in a loop was common either.
Both needs are relatively rare in general C coding.
But while the consensus is that a "loop-break" statement is not worth
adding to C, that is a completely different thing than claiming that
"everyone" said you were wrong to say nested loop breaks are common!
So - again - please cut the paranoia and exaggerations, and /read/ what
people write, rather than the conspiracies you imagine they write.
>
>>> There is no reason to abstract away that function pointer type.
>>>
>>> You probably do so in C /because/ the type involves * () and [] but
>>> have somehow persuaded yourself that it just better that way.
>>
>> Do you hear that whooshing noise? It is the sound of the point flying
>> far above your head.
>>
>> Here is an example of some sensible function typedefs, all from third-
>> party code (so not my "peculiar" style)
>>
>
>> typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
>>
>> TimerHandle_t xTimerCreate( const char * const pcTimerName,
>> TickType_t xTimerPeriodInTicks,
>> UBaseType_t uxAutoReload,
>> void * pvTimerID,
>> TimerCallbackFunction_t pxCallbackFunction );
>>
>
>> typedef void (*lwip_thread_fn)(void *arg);
>> typedef void (*tcpip_init_done_fn)(void *arg);
>> typedef void (*tcpip_callback_fn)(void *ctx);
>> typedef void (* sys_timeout_handler)(void *arg);
>> typedef void (*dns_found_callback)(const char *name,
>> const ip_addr_t *ipaddr, void *callback_arg);
>
>
> This is the kind of C I find hard to read. There are lots of typedefs
> but few uses of those typedefs that I can see, so I don't know how much
> difference they make.
Yes, sorry, I should have posted tens of thousands of lines of C code
using these. I'm sure that would have made things much clearer than a
couple of extracted examples.
But let us take a concrete example. These network functions are from
the LWIP network stack, which is designed to be used on small embedded
systems that may not have any kind of OS - so it uses call-backs for
asynchronous programming.
An example API function is this :
err_t dns_gethostbyname(const char *hostname, ip_addr_t *addr,
dns_found_callback found, void *callback_arg)
The returned "err_t" can be "ERR_OK" (indicating the "hostname" is in
the DNS cache and *addr is set to the IP), "ERR_ARG" for argument
errors, or "ERR_INPROGRESS" to indicate that the stack is looking up the
DNS name, and will call the callback when there is a final result or
timeout.
Without typedef's, that function signature would be something like :
signed char dns_gethostbyname(const char *hostname, struct ip_addr
*addr, void (*found)(const char *name, const struct ip_addr
*ipaddr, void *callback_arg), void *callback_arg);
Do you expect anyone to believe you if you claim this is easier to read
than the real declaration using typedefs? I'll believe you if you say
you find the original hard to read - but not if you claim the
"untypedef'ed" version is clearer.
The typedefs let you understand the code piece by piece.
A "dns_found_callback" is a callback function called when a dns lookup
has finished - that's clear from its name. It is called with arguments
the name that was looked up, the ip address that was found, and a
user-supplied extra argument that can be used as you want. That's
simple and clear.
The "dns_gethostbyname" function is a function to find a host's IP
address, given its name - that's clear from the name. It is called with
the name to look up, a pointer to a place to store the resulting IP
address, a callback function of type "dns_found_callback" if it can't
answer immediately, and a user-supplied extra argument for the callback
function. This is again, simple and clear.
>
> Except here:
>
> typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
>
> TimerHandle_t xTimerCreate( const char * const pcTimerName,
> TickType_t xTimerPeriodInTicks,
> UBaseType_t uxAutoReload,
> void * pvTimerID,
> TimerCallbackFunction_t pxCallbackFunction );
>
> Without the typedef, I believe it would just be this:
>
> TimerHandle_t xTimerCreate( const char * const pcTimerName,
> TickType_t xTimerPeriodInTicks,
> UBaseType_t uxAutoReload,
> void * pvTimerID,
> void (*pxCallbackFunction)(TimerHandle_t));
>
> (I've left out the parameter name of the callback function, as I don't
> believe it is that useful.
>
> I've left in the regular parameter names, even though C doesn't need
> them, but they are quite heavy - you don't really need those Hungarian-
> style prefixes.)
/C/ does not need the parameter names - /programmers/ need them, because
they tell you want they do. Omitting them is as smart as calling all
your functions "foo1", "foo2", etc., just because C does not require
sensible names.
The point of using typedefs here is that they make the xTimerCreate()
function declaration simpler and clearer, and it tells the programmer
what is going on. It tells the programmer that the parameter is a
TimerCallbackFunction - not just any old function that takes a
TimerHandle_t parameter. The programmer knows that a suitable argument
is their "flash_the_green_led" function, but not their
"initialise_timer" function that happens coincidentally to have the same
signature.
>
> Well, I guess this buys you one thing: the parameter name for the last
> parameter is to the right of its type, rather than be inside it. But a C
> expert should not be fazed by that.
>
> Here is the same function as I might write it in an alternative syntax.
>
> I've kept the same names, but changed case-style and removed prefixes
> and suffixes. I've capitalised user-type names:
>
> func TimerCreate( # (retain case if FFI import)
> ichar timername,
> Ticktype timerperiodinticks,
> Ubasetype autoreload,
> ref void timerid,
> ref proc(Timerhandle) callbackfn)
>
> In this form, it's hard to see what benefit a typedef would give for
> that last parameter; it is simple enough.
I am glad I don't have to work with your code - whatever language you
use. The number one skill for programmers is picking good names, and
you flumped that one.
>
>
>> Ask yourself why the typedefs are used. Look at the /names/. Those
>> last four are all from the same network stack library, and are all
>> typedefs for "void (*)(void*)".
>
> Until you mentioned it, I hadn't noticed. So typedef has done a good job
> of hiding that useful fact! But looking more closely, it is the first
> four of the last five.
It is not "hiding a useful fact" - it is abstracting away from an
unintended coincidence. My own preference is to use stronger types,
precisely so that things could not be mixed up. I'd have :
typedef struct { void * arg; } lwip_thread_arg;
typedef void (*lwip_thread_fn)(lwip_thread_arg * arg);
typedef struct { void * arg; } tcpip_init_done_arg;
typedef void (*tcpip_init_done_fn)(tcpip_init_done_arg * arg);
(If I were to go back in time and change things in C, I'd make "typedef"
define new types, not type aliases.)
>
> Let's take one:
>
> typedef void (*lwip_thread_fn)(void *arg);
>
> That 'arg' is not much use for a start (other than being a hint that
> this particular (...) is where the parameters go).
>
> So, maybe this is used like this:
>
> void F(lwip_thread_fn lwip_thread_callback);
>
> Here you have two identifiers imparting the sort kind of information; a
> tautology.
You don't need to duplicate the name when it is not helpful - and you
certainly should not do so when it is clearly wrong (a thread function
is not a callback function, even if the signatures match). A real
function signature using this type is :
sys_thread_t sys_thread_new(const char *name, lwip_thread_fn thread,
void *arg, int stacksize, int prio);
>
> If that function pointer pattern is common, or recurs in a suite of
> functions, I might also have used a typedef, but with a common name.
> Then only one would be needed, say:
>
> typedef void (*stack_callbackfn)(void);
/You/ might have written that, but it would be significantly worse code.
You are obsessed with the details of the syntax of the type, instead
of looking at what it represents and what it will mean in the code.
There can be occasional uses for "generic" names, like :
typedef void (*fp_void)(void);
just as there are uses for generic "int" types rather than types like
"size_t", "int32_t", "TickType_t", etc. But using well-named types
conveys vital information. Using badly named types, or re-using named
types inappropriately, makes code worse.
>
> I might have done the same in that alternate syntax as it would start to
> get cluttery: 'ref proc(ref void)', but also in order to define that
> common pattern in one place.
>
>>> Note that 'pcl' in my example /is/ a typedef; here it makes sense as
>>> it is used in 100s of places. This function pointer occurs in only
>>> one place.
>>
>> I'm sorry, I had mistaken you for a programmer who wanted to write
>> good, clear programs. Naming things is not a shortcut to save
>> keypresses.
>
> Isn't that one of the main uses of typedefs? So as to give a handy,
> 'euphonious' one-token alias to an elaborate typedef.
No, it should not be your main use of typedef - but it might
occasionally be a reason.
>
> It also allows you to change the type in one place without having to
> update hundreds of instances.
>
> It also allows the type to be opaque.
Now you are beginning to understand! Yes, these are two key reasons for
typedefs.
>
> Saving keypresses is bonus benefit, but if it is shorter, then it can
> also help readability as other critical elements are not overshadowed.
I agree - but that is a bonus, not an aim in itself. There is a balance
to be found between being too verbose, and not being explicit enough.
The "right" balance point depends very much on the context, the code,
and the target audience.
>
> So I'm not sure what objection you have to this particular use of it.
I don't object to having shorter aliases when appropriate. I object to
it as a prime motivation.
>
> Here is the one place I do remember using typedef for a function pointer
> (from an old project, not in C):
>
> type fnptr = ref proc
>
> repeat
> (fnptr(pcptr^))^()
> until stopped
>
> It's used as a cast, but reason I have it is because with simple cast
> syntax, which is 'T(X)', the meaning without it would be ambiguous (a
> grammar issue that I might fix one day).
>
> Rather than fallback to standard cast syntax (which is 'cast(X, T)'),
> this was tidier.
>
>>> BTW what name would be given to such a function pointer type?
>
>> I have no idea what your code is supposed to do,
>
> It's a table of function pointers! All sharing the same signature.
I can't see any use in a table of function pointers. I can see a use in
a table of event handlers, a table of timer callback functions, a table
of state machine state handlers, etc.
It's like saying you have an array of "int". No, you have an array of
the days in each month of the year, or an array of timestamps of
keypresses, or an array of the cost of different coffee mugs.
>
> That's pretty generic. Is it really that hard to guess? You don't need
> to know what they do, other than at some point they will be called as
> handlertable[i](arg).
>
That is why I guessed "host_handler_fn" as a name, but you snipped that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-20 17:05 -0700 |
| Message-ID | <11b8vl0$3g2gf$1@kst.eternal-september.org> |
| In reply to | #403377 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Without typedef's, that function signature would be something like :
>
> signed char dns_gethostbyname(const char *hostname, struct ip_addr
> *addr, void (*found)(const char *name, const struct ip_addr
> *ipaddr, void *callback_arg), void *callback_arg);
I might write that as:
signed char dns_gethostbyname(
const char *hostname,
struct ip_addr *addr,
void (*found)(
const char *name,
const struct ip_addr *ipaddr,
void *callback_arg
),
void *callback_arg
);
so the indentation and structure reflects the semantics. I find
that much clearer than your version. (I'm not commenting on the
merits of typedefs.)
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 12:45 +0200 |
| Message-ID | <11ba54b$3peq3$2@dont-email.me> |
| In reply to | #403393 |
On 21/10/2026 02:05, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Without typedef's, that function signature would be something like : >> >> signed char dns_gethostbyname(const char *hostname, struct ip_addr >> *addr, void (*found)(const char *name, const struct ip_addr >> *ipaddr, void *callback_arg), void *callback_arg); > > I might write that as: > > signed char dns_gethostbyname( > const char *hostname, > struct ip_addr *addr, > void (*found)( > const char *name, > const struct ip_addr *ipaddr, > void *callback_arg > ), > void *callback_arg > ); > > so the indentation and structure reflects the semantics. I find > that much clearer than your version. (I'm not commenting on the > merits of typedefs.) > Certainly the indentation makes the unpleasant non-typedef'ed version clearer. And /if/ I had to write that function signature without typedefs, I would structure it like you had - but I can't think of any reason I would ever have to do so.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 02:04 +0100 |
| Message-ID | <11b933e$3h3d0$1@dont-email.me> |
| In reply to | #403377 |
On 20/10/2026 13:58, David Brown wrote:
> On 20/10/2026 13:41, bart wrote:
> But let us take a concrete example. These network functions are from
> the LWIP network stack, which is designed to be used on small embedded
> systems that may not have any kind of OS - so it uses call-backs for
> asynchronous programming.
>
> An example API function is this :
>
> err_t dns_gethostbyname(const char *hostname, ip_addr_t *addr,
> dns_found_callback found, void *callback_arg)
>
> The returned "err_t" can be "ERR_OK" (indicating the "hostname" is in
> the DNS cache and *addr is set to the IP), "ERR_ARG" for argument
> errors, or "ERR_INPROGRESS" to indicate that the stack is looking up the
> DNS name, and will call the callback when there is a final result or
> timeout.
>
>
> Without typedef's, that function signature would be something like :
>
> signed char dns_gethostbyname(const char *hostname, struct ip_addr
> *addr, void (*found)(const char *name, const struct ip_addr
> *ipaddr, void *callback_arg), void *callback_arg);
>
>
> Do you expect anyone to believe you if you claim this is easier to read
> than the real declaration using typedefs? I'll believe you if you say
> you find the original hard to read - but not if you claim the
> "untypedef'ed" version is clearer.
Neither are great. But let's first lay them out better:
err_t
dns_gethostbyname(
const char *hostname,
ip_addr_t *addr,
dns_found_callback found,
void *callback_arg
);
Here, one problem is that there are 3 types that I don't know and would
have to look up. The long version at least has all the info in one place:
signed char
dns_gethostbyname(
const char *hostname,
struct ip_addr *addr,
void (*found)(const char *name, const struct ip_addr *ipaddr,
void *callback_arg),
void *callback_arg
);
That signed char return is unusual; why not 'int'? (How would you even
print an 'err_t' value anyway)?
That 'ip_addr_t' turns out to be a struct. For those I would use
typedefs anyway; I rarely use struct tags and you have to invent an
identifier in either case.
Then we come to the function pointer, which is a quite a chunky one, but
let's work with it. Here, I would question whether you really need those
types in there, and especially those names.
Presumably you have a regular function of your own with the same
signature? You anyway never directly 'call' this parameter with
arguments; you just pass it the address of your handler.
Or do you use that typedef as documentation?
Where does the info come from anyway; does the library export a suitable
typedef? In that case you might as well use it. But if not, info must
come from elsewhere.
Anyway with some tweaks in place, using the struct typedef and using an
inline function pointer type, it would look like this:
signed char
dns_gethostbyname(
const char *hostname,
IP_addr *addr,
void (*found)(char*, IP_addr*, void *),
void *arg
);
In this form, it is not wildly different from your short version.
So I would look at other ways of tidying up before resorting to
extraneous typedefs.
But here, there may well be an extra reason to use a callback typedef; I
don't have the full details.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 13:21 +0200 |
| Message-ID | <11ba78m$3peq3$3@dont-email.me> |
| In reply to | #403395 |
On 21/10/2026 03:04, bart wrote: > On 20/10/2026 13:58, David Brown wrote: >> On 20/10/2026 13:41, bart wrote: > >> But let us take a concrete example. These network functions are from >> the LWIP network stack, which is designed to be used on small embedded >> systems that may not have any kind of OS - so it uses call-backs for >> asynchronous programming. >> >> An example API function is this : >> >> err_t dns_gethostbyname(const char *hostname, ip_addr_t *addr, >> dns_found_callback found, void *callback_arg) >> >> The returned "err_t" can be "ERR_OK" (indicating the "hostname" is in >> the DNS cache and *addr is set to the IP), "ERR_ARG" for argument >> errors, or "ERR_INPROGRESS" to indicate that the stack is looking up >> the DNS name, and will call the callback when there is a final result >> or timeout. >> >> >> Without typedef's, that function signature would be something like : >> >> signed char dns_gethostbyname(const char *hostname, struct ip_addr >> *addr, void (*found)(const char *name, const struct ip_addr >> *ipaddr, void *callback_arg), void *callback_arg); >> >> >> Do you expect anyone to believe you if you claim this is easier to >> read than the real declaration using typedefs? I'll believe you if >> you say you find the original hard to read - but not if you claim the >> "untypedef'ed" version is clearer. > > Neither are great. But let's first lay them out better: > > err_t > dns_gethostbyname( > const char *hostname, > ip_addr_t *addr, > dns_found_callback found, > void *callback_arg > ); OK. I'd not write it that way, and I don't think it is better, but that's a subjective opinion. (As a note on layout, the original code is not as line-length restricted as a Usenet post, and the code has Doxygen comments. That means that there is additional comment information in header, and that the user documentation, which is the normal way to get details of the API, is generated html.) > > Here, one problem is that there are 3 types that I don't know and would > have to look up. Incorrect. There are three types that are not standard C types, but if you are using this function, you don't have to look them up. You generally don't need to know what they are - indeed, knowing their details can easily lead to writing poorer and less adaptable or portable code. Only information about the callback function type is of interest, and even then it is only marginal - you look it up once when writing an appropriate callback function, taking negligible effort compared to writing the code itself. And because it is a named type, you know immediately that your function is suitable for other use-cases of that specific named type, such as for related dns lookup APIs. > The long version at least has all the info in one place: > > signed char > dns_gethostbyname( > const char *hostname, > struct ip_addr *addr, > void (*found)(const char *name, const struct ip_addr *ipaddr, > void *callback_arg), > void *callback_arg > ); > > That signed char return is unusual; why not 'int'? (How would you even > print an 'err_t' value anyway)? It seems that yet again, you need an explanation of fundamental points of software development. Today's lesson is on "abstraction". It does not matter what type "err_t" is, underneath. What matters is what you can /do/ with it. It is a type that is returned by this function (and many others), and which can be compared to ERR_OK, ERR_INPROGRESS, and ERR_ARG. That's all you need to know to use it here. Maybe on some targets (of this portable library), err_t is "signed char". Maybe on others it is "int32_t". Maybe in a newer version of the library, it will be an enum. It is also nice to know that it can be used in a switch, and cast to an int for printf. The documentation for the type can give more or less detail about it. But it is /not/ the same as a "signed char". That is an implementation detail which you should not rely on, and it is better - clearer, safer, more portable, more maintainable - if you do not know what it is. (I didn't know, until looking it up for these posts.) You use the correct type, as documented. Or look at the "ip_addr_t" type. It happens, at the moment, to be a struct. But it might have been a union. The size and contents of the struct depend on details of how the library is built - whether it has support for ipv4, ipv6, or both. Maybe a future version will also support ipv8, or ipv5 (I've heard some people are trying to make an IP protocol that covers more than IPv4, but without most of the complicating additional features of IPv6). It is an abstract type - you use it without knowing the details. > > That 'ip_addr_t' turns out to be a struct. For those I would use > typedefs anyway; I rarely use struct tags and you have to invent an > identifier in either case. > > Then we come to the function pointer, which is a quite a chunky one, but > let's work with it. Here, I would question whether you really need those > types in there, and especially those names. > > Presumably you have a regular function of your own with the same > signature? You anyway never directly 'call' this parameter with > arguments; you just pass it the address of your handler. Yes, that is how callbacks work. > > Or do you use that typedef as documentation? You can certainly do that if you want, in a declaration of the function - but it would be unusual to do so in the definition. The typedef is used primarily when passing the function pointer around, or storing it (in a local variable, in a struct, or whatever). > > Where does the info come from anyway; does the library export a suitable > typedef? In that case you might as well use it. But if not, info must > come from elsewhere. Of course it "exports" the typedef - it is in one of the library's headers. > > Anyway with some tweaks in place, using the struct typedef and using an > inline function pointer type, it would look like this: > > signed char > dns_gethostbyname( > const char *hostname, > IP_addr *addr, > void (*found)(char*, IP_addr*, void *), > void *arg > ); > > In this form, it is not wildly different from your short version. Not wildly different, just worse by counter-productively removing the abstractions and appropriate type names, and uselessly cluttering the declaration with unnecessary detail. > > So I would look at other ways of tidying up before resorting to > extraneous typedefs. > > But here, there may well be an extra reason to use a callback typedef; I > don't have the full details. > >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 11:26 +0000 |
| Message-ID | <11ba7hv$4sh$1@reader2.panix.com> |
| In reply to | #403407 |
In article <11ba78m$3peq3$3@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 21/10/2026 03:04, bart wrote: >> [snip] >> Anyway with some tweaks in place, using the struct typedef and using an >> inline function pointer type, it would look like this: >> >> signed char >> dns_gethostbyname( >> const char *hostname, >> IP_addr *addr, >> void (*found)(char*, IP_addr*, void *), >> void *arg >> ); >> >> In this form, it is not wildly different from your short version. > >Not wildly different, just worse by counter-productively removing the >abstractions and appropriate type names, and uselessly cluttering the >declaration with unnecessary detail. ...and also removing the `const` qualifiers on the first two pointer arguments to `found`. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 12:33 +0100 |
| Message-ID | <11ba7v6$3skdl$1@dont-email.me> |
| In reply to | #403407 |
On 21/10/2026 12:21, David Brown wrote: > On 21/10/2026 03:04, bart wrote: >> Where does the info come from anyway; does the library export a >> suitable typedef? In that case you might as well use it. But if not, >> info must come from elsewhere. > > Of course it "exports" the typedef - it is in one of the library's headers. You could have said that in the first place. So it's not really a choice then is it? Then it makes sense to use what they have provided.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-20 19:24 +0000 |
| Message-ID | <11b8f5h$67l$1@reader2.panix.com> |
| In reply to | #403374 |
In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 20/10/2026 09:01, David Brown wrote:
>> On 19/10/2026 23:28, bart wrote:
>
>>> (Funny that when I suggest that nested loop breaks are uncommon,
>>> everyone says I'm wrong! Some even write 200-line made-up examples to
>>> prove their point.)
>>
>> I don't remember "everyone" saying you were wrong to say that nested
>> loop breaks are uncommon - in fact, I don't remember /anyone/ saying
>> that was wrong.
>
>(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.
Using that as an excuse not to provide a more general mechanism
because you already have a proposal for the specific case is
what I and others took you to task for. I find this ironic,
since you rail against things in C that you do not like, citing
the most ridiculous examples you can think of that do not show
up in actual programs, yet for something where it is pointed out
to you that your solution does not generalize, you claim that it
does not need to because ... the general case rarely shows up in
a real program.
>>> There is no reason to abstract away that function pointer type.
>>>
>>> You probably do so in C /because/ the type involves * () and [] but
>>> have somehow persuaded yourself that it just better that way.
>>
>> Do you hear that whooshing noise? It is the sound of the point flying
>> far above your head.
>>
>> Here is an example of some sensible function typedefs, all from third-
>> party code (so not my "peculiar" style)
>>
>> typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
>>
>> TimerHandle_t xTimerCreate( const char * const pcTimerName,
>> TickType_t xTimerPeriodInTicks,
>> UBaseType_t uxAutoReload,
>> void * pvTimerID,
>> TimerCallbackFunction_t pxCallbackFunction );
>>
>> typedef void (*lwip_thread_fn)(void *arg);
>> typedef void (*tcpip_init_done_fn)(void *arg);
>> typedef void (*tcpip_callback_fn)(void *ctx);
>> typedef void (* sys_timeout_handler)(void *arg);
>> typedef void (*dns_found_callback)(const char *name,
>> const ip_addr_t *ipaddr, void *callback_arg);
>
>This is the kind of C I find hard to read. There are lots of typedefs
>but few uses of those typedefs that I can see, so I don't know how much
>difference they make.
You again missed the entire point. You may not see many uses
of them, but as David says, the `typedef`s give you
domain-specific *names* understandable to the programmer: a
programmer can see the `sys_timeout_handler` type instantly know
that this has a different function than the,
`tcpip_callback_fn`, despite the having the same type.
The other point is that the ridiculous examples you make up to
illustrate your distaste for C declaration syntax basically do
not appear in real programs.
>[snip]
>I've left in the regular parameter names, even though C doesn't need
>them, but they are quite heavy - you don't really need those
>Hungarian-style prefixes.)
>
>Well, I guess this buys you one thing: the parameter name for the last
>parameter is to the right of its type, rather than be inside it. But a C
>expert should not be fazed by that.
>
>Here is the same function as I might write it in an alternative syntax.
>
>I've kept the same names, but changed case-style and removed prefixes
>and suffixes. I've capitalised user-type names:
>
>func TimerCreate( # (retain case if FFI import)
> ichar timername,
> Ticktype timerperiodinticks,
> Ubasetype autoreload,
> ref void timerid,
> ref proc(Timerhandle) callbackfn)
>
>In this form, it's hard to see what benefit a typedef would give for
>that last parameter; it is simple enough.
What is your point? Do you have one? If you don't want to use
C, don't use C.
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.
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.
If I were writing this from scratch in Rust, a language that has
generics, closures, and so sum types, I'd do the whole thing
differently; see the end for an example.
But I digress. The point here is, Bart, that alternatives exist
if you don't like C. You don't have to keep posting, over and
over again, in comp.lang.c of all places, about how oh so
terribly awful C is. If you don't want to program in C, simply
don't program in C.
>> Ask yourself why the typedefs are used. Look at the /names/. Those
>> last four are all from the same network stack library, and are all
>> typedefs for "void (*)(void*)".
>
>Until you mentioned it, I hadn't noticed. So typedef has done a good job
>of hiding that useful fact! But looking more closely, it is the first
>four of the last five.
>
>Let's take one:
>
> typedef void (*lwip_thread_fn)(void *arg);
>
>That 'arg' is not much use for a start (other than being a hint that
>this particular (...) is where the parameters go).
>
>So, maybe this is used like this:
>
> void F(lwip_thread_fn lwip_thread_callback);
I have no idea what you're trying to say here. The obvious (and
honestly, excusable) syntax error aside, what is F? It's a
function that, what, takes two function pointers?
The type defined by `lwip_thread_fn` is a pointer to a function
that takes a void pointer (`void *`) as its sole arugment, and
returns `void` (that is, has no meaningful return value).
Intuitively, the name implies that this is the function run as
some thread, so we'd pass it to a thread creation function. The
usual shape of those things is to give them a pointer to some
function to run in the new thread, and a pointer to some
arguments to be passed to that function. For example:
void
whatever(void *argp)
{
struct Args *args = argp;
while (keep_running()) {
// Do the thing the thread is supposed to do.
}
thread_exit(SUCCESS);
}
thread_t *
start_the_whatever_thread(void)
{
struct Args *args = malloc(sizeof(*args));
if (args == NULL) abort();
memset(args, 0, sizeof(*args));
args->whatever = something();
// etc...
thread_t *thr = thread_create(whatever, args);
if (thr == NULL) abort();
return thr;
}
Something could start this as:
thread_t *whatever_id = start_the_whatever_thread();
At some point later, if you want to wait for the thread to
exit, you'd run:
(void)thread_join(whatever_id);
Note this is decently complex behavior, but it's actually quite
intuitive from the name and the type.
>Here you have two identifiers imparting the sort kind of information; a
>tautology.
That's not what a tautology is.
>If that function pointer pattern is common, or recurs in a suite of
>functions, I might also have used a typedef, but with a common name.
Then you loose the domain specificity; you can't tell from the
name whether you need an LwIP thread, or a callback, or a
something run in a different thread, or just a plain 'ol
function you want to apply to run every now and again for a side
effect.
>Then only one would be needed, say:
>
> typedef void (*stack_callbackfn)(void);
>
>I might have done the same in that alternate syntax as it would start to
>get cluttery: 'ref proc(ref void)', but also in order to define that
>common pattern in one place.
I dunno. Sounds like you have no idea what the code that David
posted is meant to do. But that's a "you" problem.
>>> Note that 'pcl' in my example /is/ a typedef; here it makes sense as
>>> it is used in 100s of places. This function pointer occurs in only one
>>> place.
>>
>> I'm sorry, I had mistaken you for a programmer who wanted to write good,
>> clear programs. Naming things is not a shortcut to save keypresses.
>
>Isn't that one of the main uses of typedefs? So as to give a handy,
>'euphonious' one-token alias to an elaborate typedef.
>
>It also allows you to change the type in one place without having to
>update hundreds of instances.
>
>It also allows the type to be opaque.
The point is that the name you chose is meaningless to anyone
other than you. What's a PCL? Phase Control Line? Printer
Command Language? Photon Compressor Loop?
>Saving keypresses is bonus benefit, but if it is shorter, then it can
>also help readability as other critical elements are not overshadowed.
>
>So I'm not sure what objection you have to this particular use of it.
Have you ever written a large program that was maintained by
anyone other than yourself?
>Here is the one place I do remember using typedef for a function pointer
>(from an old project, not in C):
>
> type fnptr = ref proc
>
> repeat
> (fnptr(pcptr^))^()
> until stopped
>
>It's used as a cast, but reason I have it is because with simple cast
>syntax, which is 'T(X)', the meaning without it would be ambiguous (a
>grammar issue that I might fix one day).
>
>Rather than fallback to standard cast syntax (which is 'cast(X, T)'),
>this was tidier.
I can only guess at what this may mean. Hazarding a guess,
`pcptr` is a "pointer to a program counter", which is a
reference type to some type that represents some executable
memory location in the program. You then have a loop that runs
until "stopped" is true where you indirect the program counter
pointer, cast it to a pointer to a function, and then invoke
the function, right? One presumes you have the, "PC Pointer"
because it changes over time, otherwise, you'd just give
whatever it points to a name and call it.
More generally, I fail to see what this is trying to
demonstrate. If it's to show some sort of imagined superiority
over C, I don't see it; that's sort of thing is easy enough to
write:
typedef void (*fnptr)(void);
// Assume uintptr_t *pcptr is declared somewhere.
do {
((fnptr)*pcptr)();
} while (!stopped);
E.g.,
```
term% cat b.c
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
static void first(void);
typedef void (*fnptr)(void);
bool stopped = false;
uintptr_t pc = (uintptr_t)first;
uintptr_t *pcptr = &pc;
void
done(void)
{
printf("done\n");
stopped = true;
}
void
second(void)
{
printf("second\n");
*pcptr = (uintptr_t)done;
}
void
first(void)
{
printf("first\n");
*pcptr = (uintptr_t)second;
}
void
run(void)
{
do {
((fnptr)*pcptr)();
} while (!stopped);
}
int
main(void)
{
run();
return 0;
}
term% gcc-16 -std=c11 -pedantic -o b b.c
term% ./b
first
second
done
term%
```
>>> BTW what name would be given to such a function pointer type?
>
>> I have no idea what your code is supposed to do,
>
>It's a table of function pointers! All sharing the same signature.
>
>That's pretty generic. Is it really that hard to guess? You don't need
>to know what they do, other than at some point they will be called as
>handlertable[i](arg).
That part is fine.
What's utterly mystifying is what you are trying to show, if
anything, by posting it. Is this supposed to prove some kind of
point? Your code is not _a priori_ easier to understand than
the equivalent C code; if anything, it is harder to understand
because of your poorly chosen names.
- Dan C.
-->Rust implementation of Timers, mentioned above<--
As mentioned above, if I were providing the FreeRTOS timers API
in an alternative language, I'd write it differently from the
start. In particular, I'd use an enumeration to describe the
behavior with respect to repeating, and I'd use a closure to
obviate the need for the opaque id. Something that isn't easy
to express in the original API is a type of repeating timer that
waits for the initial period, and then repeats with some
different period.
Something like this:
```rust
pub mod timer {
use std::sync::atomic::{AtomicBool, Ordering};
use std::time::Duration;
/// Errors that may occur when working with timers.
#[derive(Clone, Copy, Debug)]
pub enum Error {
Running,
CantStop,
WontStop,
}
/// Describes the kind of a timer, as defined by its
/// periodicity.
///
/// A timer can either be a `OneShot` timer, which fires
/// once, after its timeout expires, or it may be a Repeating
/// timer, which will automatically reset after its handler
/// is run and continue firing at the rate defined by the
/// initial timeout, or it can be a periodic timer, that
/// will fire the first time at the initial timeout, and
/// then repeatedly a potentially different timeout. This
/// use case can be simulated by a OneShot timer that
/// creates a repeating Timer, but
///
/// Once started, Repeating and Periodic timers continue
/// firing until explicitly stopped.
#[derive(Clone, Copy, Debug)]
pub enum Kind {
OneShot,
Repeating,
Periodic(Duration),
}
/// A named timer, that is handled by the given callback.
pub struct Timer<'a, F> {
pub name: &'a str,
pub kind: Kind,
pub timeout: Duration,
callback: F,
running: AtomicBool,
// Whatever other innards...
// ...
}
/// A read-only "view" into the timer.
pub trait TimerView {
fn name(&self) -> &str;
fn kind(&self) -> Kind;
fn timeout(&self) -> Duration;
}
impl<'a, F: Fn(&dyn TimerView)> Timer<'a, F> {
/// Creates a new named timer of the given kind with an
/// initial timeout. When the timeout expires, it will
/// automatically invoke the given handler.
pub fn new(
name: &'a str,
timeout: Duration,
kind: Kind,
callback: F,
) -> Timer<'a, F> {
let running = AtomicBool::new(false);
Self {
name,
kind,
callback,
timeout,
running,
}
}
/// Starts the timer.
pub fn start(&self) -> Result<(), Error> {
if self.running.swap(true, Ordering::AcqRel) {
return Err(Error::Running);
}
self.arm(self.timeout)?;
Ok(())
}
/// Stops the timer.
///
/// Note that this inherently races with the timer firing,
/// and a timer event that occurs while we are disabling
/// the timer may still invoke `fired` after this returns.
///
/// Callers are advised to determine definitively that
/// there are no events pending for this timer before
/// destroying the `Timer` object.
pub fn stop(&self) -> Result<(), Error> {
let was_running = self.running.swap(false, Ordering::AcqRel);
if !was_running {
return Err(Error::WontStop);
}
self.disarm();
Ok(())
}
// Automatically called when the timeout fires.
//
// # Safety
//
// Nothing may be mutably borrowing a reference to the
// Timer object when this is called.
pub(super) unsafe fn fired(&self) -> Result<(), Error> {
if !self.running.load(Ordering::Acquire) {
return Ok(());
}
(self.callback)(self);
match self.kind {
Kind::OneShot => Ok(()),
Kind::Repeating => self.arm(self.timeout),
Kind::Periodic(period) => self.arm(period),
}
}
// Arranges for `self.fired(self)` to be called when
// the given timeout expires.
fn arm(&self, timeout: Duration) -> Result<(), Error> {
// Does whatever one does here to actually arm the
// timer (e.g., calls a HAL to actually program a
// physical timer to interrupt after the amount of
// time specified by `Duration`, for example).
// ...
Ok(())
}
// Disables an armed timer, so that it does not fire
// after this returns.
fn disarm(&self) -> Result<(), Error> {
// whatever one does here to disarm an active timer
// ...
Ok(())
}
}
impl<F> TimerView for Timer<'_, F> {
fn name(&self) -> &str { self.name }
fn kind(&self) -> Kind { self.kind }
fn timeout(&self) -> Duration { self.timeout }
}
}
```
One might use this with something like,
```
let value = 42;
let cb = move |timer: &dyn timer::TimerView| {
println!(
"Timer '{}' fired; value is {} and duration was {} ms",
timer.name(),
value,
timer.timeout().as_millis()
);
};
let timeout = std::time::Duration::from_millis(100);
let timer = timer::Timer::new("timer", timeout, timer::Kind::OneShot, &cb);
timer.start().expect("Timer started");
//... at some point the timer fires and prints,
// 'Timer 'timer1' fired; value is 42 and duration was 100 ms'
}
```
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 21:30 +0100 |
| Message-ID | <11b8j17$3btus$1@dont-email.me> |
| In reply to | #403383 |
On 20/10/2026 20:24, Dan Cross wrote: > In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: > The point is that the name you chose is meaningless to anyone > other than you. What's a PCL? Phase Control Line? Printer > Command Language? Photon Compressor Loop? Within the context of that application then it would be clear. You're just being overly hostile. (Within the app, PCL is the name of a bytecode language, and 'pcl' is a reference to a specific instruction. Next time I'll just use T for such examples, since the type is not relevant to the point. Although that didn't stop you seizing upon my F function.) >> Here is the one place I do remember using typedef for a function pointer >> (from an old project, not in C): >> >> type fnptr = ref proc >> >> repeat >> (fnptr(pcptr^))^() >> until stopped > More generally, I fail to see what this is trying to > demonstrate. Not much. It is just a rare example of my using aliases for function pointers. Because I suggested such aliases are often unnecessary and partly used in C to get around the fiddly type syntax that would arise.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-20 21:44 +0000 |
| Message-ID | <11b8nc4$9aq$1@reader2.panix.com> |
| In reply to | #403387 |
In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 20/10/2026 20:24, Dan Cross wrote: >> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >> The point is that the name you chose is meaningless to anyone >> other than you. What's a PCL? Phase Control Line? Printer >> Command Language? Photon Compressor Loop? > >Within the context of that application then it would be clear. You're >just being overly hostile. Not really. You are, I presume, posting that code to try and make some kind of point about how "readable" it is. But it's not readable unless you already know what it does. On the other hand, the code David posted _is_ readable, because it uses the language to encode domain-specific information into type names. >(Within the app, PCL is the name of a bytecode language, and 'pcl' is a >reference to a specific instruction. > >Next time I'll just use T for such examples, since the type is not >relevant to the point. Although that didn't stop you seizing upon my F >function.) You just don't get it. I suspect you have no idea what the `typedef`s David posted actually represent. >>> Here is the one place I do remember using typedef for a function pointer >>> (from an old project, not in C): >>> >>> type fnptr = ref proc >>> >>> repeat >>> (fnptr(pcptr^))^() >>> until stopped > >> More generally, I fail to see what this is trying to >> demonstrate. > >Not much. It is just a rare example of my using aliases for function >pointers. Because I suggested such aliases are often unnecessary and >partly used in C to get around the fiddly type syntax that would arise. Yeah, you really just don't get it. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 23:43 +0100 |
| Message-ID | <11b8qqg$3ejlp$1@dont-email.me> |
| In reply to | #403389 |
On 20/10/2026 22:44, Dan Cross wrote:
> In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>> On 20/10/2026 20:24, Dan Cross wrote:
>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>> The point is that the name you chose is meaningless to anyone
>>> other than you. What's a PCL? Phase Control Line? Printer
>>> Command Language? Photon Compressor Loop?
>>
>> Within the context of that application then it would be clear. You're
>> just being overly hostile.
>
> Not really. You are, I presume, posting that code to try and
> make some kind of point about how "readable" it is. But it's
> not readable unless you already know what it does.
What it does not relevant. This is simply defining an array of T. But
because T happens to be a function pointer, DB insists that an alias
must be created, and a new name invented.
Why? Probably because in C, the syntax for function pointers gets hairy.
> On the other hand, the code David posted _is_ readable, because
> it uses the language to encode domain-specific information into
> type names.
Maybe we should create aliases for function signatures more often then,
then we can encode that extra info.
So that instead of, for example:
void SomeFunc(int x, int y) {printf("%d %d\n", x, y);}
you do:
typedef void Take2Ints(int x, int y);
Take2Ints SomeFunc {printf("%d %d\n", x, y);}
If you have a suite of functions sharing the signature, then it might be
a good idea. But funnily enough, you never see this being done.
(I don't know if this is legal C; but it works fine with my compiler:
c:\m>type fred.c
#include <stdio.h>
typedef void Take2Ints(int x, int y);
Take2Ints SomeFunc{printf("%d %d\n", x, y);}
int main(void) { SomeFunc(10, 20); }
c:\m>bcc -r -q fred
10 20
)
> Yeah, you really just don't get it.
One of us doesn't get it.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 00:56 +0000 |
| Message-ID | <11b92j1$dhb$1@reader2.panix.com> |
| In reply to | #403390 |
In article <11b8qqg$3ejlp$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 20/10/2026 22:44, Dan Cross wrote:
>> In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>> On 20/10/2026 20:24, Dan Cross wrote:
>>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>
>>>> The point is that the name you chose is meaningless to anyone
>>>> other than you. What's a PCL? Phase Control Line? Printer
>>>> Command Language? Photon Compressor Loop?
>>>
>>> Within the context of that application then it would be clear. You're
>>> just being overly hostile.
>>
>> Not really. You are, I presume, posting that code to try and
>> make some kind of point about how "readable" it is. But it's
>> not readable unless you already know what it does.
>
>What it does not relevant. This is simply defining an array of T. But
>because T happens to be a function pointer, DB insists that an alias
>must be created, and a new name invented.
>
>Why? Probably because in C, the syntax for function pointers gets hairy.
I dunno; your syntax didn't seem any clearer to me.
>> On the other hand, the code David posted _is_ readable, because
>> it uses the language to encode domain-specific information into
>> type names.
>
>Maybe we should create aliases for function signatures more often then,
>then we can encode that extra info.
>
>So that instead of, for example:
>
> void SomeFunc(int x, int y) {printf("%d %d\n", x, y);}
>
>you do:
>
> typedef void Take2Ints(int x, int y);
>
> Take2Ints SomeFunc {printf("%d %d\n", x, y);}
>
>If you have a suite of functions sharing the signature, then it might be
>a good idea. But funnily enough, you never see this being done.
Yeah, you really don't get it.
You remind me of the guy at Google who objected to importing the
`std::` namespace in C++ into the default scope; "oh, so what;
we should all write ::std::whatever::foo<::std::blah>(...)?!" as
if finding the most stupidly extreme example was somehow a
useful technical argument. He also spent all his time on
mailing lists arguing about how everybody else Got It Wrong. He
got fired a few months later.
>(I don't know if this is legal C; but it works fine with my compiler:
>
> c:\m>type fred.c
> #include <stdio.h>
>
> typedef void Take2Ints(int x, int y);
>
> Take2Ints SomeFunc{printf("%d %d\n", x, y);}
>
> int main(void) { SomeFunc(10, 20); }
>
> c:\m>bcc -r -q fred
> 10 20
>)
Yeah, I gues running it through `gcc` is a really heavy lift.
<eyeroll>
>> Yeah, you really just don't get it.
>
>One of us doesn't get it.
I'm glad you can admit it.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 02:39 +0100 |
| Message-ID | <11b954e$3hjvi$1@dont-email.me> |
| In reply to | #403394 |
On 21/10/2026 01:56, Dan Cross wrote: > In article <11b8qqg$3ejlp$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> On 20/10/2026 22:44, Dan Cross wrote: >>> In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>> On 20/10/2026 20:24, Dan Cross wrote: >>>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>> >>>>> The point is that the name you chose is meaningless to anyone >>>>> other than you. What's a PCL? Phase Control Line? Printer >>>>> Command Language? Photon Compressor Loop? >>>> >>>> Within the context of that application then it would be clear. You're >>>> just being overly hostile. >>> >>> Not really. You are, I presume, posting that code to try and >>> make some kind of point about how "readable" it is. But it's >>> not readable unless you already know what it does. >> >> What it does not relevant. This is simply defining an array of T. But >> because T happens to be a function pointer, DB insists that an alias >> must be created, and a new name invented. >> >> Why? Probably because in C, the syntax for function pointers gets hairy. > > I dunno; your syntax didn't seem any clearer to me. Yeah, the C is so much clearer. Of course, you would all lie through your teeth anyway before you'd admit mine might be simpler. I've just defined three entities: a variable, a function pointer, and a function, in both my syntax and in C's. Here are the first tokens of the C versions: int int int Can you guess which one is which yet? Here are the first three tokens in my syntax: int func ref Any easier? This is like PL Design 101.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-20 18:55 -0700 |
| Message-ID | <11b963d$3h5oi$2@kst.eternal-september.org> |
| In reply to | #403397 |
bart <bc@freeuk.com> writes:
[...]
> Yeah, the C is so much clearer. Of course, you would all lie through
> your teeth anyway before you'd admit mine might be simpler.
[...]
You preemptively accuse someone of being a liar, and then you wonder
why people are hostile to you.
Tone down the insults and hyperbole.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-10-21 07:22 +0000 |
| Message-ID | <11b9p89$1euuv$1@news.xmission.com> |
| In reply to | #403398 |
In article <11b963d$3h5oi$2@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >bart <bc@freeuk.com> writes: >[...] >> Yeah, the C is so much clearer. Of course, you would all lie through >> your teeth anyway before you'd admit mine might be simpler. >[...] > >You preemptively accuse someone of being a liar, and then you wonder >why people are hostile to you. > >Tone down the insults and hyperbole. The Lord and Master has spoken. All must comply with His dictates. -- Just like Donald Trump today, Jesus Christ had a Messiah complex. And, in fact, the similarities between the two figures are quite striking. For example, both have a ragtag band of followers, whose faith cannot be shaken.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 01:56 +0000 |
| Message-ID | <11b964s$8a9$1@reader2.panix.com> |
| In reply to | #403397 |
In article <11b954e$3hjvi$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 21/10/2026 01:56, Dan Cross wrote: >> In article <11b8qqg$3ejlp$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> On 20/10/2026 22:44, Dan Cross wrote: >>>> In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>>> On 20/10/2026 20:24, Dan Cross wrote: >>>>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>>>> >>>>>> The point is that the name you chose is meaningless to anyone >>>>>> other than you. What's a PCL? Phase Control Line? Printer >>>>>> Command Language? Photon Compressor Loop? >>>>> >>>>> Within the context of that application then it would be clear. You're >>>>> just being overly hostile. >>>> >>>> Not really. You are, I presume, posting that code to try and >>>> make some kind of point about how "readable" it is. But it's >>>> not readable unless you already know what it does. >>> >>> What it does not relevant. This is simply defining an array of T. But >>> because T happens to be a function pointer, DB insists that an alias >>> must be created, and a new name invented. >>> >>> Why? Probably because in C, the syntax for function pointers gets hairy. >> >> I dunno; your syntax didn't seem any clearer to me. > >Yeah, the C is so much clearer. Of course, you would all lie through >your teeth anyway before you'd admit mine might be simpler. Oh, grow up. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 18 of 23 — ← Prev page 1 … 16 17 [18] 19 20 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web