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-28 02:27 -0400 |
| Articles | 20 on this page of 638 — 29 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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 20:53 -0700
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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:47 -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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:48 -0700
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 Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:13 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:17 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:34 +0100
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 22:11 -0700
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 Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:27 +0100
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 Rosario19 <Ros@invalid.invalid> - 2026-11-01 10:39 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-02 02:49 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 08:34 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 21:40 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:32 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 17:22 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 20:34 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 00:04 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 01:03 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 15:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:02 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:07 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 11:20 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:29 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 16:40 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 23:33 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 00:01 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 13:22 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 14:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 17:09 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:09 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 23:20 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:26 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 15:46 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 22:28 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 12:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 14:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 17:05 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 12:45 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 13:21 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 11:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:21 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 15:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:36 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 15:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 17:22 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 17:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 19:04 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:36 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:36 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 23:10 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 22:55 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 17:19 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 19:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:56 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 19:24 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:30 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 21:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 23:43 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 00:56 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:55 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-21 07:22 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 01:56 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:10 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:17 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 13:22 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:29 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:43 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-21 13:02 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 08:57 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-22 12:56 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 17:00 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 16:54 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 21:09 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-22 12:46 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-23 09:37 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-23 14:21 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-23 22:40 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-23 18:33 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-24 22:26 +0000
Modelling self/this? (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-25 00:56 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-24 16:38 -0700
Re: Taming The Switch-Statement steve g <Sgonedes1977@gmail.com> - 2026-10-28 01:13 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 22:33 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-24 12:58 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-24 21:42 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-25 10:51 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-25 13:54 -0700
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-25 20:30 +0000
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Blaine <cactus_DAC@yahoo.com> - 2026-10-26 10:28 -0600
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:26 -0400
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 15:50 +0100
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Blaine <cactus_DAC@yahoo.com> - 2026-10-28 10:34 -0600
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) fir <profesor.fir@gmail.com> - 2026-10-28 19:25 +0100
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) fir <profesor.fir@gmail.com> - 2026-10-28 19:35 +0100
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) fir <profesor.fir@gmail.com> - 2026-10-28 19:40 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-22 16:42 -0700
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-22 18:38 -0600
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-23 04:23 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-23 01:09 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 01:18 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 08:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 15:00 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-19 16:55 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:40 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:24 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:58 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:26 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 18:11 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 19:32 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:44 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-19 22:35 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:29 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 00:57 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:55 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:25 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 16:56 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:32 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:23 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:28 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:11 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 18:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-11-01 11:02 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-11-01 12:09 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-02 02:50 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-21 11:19 +0200
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-21 09:29 -0600
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-22 00:33 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 09:51 +0200
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 13:07 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 12:11 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 13:20 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 14:16 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:03 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 16:32 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 16:42 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-26 19:39 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 20:03 +0100
Re: Taming The Switch-Statement "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-28 05:56 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:06 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:21 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-28 14:24 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 15:52 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:45 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 17:00 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:06 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:11 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 19:03 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 20:39 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 19:59 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:13 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 20:56 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:37 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:40 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:46 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 11:51 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:18 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 21:49 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:23 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 14:25 -0700
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-27 22:39 +0000
Re: Taming The Switch-Statement Dan Purgert <dan@djph.net> - 2026-10-27 22:44 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-27 23:00 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 16:33 -0700
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-27 20:06 -0600
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-27 19:21 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 16:00 +0100
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-28 10:35 -0600
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 11:59 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 23:25 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 08:28 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 08:32 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-29 22:16 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-28 16:08 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 08:31 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 09:13 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 09:24 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-28 11:09 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:10 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-28 09:04 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:25 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 00:39 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 08:23 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-28 12:02 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-28 23:31 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-11-05 06:39 -0800
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-11-06 12:26 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-11-06 19:47 -0800
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:51 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:32 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:47 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:11 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:17 -0700
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:50 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-26 23:37 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:01 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:28 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:55 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 09:50 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 01:12 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:43 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 09:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 11:51 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 12:57 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:10 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 12:14 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:22 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:30 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 13:48 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-27 13:54 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:19 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:20 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:24 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 15:36 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 17:13 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 18:45 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-27 18:16 +0000
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 19:21 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 20:42 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-27 13:16 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 21:36 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-28 14:53 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 08:05 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-30 11:16 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:43 -0700
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:55 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 15:01 -0700
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-29 08:30 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-29 08:38 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-29 08:41 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-29 12:31 +0100
Re: Taming The Switch-Statement Rosario19 <Ros@invalid.invalid> - 2026-10-31 10:54 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-30 08:27 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-30 11:47 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 11:39 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-31 12:21 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 14:30 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-31 13:38 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 18:14 +0100
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-31 13:27 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) bartc <bc@freeuk.com> - 2026-10-30 15:36 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-30 12:04 -0700
Python is the universal language (Was: BizFuss (was Re: Taming The Switch-Statement)) gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-30 20:10 +0000
Re: BizFuss (was Re: Taming The Switch-Statement) Rosario19 <Ros@invalid.invalid> - 2026-10-31 11:36 +0100
Re: Taming The Switch-Statement "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-28 05:33 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-28 14:45 +0100
Re: Taming The Switch-Statement "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-29 07:34 -0700
Re: Taming The Switch-Statement steve g <Sgonedes1977@gmail.com> - 2026-10-28 02:27 -0400
Page 19 of 32 — ← Prev page 1 … 17 18 [19] 20 21 … 32 Next page →
| 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 14:21 +0200 |
| Message-ID | <11baaod$3te3v$2@dont-email.me> |
| In reply to | #403411 |
On 21/10/2026 13:33, bart wrote: > 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? What do you mean? There is an API in "dns.h" that uses typedefs such as "ip_addr_t" and "dns_found_callback". /Obviously/ those typedefs are also included in the header (or other headers included by "dns.h"). This is not something that I should have had to point out. > > Then it makes sense to use what they have provided. > It always makes sense to use the types provided.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 15:41 +0100 |
| Message-ID | <11baiuc$11ac$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: >> Here, one problem is that there are 3 types that I don't know and >> would have to look up. > > Incorrect. If I wanted to use function from a language that is not C and for which nobody has yet created a set of bindings, then I would have to investigate every single abstract type. Even then, I might find that a year later, 'err_t' has been defined to be something slightly different. Standard types are easier to deal with and more likely to be stable. >> 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". OK. I've just looked at several graphics libraries. Those have chosen to use predominantly standard C types for function return values. And standard C types for numeric arguments. Sometimes they might be prefixed, eg. GL_int, SDL_bool, probably as abstraction from the vagaries of standard C. It seems a trend to invent pointless extra types for everything. In C itself, there are about 35 denotations for integer types, and that's before you get into clock_t, time_t, offset_t and everything else. In general most boil down to one of i32 u32 i64 u64. So you can go over the top with abstraction. > Maybe on some targets (of this portable library), err_t is "signed > char". Why not define it on top of 'int'? Is it likely that large numbers of error codes are going to be stored within structs and arrays so that the size must be minimal? > It is also nice to know that it can be used in a switch, and cast to an > int for printf. How would you know that? I thought it was abstract! Maybe err_t is a small struct. > 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. I haven't said much about that. It is a struct so some username is needed. I renamed it to IP_addr in my example. But I'm not sure it needs the _t suffix. (Is it a thing now for every typedef name to need _t?) I notice however that the argument is a pointer: if ip_addr_t* values are commonly passed around, I would put an abstraction around that. (However that's partly because how my language works is different; to access a member of the struct, I don't need to know if the type of X is an actual struct or is a pointer to one; I write X.addr in both cases.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 17:36 +0200 |
| Message-ID | <11bam5q$1042$3@dont-email.me> |
| In reply to | #403419 |
On 21/10/2026 16:41, bart wrote: > On 21/10/2026 12:21, David Brown wrote: >> On 21/10/2026 03:04, bart wrote: > >>> Here, one problem is that there are 3 types that I don't know and >>> would have to look up. >> >> Incorrect. > > If I wanted to use function from a language that is not C and for which > nobody has yet created a set of bindings, then I would have to > investigate every single abstract type. So for a one-in-a-million use-cases, you would have to look up the type, such as by holding your mouse over the type, or pressing the "navigate to definition" shortcut in your IDE. I think it is better to optimise for the 999,999 other cases. Or you could use a real programming language, for which there is probably SWIG support. > > Even then, I might find that a year later, 'err_t' has been defined to > be something slightly different. Standard types are easier to deal with > and more likely to be stable. Libraries change types for good reasons. Support for one person using an obscure language who does not want to have to look up a typedef is not going to influence that decision. The world does not revolve around you and your unique needs and wants.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 15:37 +0000 |
| Message-ID | <11bam77$6at$1@reader2.panix.com> |
| In reply to | #403419 |
In article <11baiuc$11ac$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 21/10/2026 12:21, David Brown wrote: >> On 21/10/2026 03:04, bart wrote: >>> Here, one problem is that there are 3 types that I don't know and >>> would have to look up. >> >> Incorrect. > >If I wanted to use function from a language that is not C and for which >nobody has yet created a set of bindings, then I would have to >investigate every single abstract type. That is true of every programming language. >Even then, I might find that a year later, 'err_t' has been defined to >be something slightly different. Standard types are easier to deal with >and more likely to be stable. That is also true of every programming language. You can write some library in BartM or whatever language you like, and someone might write a binding to call it from, say, Pascal; and then a year down the road, you might change your compiler (since I gather you don't bother with a well-defined ABI, based on your not seeming to understand them) or change the type of something in a record, and you don't tell the Pascal person; now, they've got a program that will probably link against your library, and may even work correctly _most of the time_, but sometimes will just mysteriously crash. Welcome to programming. It's Hard(TM). Your answer to that appears to be to simply give up on abstraction; others work around it by writing tools (cf, `swig` or `bindgen` for Rust). >>> 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". > >OK. I've just looked at several graphics libraries. Those have chosen to >use predominantly standard C types for function return values. And >standard C types for numeric arguments. > >Sometimes they might be prefixed, eg. GL_int, SDL_bool, probably as >abstraction from the vagaries of standard C. > >It seems a trend to invent pointless extra types for everything. In C >itself, there are about 35 denotations for integer types, and that's >before you get into clock_t, time_t, offset_t and everything else. > >In general most boil down to one of i32 u32 i64 u64. Judicious use of types can render entire categories of errors unexpressible. Alexis King wrote a wonderful post about this, expressed using Haskell, but the general principles apply more broadly. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ >So you can go over the top with abstraction. Of course. Part of becoming a true software engineer is learning to find balance between too much abstraction and too little. >> Maybe on some targets (of this portable library), err_t is "signed >> char". > >Why not define it on top of 'int'? Is it likely that large numbers of >error codes are going to be stored within structs and arrays so that the >size must be minimal? Because maybe on some platforms it's more efficient to keep it in a `signed char`. Who knows? The point is you almost never need to care. >> It is also nice to know that it can be used in a switch, and cast to an >> int for printf. > >How would you know that? I thought it was abstract! Maybe err_t is a >small struct. Because the documentation about it tells you that you can: "The type `err_t` is used to represent errors. It can be cast to `int`." Really, this is table-stakes software development. >> 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. > >I haven't said much about that. It is a struct so some username is >needed. I renamed it to IP_addr in my example. Huh? Username? >But I'm not sure it needs the _t suffix. (Is it a thing now for every >typedef name to need _t?) > >I notice however that the argument is a pointer: if ip_addr_t* values >are commonly passed around, I would put an abstraction around that. > >(However that's partly because how my language works is different; to >access a member of the struct, I don't need to know if the type of X is >an actual struct or is a pointer to one; I write X.addr in both cases.) So does Rust. You're welcome. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 17:22 +0100 |
| Message-ID | <11baot1$3j98$1@dont-email.me> |
| In reply to | #403423 |
On 21/10/2026 16:37, Dan Cross wrote: > In article <11baiuc$11ac$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> On 21/10/2026 12:21, David Brown wrote: >>> On 21/10/2026 03:04, bart wrote: >>>> Here, one problem is that there are 3 types that I don't know and >>>> would have to look up. >>> >>> Incorrect. >> >> If I wanted to use function from a language that is not C and for which >> nobody has yet created a set of bindings, then I would have to >> investigate every single abstract type. > > That is true of every programming language. It's not clear what you mean by 'that'. But typically APIs are primarily expressed as C headers. With mainstream languages, somebody else has usually already done that work. >> Even then, I might find that a year later, 'err_t' has been defined to >> be something slightly different. Standard types are easier to deal with >> and more likely to be stable. > > That is also true of every programming language. Then it is also true that standard types will be more stable. > You can write some library in BartM or whatever language you > like, and someone might write a binding to call it from, say, > Pascal; and then a year down the road, you might change your > compiler (since I gather you don't bother with a well-defined > ABI, based on your not seeming to understand them You still don't get what an ABI is. > Welcome to programming. It's Hard(TM). Some things could be easier. Someone produces library (eg. DLL binary). That library exports a set of function names, but not a set of language-neutral function signatures. (And it will not export types, structs, enums etc needed to use the library.) Why not do that? Just a DLL having the C header API embedded within it would be a start! You don't need to source them separately, and they will always match in version. >> In general most boil down to one of i32 u32 i64 u64. > Judicious use of types can render entire categories of errors > unexpressible. Alexis King wrote a wonderful post about this, > expressed using Haskell, but the general principles apply more > broadly. If you want to use lots of abstraction then use a language with strict type systems that can back them up. Ada for example. But it's not a language I'd want to use. You can go too far down that path (look at the Frink programming language). >>> It is also nice to know that it can be used in a switch, and cast to an >>> int for printf. >> >> How would you know that? I thought it was abstract! Maybe err_t is a >> small struct. > > Because the documentation about it tells you that you can: "The > type `err_t` is used to represent errors. It can be cast to > `int`." Really, this is table-stakes software development. In this case it doesn't. It is an alias for 's8_t', which is itself an alias for 'int8_t' (which itself is probably an alias for 'signed char' within 'stdint.h'. What it does say however is that, if you define a certain macro, you can make err_t' any type you like. I don't know how that would work here; I assume it still has to be a numeric type, but it is not stated.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-21 17:21 +0000 |
| Message-ID | <aw6CS.179415$PnNb.56673@fx12.iad> |
| In reply to | #403424 |
bart <bc@freeuk.com> writes: >On 21/10/2026 16:37, Dan Cross wrote: >> You can write some library in BartM or whatever language you >> like, and someone might write a binding to call it from, say, >> Pascal; and then a year down the road, you might change your >> compiler (since I gather you don't bother with a well-defined >> ABI, based on your not seeming to understand > >You still don't get what an ABI is. Please, enlighten us. Be specific. What exactly does the term ABI mean to you?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 19:04 +0100 |
| Message-ID | <11baur1$63id$1@dont-email.me> |
| In reply to | #403425 |
On 21/10/2026 18:21, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 21/10/2026 16:37, Dan Cross wrote:
>
>>> You can write some library in BartM or whatever language you
>>> like, and someone might write a binding to call it from, say,
>>> Pascal; and then a year down the road, you might change your
>>> compiler (since I gather you don't bother with a well-defined
>>> ABI, based on your not seeming to understand
>>
>> You still don't get what an ABI is.
>
> Please, enlighten us. Be specific. What exactly
> does the term ABI mean to you?
It's what I have to deal with in a compiler back-end if I want to
support an FFI in a language.
It's not the same problem as using that FFI to write a set of bindings
corresponding with a particular API.
The latter problem needs to be solved even if there was no back-end and
no ABI to deal with (eg. transpiling to another language, or lowering to
some VM).
I don't why I'm bothering, since somebody will find another stick to
beat me over the head with or to somehow try to catch me out, but here
is an example of a function inside MSVCRT.DLL..
In the C API (ie. stdio.h) it will be expressed like this:
int puts(const char*);
In my FFI and in my syntax, it is expressed like this:
func puts (ichar)i32
So, this is 'creating a binding'. This can be done manually for this
one-off example. It's not perfect: on my platform, the C parameter has
'ref i8' type, but mine is more like 'ref u8'.
At this point, the ABI doesn't come into it.
That becomes relevant within the backend for a particular target and
platform.
So for this call:
puts(s)
the ABI for x64 running Windows will tell me that 's' must be passed in
rcx, the stack needs a shadow space, it needs to be 16-byte aligned, and
the 32-bit result is placed in eax.
For ARM64 running Linux (SYS V), then 's' is passed in x0, and the
result placed in w0. The stack will always properly aligned.
The only overlap in API/ABI may be to do with details of how structs may
be laid out in memory. But generally, C APIs will just follow the C
rules; I don't consider it an ABI thing. It would be something to deal
with even if no ABI existed and no native code was generated.
For my purposes, ABI is about calling conventions. ABI references may
cover a lot more (eg. for SYS V which likes to make everything as
complicated as possible).
So, now tell me what I've got wrong.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 18:38 +0000 |
| Message-ID | <11bb0rn$nbe$1@reader2.panix.com> |
| In reply to | #403426 |
In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 21/10/2026 18:21, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 21/10/2026 16:37, Dan Cross wrote: >> >>>> You can write some library in BartM or whatever language you >>>> like, and someone might write a binding to call it from, say, >>>> Pascal; and then a year down the road, you might change your >>>> compiler (since I gather you don't bother with a well-defined >>>> ABI, based on your not seeming to understand >>> >>> You still don't get what an ABI is. >> >> Please, enlighten us. Be specific. What exactly >> does the term ABI mean to you? > >It's what I have to deal with in a compiler back-end if I want to >support an FFI in a language. > >It's not the same problem as using that FFI to write a set of bindings >corresponding with a particular API. > >The latter problem needs to be solved even if there was no back-end and >no ABI to deal with (eg. transpiling to another language, or lowering to >some VM). > >I don't why I'm bothering, since somebody will find another stick to >beat me over the head with or to somehow try to catch me out, but here >is an example of a function inside MSVCRT.DLL.. > >In the C API (ie. stdio.h) it will be expressed like this: > > int puts(const char*); > >In my FFI and in my syntax, it is expressed like this: > > func puts (ichar)i32 > >So, this is 'creating a binding'. This can be done manually for this >one-off example. It's not perfect: on my platform, the C parameter has >'ref i8' type, but mine is more like 'ref u8'. > >At this point, the ABI doesn't come into it. > >That becomes relevant within the backend for a particular target and >platform. > >So for this call: > > puts(s) > >the ABI for x64 running Windows will tell me that 's' must be passed in >rcx, the stack needs a shadow space, it needs to be 16-byte aligned, and >the 32-bit result is placed in eax. > >For ARM64 running Linux (SYS V), then 's' is passed in x0, and the >result placed in w0. The stack will always properly aligned. > >The only overlap in API/ABI may be to do with details of how structs may >be laid out in memory. But generally, C APIs will just follow the C >rules; I don't consider it an ABI thing. It would be something to deal >with even if no ABI existed and no native code was generated. > >For my purposes, ABI is about calling conventions. ABI references may >cover a lot more (eg. for SYS V which likes to make everything as >complicated as possible). > >So, now tell me what I've got wrong. Wow. You really, truly, have no idea how any of this works. I don't even know where to begin. You just throw around words but have no idea what they mean in context. It's breathtaking, really. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 20:36 +0100 |
| Message-ID | <11bb47i$889c$1@dont-email.me> |
| In reply to | #403427 |
On 21/10/2026 19:38, Dan Cross wrote: > In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> So, now tell me what I've got wrong. > > Wow. You really, truly, have no idea how any of this works. I > don't even know where to begin. You just throw around words but > have no idea what they mean in context. > > It's breathtaking, really. And Wow, your reply is exactly the kind I expected! Of course, you're not going to tell me what API means versus ABI, and you're not going to answer my question about what I've got wrong. Because actually you don't know. This was apparent from things you've said in the past. I have actually wondered what you're doing here, and this appears to be it: being hostile, patronising, condescending and constantly taking the contrary view no matter what. In other words, being a troll.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 20:36 +0000 |
| Message-ID | <11bb7nk$noa$1@reader2.panix.com> |
| In reply to | #403431 |
In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 21/10/2026 19:38, Dan Cross wrote: >> In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >>> So, now tell me what I've got wrong. >> >> Wow. You really, truly, have no idea how any of this works. I >> don't even know where to begin. You just throw around words but >> have no idea what they mean in context. >> >> It's breathtaking, really. > >And Wow, your reply is exactly the kind I expected! > >Of course, you're not going to tell me what API means versus ABI, and >you're not going to answer my question about what I've got wrong. Honestly? No, I'm not. It's clear that if I tried, you would either not understand, or deliberately ignore it so you could blindly continue in your self-imposed ignorance. >Because actually you don't know. Umm..... >This was apparent from things you've said in the past. You know, it's one thing to be ignorant yourself. It's quite another to project that onto others. >I have actually wondered what you're doing here, and this appears to be >it: being hostile, patronising, condescending and constantly taking the >contrary view no matter what. > >In other words, being a troll. It's apparent that you really, truly, do not understand why so many others seem like they are "having a go" at you. I actually feel kind of bad for you. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 23:10 +0100 |
| Message-ID | <11bbd8k$bhfq$1@dont-email.me> |
| In reply to | #403435 |
On 21/10/2026 21:36, Dan Cross wrote: > In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> On 21/10/2026 19:38, Dan Cross wrote: >>> In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> >>>> So, now tell me what I've got wrong. >>> >>> Wow. You really, truly, have no idea how any of this works. I >>> don't even know where to begin. You just throw around words but >>> have no idea what they mean in context. >>> >>> It's breathtaking, really. >> >> And Wow, your reply is exactly the kind I expected! >> >> Of course, you're not going to tell me what API means versus ABI, and >> you're not going to answer my question about what I've got wrong. > > Honestly? No, I'm not. It's clear that if I tried, you would > either not understand, or deliberately ignore it so you could > blindly continue in your self-imposed ignorance. > >> Because actually you don't know. > > Umm..... > >> This was apparent from things you've said in the past. > > You know, it's one thing to be ignorant yourself. It's quite > another to project that onto others. I've seen zero evidence that you know anything about the matter. Just bluster. > >> I have actually wondered what you're doing here, and this appears to be >> it: being hostile, patronising, condescending and constantly taking the >> contrary view no matter what. >> >> In other words, being a troll. > > It's apparent that you really, truly, do not understand why so > many others seem like they are "having a go" at you. I actually > feel kind of bad for you. If you don't know this stuff, that would be perfectly fine, not everyone is into compilers. But refusing to admit that you mixed up API/ABI and instead gaslighting others into thinking they're the ones in the wrong is unacceptable and childish. I've looked at the 40 or so posts you've made in the last few days, half of them were replies to me, all unpleasant exchanges. This is just persecution, constantly attacking and belittling at the personal level. Maybe you're some sick fuck and and you get a kick out of it, then you should get help together with JP, that other wonderful person.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 22:55 +0000 |
| Message-ID | <11bbfte$dul$1@reader2.panix.com> |
| In reply to | #403436 |
In article <11bbd8k$bhfq$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 21/10/2026 21:36, Dan Cross wrote: >> In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> On 21/10/2026 19:38, Dan Cross wrote: >>>> In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> >>>>> So, now tell me what I've got wrong. >>>> >>>> Wow. You really, truly, have no idea how any of this works. I >>>> don't even know where to begin. You just throw around words but >>>> have no idea what they mean in context. >>>> >>>> It's breathtaking, really. >>> >>> And Wow, your reply is exactly the kind I expected! >>> >>> Of course, you're not going to tell me what API means versus ABI, and >>> you're not going to answer my question about what I've got wrong. >> >> Honestly? No, I'm not. It's clear that if I tried, you would >> either not understand, or deliberately ignore it so you could >> blindly continue in your self-imposed ignorance. >> >>> Because actually you don't know. >> >> Umm..... >> >>> This was apparent from things you've said in the past. >> >> You know, it's one thing to be ignorant yourself. It's quite >> another to project that onto others. > >I've seen zero evidence that you know anything about the matter. Just >bluster. And sadly, I've seen plenty of evidence confirming that you know nothing about it at all. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-10-22 17:19 +0200 |
| Message-ID | <11bd9h6$v6q2$1@dont-email.me> |
| In reply to | #403436 |
bart pisze: > On 21/10/2026 21:36, Dan Cross wrote: >> In article <11bb47i$889c$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> On 21/10/2026 19:38, Dan Cross wrote: >>>> In article <11baur1$63id$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> >>>>> So, now tell me what I've got wrong. >>>> >>>> Wow. You really, truly, have no idea how any of this works. I >>>> don't even know where to begin. You just throw around words but >>>> have no idea what they mean in context. >>>> >>>> It's breathtaking, really. >>> >>> And Wow, your reply is exactly the kind I expected! >>> >>> Of course, you're not going to tell me what API means versus ABI, and >>> you're not going to answer my question about what I've got wrong. >> >> Honestly? No, I'm not. It's clear that if I tried, you would >> either not understand, or deliberately ignore it so you could >> blindly continue in your self-imposed ignorance. >> >>> Because actually you don't know. >> >> Umm..... >> >>> This was apparent from things you've said in the past. >> >> You know, it's one thing to be ignorant yourself. It's quite >> another to project that onto others. > > I've seen zero evidence that you know anything about the matter. Just > bluster. > > >> >>> I have actually wondered what you're doing here, and this appears to be >>> it: being hostile, patronising, condescending and constantly taking the >>> contrary view no matter what. >>> >>> In other words, being a troll. >> >> It's apparent that you really, truly, do not understand why so >> many others seem like they are "having a go" at you. I actually >> feel kind of bad for you. > > > If you don't know this stuff, that would be perfectly fine, not everyone > is into compilers. > > But refusing to admit that you mixed up API/ABI and instead gaslighting > others into thinking they're the ones in the wrong is unacceptable and > childish. > > I've looked at the 40 or so posts you've made in the last few days, half > of them were replies to me, all unpleasant exchanges. > > This is just persecution, constantly attacking and belittling at the > personal level. Maybe you're some sick fuck and and you get a kick out > of it, then you should get help together with JP, that other wonderful > person. > > i dont know as to dan cross (only read some parts of side discusions here) but for sure some people here are somewhat trollish - note keith thompson and his sidekicks ;c but overally clc is quite decent and even this trolls are standable (mostly).. maybe its another advantage of writig with mistipes trolls not go into you way coz they dont understood what you write ;c clc is decent place coz honestly wide world has overally much worse level than here imo..especially if some opens co called 'media'..thats terrible thing
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-21 19:17 +0000 |
| Message-ID | <Pc8CS.30541$sfD.17299@fx03.iad> |
| In reply to | #403426 |
bart <bc@freeuk.com> writes: >On 21/10/2026 18:21, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 21/10/2026 16:37, Dan Cross wrote: >> >>>> You can write some library in BartM or whatever language you >>>> like, and someone might write a binding to call it from, say, >>>> Pascal; and then a year down the road, you might change your >>>> compiler (since I gather you don't bother with a well-defined >>>> ABI, based on your not seeming to understand >>> >>> You still don't get what an ABI is. >> >> Please, enlighten us. Be specific. What exactly >> does the term ABI mean to you? > >It's what I have to deal with in a compiler back-end if I want to >support an FFI in a language. Ah, so you don't know what an ABI is. An Application Binary Interface (ABI) is a low-level contract in computer science that defines how two compiled binary program modules interact with each other at the machine-code level. <snip discussions of the well known ABI requirements for windows x86_64 and linux on ARM64>[*] If you want your compiler to leverage existing libraries and/or code written in another language, you need to follow the platform ABI. It is that simple. Whether you like it or not, is completely irrelevent. [*] It is worth noting that the Windows x86 64-bit ABI requirement for the caller to reserve space for the callee to save registers (shadow store) is quite unusual in modern ABIs. The stack pointer alignment requirement should be obvious.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 20:49 +0100 |
| Message-ID | <11bb4vn$8hau$1@dont-email.me> |
| In reply to | #403430 |
On 21/10/2026 20:17, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 21/10/2026 18:21, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >>>> On 21/10/2026 16:37, Dan Cross wrote: >>> >>>>> You can write some library in BartM or whatever language you >>>>> like, and someone might write a binding to call it from, say, >>>>> Pascal; and then a year down the road, you might change your >>>>> compiler (since I gather you don't bother with a well-defined >>>>> ABI, based on your not seeming to understand >>>> >>>> You still don't get what an ABI is. >>> >>> Please, enlighten us. Be specific. What exactly >>> does the term ABI mean to you? >> >> It's what I have to deal with in a compiler back-end if I want to >> support an FFI in a language. > > Ah, so you don't know what an ABI is. > > An Application Binary Interface (ABI) is a > low-level contract in computer science that > defines how two compiled binary program modules > interact with each other at the machine-code level. OK. And how is my statement wrong? > If you want your compiler to leverage existing libraries > and/or code written in another language, you need to follow > the platform ABI. It is that simple. OK. And what have I said that contradicts that? I said it is something taken care of in the back end of my compiler; and it is a solved problem. It sends very much like both of you are confused about the difference between API and ABI! > Whether you like it or not, is completely irrelevent. Irrelevant to ... what? You're making about as much sense as the other chap. I was describing the problems of interfacing to APIs (with a 'P') and DC spouted some stuff about ABIs, which was not relevant to those problems. So, are you agreeing with me here that API issues and ABI issues are separate matters? > The stack pointer alignment requirement should be obvious. Not really: the ABI has to explicitly state it. In any case that is not relevant to the issues I was describing in working with APIs.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 18:56 +0000 |
| Message-ID | <11bb1si$2l4$1@reader2.panix.com> |
| In reply to | #403424 |
In article <11baot1$3j98$1@dont-email.me>, bart <bc@freeuk.com> wrote: >[snip] >You still don't get what an ABI is. This is the only interesting thing in your post, and only because it offers a key insight into your screeds: you use terms in a way that matches your own sense of what they mean, regardless of how they are used in the wider context. This is a good example: later, you said that ABIs are _only_ about calling conventions. For you, I'm sure that is true; for others who work in the field and use the consensus definitions, it is uninformed nonsense. No wonder you feel so attacked; what you believe you are saying is competely divorced from the way people read it. - Dan C.
[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]
Page 19 of 32 — ← Prev page 1 … 17 18 [19] 20 21 … 32 Next page →
Back to top | Article view | comp.lang.c
csiph-web