Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-21 09:29 -0600 |
| Articles | 20 on this page of 470 — 24 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:48 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 12:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:09 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:34 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:13 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:52 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:16 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 20:47 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 22:38 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 11:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 03:50 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:59 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:28 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:05 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 14:35 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 18:31 +0200
Re: Taming The Switch-Statement Bob Duff <invalid@invalid.com> - 2026-10-19 19:38 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 17:03 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:45 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 05:01 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 00:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:34 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:18 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-18 23:51 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:56 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 19:37 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 23:56 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:15 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:33 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-19 08:47 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 18:28 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 16:11 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:02 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:18 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 02:53 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 12:22 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 19:39 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 18:23 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:36 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 21:03 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 10:30 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-17 10:54 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-19 23:41 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:18 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:38 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 19:25 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 00:16 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 16:10 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 08:34 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 21:40 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:32 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 17:22 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 20:34 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 00:04 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 01:03 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 15:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:02 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:07 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 11:20 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:29 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 16:40 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 23:33 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 00:01 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 13:22 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 14:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 17:09 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:09 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 23:20 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:26 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 15:46 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 22:28 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 12:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 14:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 17:05 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 12:45 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 13:21 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 11:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:21 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 15:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:36 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 15:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 17:22 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 17:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 19:04 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:36 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:36 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 23:10 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 22:55 +0000
Re: Taming The Switch-Statement 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 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 01:18 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 08:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 15:00 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-19 16:55 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:40 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:24 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:58 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:26 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 18:11 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 19:32 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:44 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-19 22:35 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:29 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 00:57 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:55 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:25 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 16:56 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:32 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:23 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:28 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:11 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 18:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-21 11:19 +0200
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-21 09:29 -0600
Page 17 of 24 — ← Prev page 1 … 15 16 [17] 18 19 … 24 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 00:04 +0100 |
| Message-ID | <11b67mj$2gqlv$1@dont-email.me> |
| In reply to | #403343 |
On 19/10/2026 23:35, Janis Papanagnou wrote: > On 2026-10-19 19:22, Dan Cross wrote: >> In article <11b500f$216c4$1@dont-email.me>, bart <bc@freeuk.com> wrote: > [...] >>> I also never used Algol68; I'd only seen it in a book. >> >> You said yourself you modeled your language on Algol68; whether >> you had used it or not is irrelevant. > > It may be worth the observation we could make here in the flood of > bart's posts; most (if not all) features or ideas he seems to have > adopted only on a lexical or syntactical level. Given what he gave > as examples I have strong doubts that this should be attributed to > Algol 68 in its "whole glory". - Syntactical inspiration; maybe. - > More than that? - I'd be astonished. Syntax was part-influenced by Algol 60 (DEC), Algol 68, Pascal, Fortran and Ada. It was also case-insensitive (most of them). And expression-based (Algol 68). Type system and semantics were mine and befitted a low level systems language running on and for very low-end hardware.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-20 01:03 +0000 |
| Message-ID | <11b6ekh$d2qm$1@paganini.bofh.team> |
| In reply to | #403314 |
bart <bc@freeuk.com> wrote:
>
> OK. But they HAD to create C? There were quite a few languages in the
> early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL
> and B. So why a new one?
You ignore fact that Ritche wanted reasonably fast code from
very simple compiler. Around 1970 that meant in particular
pointer arithmetic. Also, address operator allowed simple
interfacing between pointer-oriented code and use of variables.
It is hard to imagine getting similar effect with different
semantics. IIUC C was not the only language going in this
direction, but mainstream languages were different.
Concerning specific languages, there was FORTRAN 66, it had 'do'
loop as only structured control structure, there rest of control
was via gotos. And the only data structure were array. Without
extentions FORTRAN 66 was unsuitable for system work, and arguably
for non-numeric work even early C was nicer than FORTRAN 66.
For reasonable speed FORTRAN 66 needed an optimizer which led
to compiler too big to run on a small machine.
PL/I had most needed features. But PL/I was a big language,
to run on small machine they would have to take tiny subset
and then add extentions. Basicaly they would end up with a
language which is very far from PL/I.
Similarly, BCPL was too complicated, B and C were simplifications
and adaptations small machine.
I think that Pascal was too late: nominally it was created earlier
but I think that it was available to Bell Labs only after they
did initial work leading to C. And Pascal shared problem of
speed on small machines. Note that later UCSD Pascal which
run on micros compiled to interpreted bytecode, which significantly
reduced performance.
> FORTRAN syntax looked nothing like C! Unless you mean the general
> pattern of 'INTEGER A, B' which was shared by half of all languages.
I think more pattern of
INTEGER A(20), B
which has similar structure to C variable declarations. Of course,
FORTRAN had no pointers (and structures or unions), so Ritche had
to invent syntax for them.
IMO C suffers because typedef was added late in the game and
function prototypes are much later. Prototypes need types and
to get it one needs "hole" in variable declaration. Where the
hole should be is specified by the C syntax, but placement of
hole is probably least clear aspect of declarations.
IMO C declaration syntax was a mistake, but as real life shows
it was not a fatal mistake, people can adapt. Note that in
eighties C position among system languages was not as strong as
it is now. In particular there were quite decent Modula 2
compilers and ony many machines Pascal was competitive too.
But there were no mass migration from C to other languages.
In fact C was gaining use and other languages lost their position.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-20 02:44 +0000 |
| Message-ID | <11b6ki2$2kohl$2@dont-email.me> |
| In reply to | #403360 |
On Tue, 20 Oct 2026 01:03:15 -0000 (UTC), Waldek Hebisch wrote: > Similarly, BCPL was too complicated, B and C were simplifications > and adaptations small machine. BCPL was a very bare-bones language -- it didn’t even have structs, or even much in the way of types. Every variable was an “integer”. Naming the variable didn’t return its value, but its address; you had to use an explicit “dereference” operator to get the variable value. C was certainly a more complicated language than BCPL.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 15:11 +0100 |
| Message-ID | <11b7sqn$32pr5$1@dont-email.me> |
| In reply to | #403360 |
On 20/10/2026 02:03, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>>
>> OK. But they HAD to create C? There were quite a few languages in the
>> early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of course BCPL
>> and B. So why a new one?
>
> You ignore fact that Ritche wanted reasonably fast code from
> very simple compiler.
According to DC's quote from HOPL, it was also more fun to create a new
language.
> PL/I had most needed features. But PL/I was a big language,
> to run on small machine they would have to take tiny subset
> and then add extentions. Basicaly they would end up with a
> language which is very far from PL/I.
There were PL/360 and PL/M, although those were more specific, more
'machine-oriented' languages. (I implemented one for PDP10 but it was a
port of a systems language from a GEC machine.)
Anyway, a more general subset could have been used.
> Similarly, BCPL was too complicated, B and C were simplifications
> and adaptations small machine.
>
> I think that Pascal was too late: nominally it was created earlier
> but I think that it was available to Bell Labs only after they
> did initial work leading to C. And Pascal shared problem of
> speed on small machines. Note that later UCSD Pascal which
> run on micros compiled to interpreted bytecode, which significantly
> reduced performance.
It would not have been hard to use Pascal as a starting point for a
workable systems language. Wirth wouldn't have approved, but his
languages were too pure, too academic; some of us had things we needed
to get done!
Here I mean adapting Pascal for a competing systems language.
In my hands some aspects would be simplified (eg. no nested functions,
no closures), thus making it easier to generate decent code with a
simple compiler.
>
>> FORTRAN syntax looked nothing like C! Unless you mean the general
>> pattern of 'INTEGER A, B' which was shared by half of all languages.
>
> I think more pattern of
>
> INTEGER A(20), B
>
> which has similar structure to C variable declarations.
OK. That was typical for the time. But in Fortran it didn't get much
more complicated than that. Maybe 2D arrays and so on.
> Of course,
> FORTRAN had no pointers (and structures or unions), so Ritche had
> to invent syntax for them.
There were three languages from that era that I know had pointers or
references, and which allowed composing arbitrary types with arrays and
pointers, two of which were Algol68 and Pascal.
Both used a 100% LTR form.
The other was C. There, several choices were made:
* To start with that Fortran style except that [] are used
* To decree that that 'A[20]' syntax is supposed to match indexing of
A as it might appear in an expression
* To introduce "*" as a prefix dereference operator in expressions ...
* ... which then means that a prefix "*" appears in the declaration too
* A further complication was to allow function pointers within that a
declaration list
* Yet one more which came later was to add 'const', where placement now
gets confusing
But to stay with pointers, take this expression:
*A[i]
C precedence rules mean this is parsed as *(A[i]), which means that a
type written as 'T *A[N]' must be an array of pointers to T (I had to
think for a few seconds!).
But suppose you wanted a pointer to array of T? The expression for that
would be:
(*A)[i]
And so the declaration has to be 'T (*A)[N]' too.
So it is unfortunate that parentheses used to control precedence in an
expression now also have to appear in type declarations (where they are
often next to () used for parameter lists, for further confusion).
==============================================
So, what would have happened with a postfix deref op? (Ignore whether
'*' would still be a good choice.) My first example would be this:
A*[i]
Here, it would mean that A is dereferenced, then indexed; A must then be
a pointer to an array of T.
But suppose we wanted the original array of pointers to T, where you
index first then dereference. That is written like this:
A[i]*
You simply swap the order of [] and *.
So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating
array/pointer and pointer/array, both within expressions and within
type-declarations.
How about that? Further, most of the type-spec is now LTR; only the
base-type has to stay on the left. Access terms in expressions will be
fully LTR.
> IMO C suffers because typedef was added late in the game and
> function prototypes are much later. Prototypes need types and
> to get it one needs "hole" in variable declaration. Where the
> hole should be is specified by the C syntax, but placement of
> hole is probably least clear aspect of declarations.
I thought that 'hole' was where 'int A[10]' mean one thing in normal
declaration but another within a parameter list.
> IMO C declaration syntax was a mistake, but as real life shows
> it was not a fatal mistake, people can adapt.
A mistake that could so easily have been avoid by choosing a different
precedence as shown above. Did none of the thousand people working at
Bell Labs (according to a comment in DC's follow-ip) spot this and say
anything?
Had no-one even glanced at a Pascal spec, if there was no working copy?
It would have transformed C type syntax.
(ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
been added. This could have been done 50 years ago, with the original
eventually deprecated.
But this is a common theme of mine whether I perceive a problem that
people grudgingly admit might not be idea. But nothing was ever done to
fix it even after decades.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-20 17:02 +0200 |
| Message-ID | <11b7vqd$2m8c9$6@dont-email.me> |
| In reply to | #403379 |
On 20/10/2026 16:11, bart wrote: > The other was C. There, several choices were made: > > * To start with that Fortran style except that [] are used > > * To decree that that 'A[20]' syntax is supposed to match indexing of > A as it might appear in an expression > > * To introduce "*" as a prefix dereference operator in expressions ... > > * ... which then means that a prefix "*" appears in the declaration too > > * A further complication was to allow function pointers within that a > declaration list I don't see a problem with that. If you need to declare a function pointer, you need to declare it in a declaration list. To me, the big disadvantage of C's declaration syntax is that it lets you declare things of different (but related) types in the same declaration. I don't have a problem with : int (*my_func_pointer)(int); int my_array[20]; but I /do/ have a problem with : int (*my_func_pointer)(int), my_array[20]; or, more common and therefore worse : int * a, b; The way to deal with this is, of course, simply not writing such mixed declarations. But some people /do/ - living with other peoples' code is the bane of all programmers. I am confident that there could have been a nicer syntax, and function pointer (or function type) syntax is particularly ugly. But it works well enough in practice that I cannot see it as a problem or even inconvenience. > > * Yet one more which came later was to add 'const', where placement now > gets confusing Some people do find it hard to understand the difference between : const int * p; int * const q; const int * const r; I note that this is despite the clear left-to-right nature of "const" here. Many newbie mistakes with const will be caught by the compiler, and once you get used to it, you should be fine. > > But to stay with pointers, take this expression: > > *A[i] > > C precedence rules mean this is parsed as *(A[i]), which means that a > type written as 'T *A[N]' must be an array of pointers to T (I had to > think for a few seconds!). If you instead forget that you can declare more than one thing in one declaration, you can write : T* A[i]; Then it is quite clear. > > But suppose you wanted a pointer to array of T? The expression for that > would be: > > (*A)[i] > > And so the declaration has to be 'T (*A)[N]' too. Yes. Declaration syntax follows usage. (If you don't like the operator precedence, or the fact that dereferencing is pre-fix in C, unlike, say, Pascal, then that's an orthogonal dislike.) > > So it is unfortunate that parentheses used to control precedence in an > expression now also have to appear in type declarations (where they are > often next to () used for parameter lists, for further confusion). You know how to use typedefs to make code clearer. Complicated types are a minority. Most object declarations are either things, arrays of things, or pointers to things - not combinations of these. And most function declarations are just function declarations, not arrays of function pointers or other complex types. > > ============================================== > > So, what would have happened with a postfix deref op? (Ignore whether > '*' would still be a good choice.) My first example would be this: > > A*[i] > > Here, it would mean that A is dereferenced, then indexed; A must then be > a pointer to an array of T. > > But suppose we wanted the original array of pointers to T, where you > index first then dereference. That is written like this: > > A[i]* > > You simply swap the order of [] and *. > > So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating > array/pointer and pointer/array, both within expressions and within > type-declarations. Agreed. But does that make a significant difference? I don't think so. I'd have to see a lot more real-life examples to get a feeling for whether postfix dereference would be better or worse than prefix - saving the occasional parentheses is not sufficient. > > How about that? Further, most of the type-spec is now LTR; only the > base-type has to stay on the left. Access terms in expressions will be > fully LTR. > >> IMO C suffers because typedef was added late in the game and >> function prototypes are much later. Prototypes need types and >> to get it one needs "hole" in variable declaration. Where the >> hole should be is specified by the C syntax, but placement of >> hole is probably least clear aspect of declarations. > > I thought that 'hole' was where 'int A[10]' mean one thing in normal > declaration but another within a parameter list. That's a different thing entirely. (And while I don't find it confusing that array and pointer parameters mean the same thing in C, I do see it as a wasted opportunity for better static checking and optimisation of code.) > >> IMO C declaration syntax was a mistake, but as real life shows >> it was not a fatal mistake, people can adapt. > > A mistake that could so easily have been avoid by choosing a different > precedence as shown above. Did none of the thousand people working at > Bell Labs (according to a comment in DC's follow-ip) spot this and say > anything? I suspect the folks at Bell Labs were too busy writing real code to be bothered by how confused you would be with artificially complex types. Life is full of little decisions that, with hindsight, might have been sub-optimal choices but are nonetheless good enough in practice. C's declaration syntax is one of those decisions. It's worth learning from that and picking a clearer syntax for new languages, but it is not worth obsessing over its use in existing languages. > > Had no-one even glanced at a Pascal spec, if there was no working copy? > It would have transformed C type syntax. > > (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have > been added. This could have been done 50 years ago, with the original > eventually deprecated. It /is/ too late - far, far too late. It would be a terrible idea to add a new postfix dereference operator to give two different operators with no benefit other than very occasionally reducing the need for parentheses. If "*p" really bothers you, write "p[0]" instead (in expressions, not type declarations). > > But this is a common theme of mine whether I perceive a problem that > people grudgingly admit might not be idea. But nothing was ever done to > fix it even after decades.) > What is the common theme? You pick something that lots of people consider as "it's maybe uglier than it need be, but it works fine in practice" and pretend that you alone discovered the issue? Then you go completely haywire about how terrible and unbelievable it is, call the C designers idiots and claim to be a genius because your irrelevant language does something different? Then comes the paranoia, and claims that no one will "admit there is a problem", and the absurd insistence that we all "do something about it". Eventually the thread dies away, until you bring up the same shit half a year later. For years, and years, and years. Is that the common theme you are talking about?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-20 21:07 +0100 |
| Message-ID | <11b8hln$3be6n$1@dont-email.me> |
| In reply to | #403381 |
On 20/10/2026 16:02, David Brown wrote:
> On 20/10/2026 16:11, bart wrote:
>
>> The other was C. There, several choices were made:
>>
>> * To start with that Fortran style except that [] are used
>>
>> * To decree that that 'A[20]' syntax is supposed to match indexing of
>> A as it might appear in an expression
>>
>> * To introduce "*" as a prefix dereference operator in expressions ...
>>
>> * ... which then means that a prefix "*" appears in the declaration too
>>
>> * A further complication was to allow function pointers within that a
>> declaration list
>
> I don't see a problem with that. If you need to declare a function
> pointer, you need to declare it in a declaration list.
>
> To me, the big disadvantage of C's declaration syntax is that it lets
> you declare things of different (but related) types in the same
> declaration.
Yes, but that doesn't bite so much because it is uncommon.
> or, more common and therefore worse :
>
> int * a, b;
(See below.)
>> * Yet one more which came later was to add 'const', where placement now
>> gets confusing
>
> Some people do find it hard to understand the difference between :
>
> const int * p;
> int * const q;
> const int * const r;
>
> I note that this is despite the clear left-to-right nature of "const" here.
I was going to say it was right-to-left, but it can be considered both
and thus not clear:
const int const * const p;
1 2 3
const 1 applies to the basetype to its right.
const 2 applies to the basetype to its left.
(Both also can be in the middle with compound types like 'long long'!)
const 3 is tricky: I think it applies to the * to its left, since it
says that the pointer value itself is const. But 'p' has type 'pointer
to', so it could apply to that directly.
What about this however:
int * const * p;
1 2 3
I think here, const 2 applies to * 1, which is to it's left, and can't
apply to 'p' as that is the other side of the * 3.
Fair to say that is a complete mess, and it is error prone.
With a LTR syntax that a postfix deref would achieve, 'const' would
always be written immediately to the left of any * modifiers. (It is
meaningless for arrays and functions.)
It is never applied directly to a variable name.
For base types, it can be applied on the left, but C would still allow
it on the right or in the middle, or all three with duplicates.
That means there would be an ambiguity here where there is no identifier
between 'int' and 'const':
(const int const *)
For such reasons I would restrict base type const to be only on the left.)
> Complicated types are a minority.
I've showed even simple types or trying to use 'const' get becomes
confusing.
>> So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating
>> array/pointer and pointer/array, both within expressions and within
>> type-declarations.
>
> Agreed.
>
> But does that make a significant difference? I don't think so.
It would make a HUGE difference:
(1) It helps to fix that confusion above
(2) You don't need parentheses so no need to remember if you want
(*A)[] or *A[]. Those will disappear from expressions too; less
clutter all round.
(3) It simplifies indexing of pointer-to-array from (*A)[i] to A*[i], so
that actual array pointers, which are more type-safe, could start to
appear more in C rather than the current T* idiom
(4) For pointers to structs, these are the patterns:
prefix * With -> With postfix *
(*P).m P->m P*.m
(**P).m (*P)->m P**.m
(***P).m (**P)->m P***.m
Which column looks the tidiest?
(5) With prefix *, a pointer type looks like 'T*'; notice the * is on
the right, not left! With postfix *, it would all be consistent. You
also wouldn't have 'T*A'; that would be an error (T* only happens
when there is no name)
(6) Your 'int * a, b' example would become:
int a *, b;
Much easier, even with that space, to see that '*' does not belong to
the base type but is a modifier for that variable.
It doesn't fix everything, so you'd still have this:
int p* = &a;
p* = a;
To fix this requires that all modifiers apply to the base type. But this
would be a massive change. The above is merely what happens when *
becomes postfix.
>> A mistake that could so easily have been avoid by choosing a different
>> precedence as shown above. Did none of the thousand people working at
>> Bell Labs (according to a comment in DC's follow-ip) spot this and say
>> anything?
>
> I suspect the folks at Bell Labs were too busy writing real code to be
> bothered by how confused you would be with artificially complex types.
So you agree the process was very different compared to that which lead
to Ada for example? Just a couple of guys left to do their own thing.
(Maybe they were respected enough that no one dared to offer any
constructive criticism, or if they did then it was dismissed. As happens
here.)
>>
>> (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have
>> been added. This could have been done 50 years ago, with the original
>> eventually deprecated.
>
> It /is/ too late - far, far too late. It would be a terrible idea to
> add a new postfix dereference operator to give two different operators
> with no benefit other than very occasionally reducing the need for
> parentheses.
But a special operator P->m to do the same job as (*P).m was fine! The
new op would eliminate the need for ->.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 11:20 +0200 |
| Message-ID | <11ba045$3peq3$1@dont-email.me> |
| In reply to | #403385 |
On 20/10/2026 22:07, bart wrote: > On 20/10/2026 16:02, David Brown wrote: >> On 20/10/2026 16:11, bart wrote: >> >>> The other was C. There, several choices were made: >>> >>> * To start with that Fortran style except that [] are used >>> >>> * To decree that that 'A[20]' syntax is supposed to match indexing of >>> A as it might appear in an expression >>> >>> * To introduce "*" as a prefix dereference operator in expressions ... >>> >>> * ... which then means that a prefix "*" appears in the declaration too >>> >>> * A further complication was to allow function pointers within that a >>> declaration list >> >> I don't see a problem with that. If you need to declare a function >> pointer, you need to declare it in a declaration list. >> >> To me, the big disadvantage of C's declaration syntax is that it lets >> you declare things of different (but related) types in the same >> declaration. > > Yes, but that doesn't bite so much because it is uncommon. > Unfortunately not - but it is uncommon to mix objects and function declarations, or objects of wildly different real types. >> or, more common and therefore worse : >> >> int * a, b; > > (See below.) > >>> * Yet one more which came later was to add 'const', where placement now >>> gets confusing >> >> Some people do find it hard to understand the difference between : >> >> const int * p; >> int * const q; >> const int * const r; >> >> I note that this is despite the clear left-to-right nature of "const" >> here. > I was going to say it was right-to-left, but it can be considered both > and thus not clear: > > const int const * const p; > 1 2 3 > > const 1 applies to the basetype to its right. > const 2 applies to the basetype to its left. These are redundant - they do the same thing. (I'd have preferred if the ordering rules were strict - allowing only "const int" or "int const" - but at least people are usually consistent in their style.) > > (Both also can be in the middle with compound types like 'long long'!) > > const 3 is tricky: I think it applies to the * to its left, since it > says that the pointer value itself is const. But 'p' has type 'pointer > to', so it could apply to that directly. Yes - it is "p" that is const, not the "*". > > What about this however: > > int * const * p; > > 1 2 3 > > I think here, const 2 applies to * 1, which is to it's left, and can't > apply to 'p' as that is the other side of the * 3. *p is of type "int * const" - thus you can use "*p" to access a pointer-to-int, but you can't use *p to change that pointer-to-int. Fortunately, such types are rare. > > Fair to say that is a complete mess, and it is error prone. No, it is not at all fair to say that. It is fair to say that a different way of writing types might make it easier to understand - but that's a /long/ way from saying it is "a complete mess". And you can't call it "error prone" unless you know that people regularly use such declarations, and often have bugs in their code as a result of doing so incorrectly. I think that is an unrealistic claim. I appreciate that it can be difficult to see exactly what that type means, unless you use such a construct regularly - but there is no benefit in wild exaggeration. And I don't think /any/ alternative syntax would make it easy to understand what that type really is, what it can do and what it cannot do, or why you might want it. > > With a LTR syntax that a postfix deref would achieve, 'const' would > always be written immediately to the left of any * modifiers. (It is > meaningless for arrays and functions.) You can write this in C++ : // This bit is only needed once template <typename T> using ptr = T *; // p is a pointer to a const pointer to an int ptr<const ptr<int>> p; That's LTR syntax. Sure, it also has < > parentheses, but that's a minor point since the ordering of the components is what apparently matters so much. Or you can write : typedef int * p_int; const p_int * p; Thus p is a pointer to a "const p_int", where a "p_int" is a pointer to an int. These are different ways to write the same type, including one that is LTR, and the main hinder to understanding remains the same - what is the type for? > > It is never applied directly to a variable name. > > For base types, it can be applied on the left, but C would still allow > it on the right or in the middle, or all three with duplicates. What do you mean "base types" ? Do you mean that C lets you write const long int a; long const int a; const int long a; int const long a; long int const a; int long const a; ? If that's your complaint, then I agree with that one - I would be happier if C had allowed only "const long int;" here. But I think most programmers are consistent in the style they use (though some prefer "east const"). > > That means there would be an ambiguity here where there is no identifier > between 'int' and 'const': > > (const int const *) > > For such reasons I would restrict base type const to be only on the left.) >> Complicated types are a minority. > > I've showed even simple types or trying to use 'const' get becomes > confusing. No, you haven't. You have shown that /you/ claim to be confused by types with "const". Most C programmers, once they are used to the language, do not find it confusing in common and simple types. You do not get to invent meaningless complicated types, claim that you don't understand them, and use that as evidence that C's declaration syntax is "a complete mess". At best, all you can show is that for complex types, C's syntax can require more thought to write or understand than some alternative syntaxes might. But we've all known that for decades. > >>> So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating >>> array/pointer and pointer/array, both within expressions and within >>> type-declarations. >> >> Agreed. >> >> But does that make a significant difference? I don't think so. > > It would make a HUGE difference: Your points below are all true, but IMHO all very minor, and do not add up to anything much. They might be enough to tip the balance when developing a new language where you are trying to decide whether your dereference operator should be prefix or postfix, but they are not enough to cause any concern in a language that has chosen prefix. > > (1) It helps to fix that confusion above Your invented confusion. > > (2) You don't need parentheses so no need to remember if you want > (*A)[] or *A[]. Those will disappear from expressions too; less > clutter all round. That doesn't matter in practice. > > (3) It simplifies indexing of pointer-to-array from (*A)[i] to A*[i], so > that actual array pointers, which are more type-safe, could start to > appear more in C rather than the current T* idiom I don't see that as significant. I do agree that the decay of expressions using array types into pointer types is a source of error in C code - though I do not think it is as bad as you do. I would have been happier if arrays were value types and the expressions did not decay to pointer expressions without manual intervention (like taking the address of the first element). In my C++ code, I make a lot of use of std::array<> types for that purpose - in my C code, it is not uncommon for me to have arrays wrapped in a struct. But I just don't see pointer-to-array expressions to be common enough for the difference you describe to be important. > > (4) For pointers to structs, these are the patterns: > > prefix * With -> With postfix * > > (*P).m P->m P*.m > (**P).m (*P)->m P**.m > (***P).m (**P)->m P***.m > > Which column looks the tidiest? Far and away the most common - by orders of magnitude - are pointers to structs. "p->m" looks fine to me, and I prefer it to "p*.m". A pointer to a pointer to a struct is rare enough that it is a good thing for the syntax to stand out - with a postfix dereference, I'd probably still use parentheses and write "(p*)->m". > > (5) With prefix *, a pointer type looks like 'T*'; notice the * is on > the right, not left! With postfix *, it would all be consistent. You > also wouldn't have 'T*A'; that would be an error (T* only happens > when there is no name) The C declaration syntax is "declaration follows use". If "*" were a postfix operator, then the declaration of a pointer-to-int would become: int p*; while the type of p would be "int *". So you would still have an inconsistency there, unless you also changed the way C has its declarations. > > (6) Your 'int * a, b' example would become: > > int a *, b; > > Much easier, even with that space, to see that '*' does not belong to > the base type but is a modifier for that variable. It's still bad. I don't think finding a way to make it easier to write bad code is a good idea. > > It doesn't fix everything, so you'd still have this: > > int p* = &a; > p* = a; > > To fix this requires that all modifiers apply to the base type. But this > would be a massive change. The above is merely what happens when * > becomes postfix. So basically, the suggestion would change some very minor things - mostly in subjective ways - and not actually do anything for aspects of the language where there is more of a consensus that C is sub-optimal. And for this, you would want a fundamental change to one of the most used operators in all C code! > >>> A mistake that could so easily have been avoid by choosing a >>> different precedence as shown above. Did none of the thousand people >>> working at Bell Labs (according to a comment in DC's follow-ip) spot >>> this and say anything? >> >> I suspect the folks at Bell Labs were too busy writing real code to be >> bothered by how confused you would be with artificially complex types. > > So you agree the process was very different compared to that which lead > to Ada for example? Just a couple of guys left to do their own thing. I don't see how you reach that conclusion from what I wrote. It is, however, true that C was designed by a small number of people working closely together, rather than a large committee-based design process involving lots of people. > > (Maybe they were respected enough that no one dared to offer any > constructive criticism, or if they did then it was dismissed. As happens > here.) I have no insight into the culture at Bell Labs at the time, but that sounds extraordinarily unlikely. Feel free to offer some constructive criticism some time, and we will see if it is dismissed. Note that "constructive criticism" involves more than "It's C, and I hate everything about C because it is connected to *nix, and I hate everything about *nix because it is connected to C". And even if you occasionally have a valid criticism about C, it is not "constructive" criticism because we did not design the language, and we do not dictate how it could be changed or how it is used. > >>> >>> (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have >>> been added. This could have been done 50 years ago, with the original >>> eventually deprecated. >> >> It /is/ too late - far, far too late. It would be a terrible idea to >> add a new postfix dereference operator to give two different operators >> with no benefit other than very occasionally reducing the need for >> parentheses. > > But a special operator P->m to do the same job as (*P).m was fine! The > new op would eliminate the need for ->. > The -> operator was added to C in 1972 ! It is not new - it has always been part of the language beyond its early prototype versions.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 12:29 +0100 |
| Message-ID | <11ba7na$3sh37$1@dont-email.me> |
| In reply to | #403403 |
On 21/10/2026 10:20, David Brown wrote: > On 20/10/2026 22:07, bart wrote: >> On 20/10/2026 16:02, David Brown wrote: >>> On 20/10/2026 16:11, bart wrote: >>>> * A further complication was to allow function pointers within that a >>>> declaration list >>> To me, the big disadvantage of C's declaration syntax is that it lets >>> you declare things of different (but related) types in the same >>> declaration. >> >> Yes, but that doesn't bite so much because it is uncommon. >> > > Unfortunately not - but it is uncommon to mix objects and function > declarations, or objects of wildly different real types. That's what I meant. >> const int const * const p; >> 1 2 3 >> >> const 1 applies to the basetype to its right. >> const 2 applies to the basetype to its left. > > These are redundant - they do the same thing. (I'd have preferred if > the ordering rules were strict - allowing only "const int" or "int > const" - but at least people are usually consistent in their style.) > >> >> (Both also can be in the middle with compound types like 'long long'!) >> >> const 3 is tricky: I think it applies to the * to its left, since it >> says that the pointer value itself is const. But 'p' has type 'pointer >> to', so it could apply to that directly. > > Yes - it is "p" that is const, not the "*". I would disagree. This type can also be written as: (const int const * const) There is no 'p' to apply to. The type describes a pointer to an integer. The first two consts say, redundantly, that the integer value is const. The third must then apply to the pointer. >> >> What about this however: >> >> int * const * p; >> >> 1 2 3 >> >> I think here, const 2 applies to * 1, which is to it's left, and can't >> apply to 'p' as that is the other side of the * 3. > > *p is of type "int * const" - thus you can use "*p" to access a pointer- > to-int, but you can't use *p to change that pointer-to-int. But what exactly does this 'const' apply to? I'm suggesting any 'const' applies either to the base type (the one on the left) or to a particular '*'. In that case the latter 'const's must apply right-to-left to the preceding '*'. >> Fair to say that is a complete mess, and it is error prone. > > No, it is not at all fair to say that. It is fair to say that a > different way of writing types might make it easier to understand - but > that's a /long/ way from saying it is "a complete mess". And you can't > call it "error prone" unless you know that people regularly use such > declarations, and often have bugs in their code as a result of doing so > incorrectly. I think that is an unrealistic claim. If there's any confusion about which const applies to which type element, then mistakes can be made. > You can write this in C++ : > > // This bit is only needed once > template <typename T> using ptr = T *; > > // p is a pointer to a const pointer to an int > ptr<const ptr<int>> p; > > > That's LTR syntax. Sure, it also has < > parentheses, but that's a > minor point since the ordering of the components is what apparently > matters so much. That it is LTR is now irrelevant because I find that incomprehensible anyway. You've turned a linear chain a nested structure ... oh never mind, I don't even want to go there with C++. > > Or you can write : > > typedef int * p_int; > const p_int * p; > > Thus p is a pointer to a "const p_int", where a "p_int" is a pointer to > an int. So, a common pattern with you is to use workarounds so that you effectively emulate LTR type patterns. Because they are easier to work with and understand. So you do appreciate how they facilitate things, even though they introduce an extra level of indirection and also disseminate the type information across the program. But you want to underplay how useful it would be to have natural LTR type declarations within a syntax. > These are different ways to write the same type, including one that is > LTR, and the main hinder to understanding remains the same - what is the > type for? If you create a type alias voluntarily (I don't mean structs where either a tag or a typedef needs to be created) then yes the name should impart something useful. But in my view this is often taken too far. Sometimes you have structs where every member has a different user-type. When you look further, you find they are all ints. That is just obfuscation. (I would accept enumeration types if the compiler can employ that info to improve type safety, but that seems to be limited.) >> I've showed even simple types or trying to use 'const' get becomes >> confusing. > > No, you haven't. OK. That is not surprising. >> It would make a HUGE difference: > > Your points below are all true, but IMHO all very minor, and do not add > up to anything much. It would eliminate half the issues with C's type syntax. Probably CDECL wouldn't need to exist. Lots of () disappear. It would make pointers-to-arrays more viable. But that's nothing in your view. OK again. > Your invented confusion. > That doesn't matter in practice. > I don't see that as significant. > > I do agree that the decay of expressions using array types into pointer > types is a source of error in C code - though I do not think it is as > bad as you do. I didn't say anything about, and that wouldn't be affected. > But I just don't see pointer-to-array expressions to be common enough > for the difference you describe to be important. If you're passing arrays to a function by-reference then the natural way is to a have a pointer to the array. C can do that, but nobody ever does so, probably because indexing is then so ugly. With my idea, (*A)[i] turns into A*[i], a bit less ugly. (In my language, it was A^[i]. However, some years ago I relaxed the rules to allow such in-between derefs to be dropped - the compiler will reinsert them as needed. So indexing looks like A[i], and there is the extra type safety of working with actual arrays, not pointers to things that may or may not be arrays. But then I also have pass-by-reference which achieves the same thing.) >> (4) For pointers to structs, these are the patterns: >> >> prefix * With -> With postfix * >> >> (*P).m P->m P*.m >> (**P).m (*P)->m P**.m >> (***P).m (**P)->m P***.m >> >> Which column looks the tidiest? > > Far and away the most common - by orders of magnitude - are pointers to > structs. "p->m" looks fine to me, and I prefer it to "p*.m". But where's the consistency? Sometimes "." is used for member selection, and sometimes "->". And with two pointer levels, you need both! (Again in my language, all those * (or ^) in the right column can be dropped. Some loss of transparency, but much, much cleaner code. But TBF, this could also be done in C without needing postfix *.) >> (5) With prefix *, a pointer type looks like 'T*'; notice the * is on >> the right, not left! With postfix *, it would all be consistent. You >> also wouldn't have 'T*A'; that would be an error (T* only happens >> when there is no name) > > The C declaration syntax is "declaration follows use". If "*" were a > postfix operator, then the declaration of a pointer-to-int would become: > > int p*; > > while the type of p would be "int *". So you would still have an > inconsistency there, unless you also changed the way C has its > declarations. The point is that currently you have 'int*' for the type, '*p' to declare p, and '*p' in expressions. The '*' switches sides for the bare type! >> (6) Your 'int * a, b' example would become: >> >> int a *, b; >> >> Much easier, even with that space, to see that '*' does not belong to >> the base type but is a modifier for that variable. > > It's still bad. I don't think finding a way to make it easier to write > bad code is a good idea. It wouldn't stay bad for long! Because if the intention was to declare two pointers, then it's easier to see that this is wrong. > So basically, the suggestion would change some very minor things - > mostly in subjective ways - and not actually do anything for aspects of > the language where there is more of a consensus that C is sub-optimal. > And for this, you would want a fundamental change to one of the most > used operators in all C code! Obviously you can't change prefix * now. A postfix /alternative/, in addition to prefix *, could have been introduced decades ago. So by the time /you/ encountered C, you might have been using the latter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 16:40 +0200 |
| Message-ID | <11bais3$1042$1@dont-email.me> |
| In reply to | #403410 |
On 21/10/2026 13:29, bart wrote: > On 21/10/2026 10:20, David Brown wrote: >> On 20/10/2026 22:07, bart wrote: >>> On 20/10/2026 16:02, David Brown wrote: >>>> On 20/10/2026 16:11, bart wrote: > >>>>> * A further complication was to allow function pointers within that a >>>>> declaration list > >>>> To me, the big disadvantage of C's declaration syntax is that it >>>> lets you declare things of different (but related) types in the same >>>> declaration. >>> >>> Yes, but that doesn't bite so much because it is uncommon. >>> >> >> Unfortunately not - but it is uncommon to mix objects and function >> declarations, or objects of wildly different real types. > > That's what I meant. Ok. It's nice to agree sometimes! > >>> const int const * const p; >>> 1 2 3 >>> >>> const 1 applies to the basetype to its right. >>> const 2 applies to the basetype to its left. >> >> These are redundant - they do the same thing. (I'd have preferred if >> the ordering rules were strict - allowing only "const int" or "int >> const" - but at least people are usually consistent in their style.) >> >>> >>> (Both also can be in the middle with compound types like 'long long'!) >>> >>> const 3 is tricky: I think it applies to the * to its left, since it >>> says that the pointer value itself is const. But 'p' has type >>> 'pointer to', so it could apply to that directly. >> >> Yes - it is "p" that is const, not the "*". > > I would disagree. This type can also be written as: > > (const int const * const) > > There is no 'p' to apply to. The type describes a pointer to an integer. > The first two consts say, redundantly, that the integer value is const. > > The third must then apply to the pointer. Yes. But "the pointer" is the thing you are declaring. I don't think it is worth belabouring this. > >>> >>> What about this however: >>> >>> int * const * p; >>> >>> 1 2 3 >>> >>> I think here, const 2 applies to * 1, which is to it's left, and >>> can't apply to 'p' as that is the other side of the * 3. >> >> *p is of type "int * const" - thus you can use "*p" to access a >> pointer- to-int, but you can't use *p to change that pointer-to-int. > > But what exactly does this 'const' apply to? The type of "*p" - the thing that "p" points to. > > I'm suggesting any 'const' applies either to the base type (the one on > the left) or to a particular '*'. > > In that case the latter 'const's must apply right-to-left to the > preceding '*'. You can view it that way. There is a style known as "east const" that aims to put "const" on the right where possible (thus "int const", rather than "const int"), so that it always applies to the thing immediately to its left. I have never liked the style, but it is arguably more consistent. > >>> Fair to say that is a complete mess, and it is error prone. >> >> No, it is not at all fair to say that. It is fair to say that a >> different way of writing types might make it easier to understand - >> but that's a /long/ way from saying it is "a complete mess". And you >> can't call it "error prone" unless you know that people regularly use >> such declarations, and often have bugs in their code as a result of >> doing so incorrectly. I think that is an unrealistic claim. > > If there's any confusion about which const applies to which type > element, then mistakes can be made. Mistakes can always be made. And mistakes can always be found, and fixed. The questions are, are mistakes made often, are they made more often than they would be with a different syntax, are the mistakes left undiscovered, and are they consequential? I don't think so - so I don't see the syntax as "error prone". Again, I do not think the C declaration syntax is the nicest or clearest to be found, compared to some languages - but I do not think it is nearly as bad in practice as some people make out. > >> You can write this in C++ : >> >> // This bit is only needed once >> template <typename T> using ptr = T *; >> >> // p is a pointer to a const pointer to an int >> ptr<const ptr<int>> p; >> >> >> That's LTR syntax. Sure, it also has < > parentheses, but that's a >> minor point since the ordering of the components is what apparently >> matters so much. > > That it is LTR is now irrelevant because I find that incomprehensible > anyway. You've turned a linear chain a nested structure ... oh never > mind, I don't even want to go there with C++. Your LTR form /is/ a nested structure - it's just that with this C++ format (which I have never seen anyone use in practice), the nesting is explicit. >> >> Or you can write : >> >> typedef int * p_int; >> const p_int * p; >> >> Thus p is a pointer to a "const p_int", where a "p_int" is a pointer >> to an int. > > So, a common pattern with you is to use workarounds so that you > effectively emulate LTR type patterns. Because they are easier to work > with and understand. I'm offering you an alternative, because /you/ find the normal C syntax confusing. /I/ would not write that, because I don't find the C syntax here confusing or difficult to read. And mostly I would not write "int * const * p" because I have no idea when such a type might be useful. (If I knew, then maybe I would give it a specific name.) > > So you do appreciate how they facilitate things, even though they > introduce an extra level of indirection and also disseminate the type > information across the program. I appreciate that you are easily confused and have trouble with C syntax. I recommend you do one of two things - stop worrying about imaginary types with no meaning, or learn to use typedef so that they are not so scary for you. > > But you want to underplay how useful it would be to have natural LTR > type declarations within a syntax. > I don't see LTR syntax as making a /significant/ or fundamental difference. There will be a narrow range of complex types where the C syntax is getting hard to follow, but an LTR syntax is easier, but beyond that LTR is equally impenetrable. The issue for complex types is not the syntax, it is the complexity of the type - and you handle that by breaking things down into manageable sections. Let us put some numbers into this. (To be clear - these numbers are pulled out of the air, and "real" values will depend on the reader, the context, the details of the real code, real alternative syntax, etc.) Let us say that C syntax is comprehensible with up to 4 parts - where a "part" is a "const", a "*", "[n]" - in addition to the base type. With an LTR syntax, let us say it is comprehensible up to 5 parts. Then there is no doubt - the LTR syntax /is/ clearer. But does it actually matter, in practice? Most declarations require no more than 3 parts - with the great majority clustered at 0 or 1 parts. Who cares if it is difficult to read a type declaration you almost never need? And then if you have something really complicated - 6 parts or more - it is equally incomprehensible with LTR and C syntax, and should be handled by divide-and-conquer just like anything complicated in programming. This is why I can agree that the C syntax is not optimal, that an LTR syntax can be clearer, and yet it does not actually matter and the C syntax works fine in practice. >> These are different ways to write the same type, including one that is >> LTR, and the main hinder to understanding remains the same - what is >> the type for? > > If you create a type alias voluntarily (I don't mean structs where > either a tag or a typedef needs to be created) then yes the name should > impart something useful. > > But in my view this is often taken too far. Sometimes you have structs > where every member has a different user-type. When you look further, you > find they are all ints. That is just obfuscation. Every good thing can be taken too far - but there are lots of good reasons for having multiple typedefs that all coincidentally happen to boil down to "int". > > (I would accept enumeration types if the compiler can employ that info > to improve type safety, but that seems to be limited.) I agree that C enumeration types are not as "strong" as I'd like. Compiler static analysis can help in many ways, but it would be better (for me) if they were strongly typed and scoped. > >>> I've showed even simple types or trying to use 'const' get becomes >>> confusing. >> >> No, you haven't. > > OK. That is not surprising. > >>> It would make a HUGE difference: >> >> Your points below are all true, but IMHO all very minor, and do not >> add up to anything much. > > It would eliminate half the issues with C's type syntax. Probably CDECL > wouldn't need to exist. Lots of () disappear. It would make pointers-to- > arrays more viable. > > But that's nothing in your view. OK again. CDECL has never needed to exist. So few () are needed in declarations that it doesn't matter if they are there or not. Pointers to arrays work fine if you want to use them, but they are not often used in C - primarily because of the array-to-pointer decay in expressions, not because of the declaration syntax or the prefix dereferencing operator. > >> Your invented confusion. > > >> That doesn't matter in practice. > >> I don't see that as significant. >> >> I do agree that the decay of expressions using array types into >> pointer types is a source of error in C code - though I do not think >> it is as bad as you do. > > I didn't say anything about, and that wouldn't be affected. > Ok. > >> But I just don't see pointer-to-array expressions to be common enough >> for the difference you describe to be important. > > > If you're passing arrays to a function by-reference then the natural way > is to a have a pointer to the array. C can do that, but nobody ever does > so, probably because indexing is then so ugly. > > With my idea, (*A)[i] turns into A*[i], a bit less ugly. Predictions are of course speculative, but I could not see that making noticeable difference. C programmers rarely use pointers to arrays because they rarely give advantages over pointers to the first element of an array, the decay in expressions means it is easy to make mistakes, and you often need to make a pointer to the first element anyway. If array expressions did not decay to pointer expressions, and array parameters were passed as values, it would be a very different matter. > >>> (4) For pointers to structs, these are the patterns: >>> >>> prefix * With -> With postfix * >>> >>> (*P).m P->m P*.m >>> (**P).m (*P)->m P**.m >>> (***P).m (**P)->m P***.m >>> >>> Which column looks the tidiest? >> >> Far and away the most common - by orders of magnitude - are pointers >> to structs. "p->m" looks fine to me, and I prefer it to "p*.m". > > But where's the consistency? Sometimes "." is used for member selection, > and sometimes "->". And with two pointer levels, you need both! The consistency is that you almost always have a pointer to a struct, so you can consistently use p->m. There is no need to change that for consistency with a much rarer usage. And of course "." is used for member selection when you have a struct object, or when you have already dereferenced a pointer to a struct. >>> (6) Your 'int * a, b' example would become: >>> >>> int a *, b; >>> >>> Much easier, even with that space, to see that '*' does not belong to >>> the base type but is a modifier for that variable. >> >> It's still bad. I don't think finding a way to make it easier to >> write bad code is a good idea. > > It wouldn't stay bad for long! Because if the intention was to declare > two pointers, then it's easier to see that this is wrong. It is bad (according to my personal style preferences) if your intentionally declare an int and a pointer to an int in the same line. I am not talking about mistakes here - a mixup between an int and an int* will almost certainly result in a compilation failure and the code will quickly be fixed to give valid C code. C lets you write "int *a, b;" - it is legal C. There are lots of things you can write in C that I think are bad code, even though they may be intentional and work as intended. (And even though others will, naturally, have different opinions.) I would be against any change to C syntax that made it /easier/ for people to write such declarations - whether intentional or by mistake. > >> So basically, the suggestion would change some very minor things - >> mostly in subjective ways - and not actually do anything for aspects >> of the language where there is more of a consensus that C is sub- >> optimal. And for this, you would want a fundamental change to one of >> the most used operators in all C code! > > Obviously you can't change prefix * now. A postfix /alternative/, in > addition to prefix *, could have been introduced decades ago. So by the > time /you/ encountered C, you might have been using the latter. > I first used C on a very small scale in the late 1980's, so that was quite a few decades ago. I expect that a postfix dereferencing operator would have worked fine instead of a prefix one - it works fine in Pascal. I don't think it would have been "better" in any significant way. Two separate dereferencing operators with no difference except the prefix vs. postfix positioning would have been a very bad idea, no matter when it were introduced - it would have been a totally unnecessary complication, just adding confusion and inconsistency. But even if you were right here, it is no more realistic to go back 4 decades to add this new postfix dereferencing operator as it is to go back 5 decades and pick that one in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-20 23:33 +0300 |
| Message-ID | <20261020233337.00004699@yahoo.com> |
| In reply to | #403379 |
On Tue, 20 Oct 2026 15:11:35 +0100 bart <bc@freeuk.com> wrote: > On 20/10/2026 02:03, Waldek Hebisch wrote: > > bart <bc@freeuk.com> wrote: > >> > >> OK. But they HAD to create C? There were quite a few languages in > >> the early 70s too: like Pascal, Fortran, PL/I, Coral-66, plus of > >> course BCPL and B. So why a new one? > > > > You ignore fact that Ritche wanted reasonably fast code from > > very simple compiler. > > According to DC's quote from HOPL, it was also more fun to create a > new language. > > > > PL/I had most needed features. But PL/I was a big language, > > to run on small machine they would have to take tiny subset > > and then add extentions. Basicaly they would end up with a > > language which is very far from PL/I. > > There were PL/360 and PL/M, although those were more specific, more > 'machine-oriented' languages. (I implemented one for PDP10 but it was > a port of a systems language from a GEC machine.) > PL/M is approximately contemporary to C, most likely Ritchie had first compiler working few months before Kildall. But input language of the early C compilers was likely further away from what it evolved later than early PL/M to later its variant. C was self-hosted on minicomputer from the beginning. PL/M originally required more powerful and expensive host. Eventually PL/M host requirements were reduced below those of C, but it took couple of years. > Anyway, a more general subset could have been used. > I suppose that you wholeheartedly agree. I don't. I never found computer language design fun. > > > Similarly, BCPL was too complicated, B and C were simplifications > > and adaptations small machine. > > > > I think that Pascal was too late: nominally it was created earlier > > but I think that it was available to Bell Labs only after they > > did initial work leading to C. And Pascal shared problem of > > speed on small machines. Note that later UCSD Pascal which > > run on micros compiled to interpreted bytecode, which significantly > > reduced performance. > > It would not have been hard to use Pascal as a starting point for a > workable systems language. Wirth wouldn't have approved, but his > languages were too pure, too academic; some of us had things we > needed to get done! > > Here I mean adapting Pascal for a competing systems language. > Pascal without several extensions does not seem suitable for system programming. > In my hands some aspects would be simplified (eg. no nested > functions, no closures), thus making it easier to generate decent > code with a simple compiler. > But then, it's not Pascal. And still needs extensions. > > > > >> FORTRAN syntax looked nothing like C! Unless you mean the general > >> pattern of 'INTEGER A, B' which was shared by half of all > >> languages. > > > > I think more pattern of > > > > INTEGER A(20), B > > > > which has similar structure to C variable declarations. > > OK. That was typical for the time. But in Fortran it didn't get much > more complicated than that. Maybe 2D arrays and so on. > > > Of course, > > FORTRAN had no pointers (and structures or unions), so Ritche had > > to invent syntax for them. > > There were three languages from that era that I know had pointers or > references, and which allowed composing arbitrary types with arrays > and pointers, two of which were Algol68 and Pascal. > > Both used a 100% LTR form. > > The other was C. There, several choices were made: > > * To start with that Fortran style except that [] are used > > * To decree that that 'A[20]' syntax is supposed to match indexing of > A as it might appear in an expression > > * To introduce "*" as a prefix dereference operator in expressions ... > > * ... which then means that a prefix "*" appears in the declaration > too > > * A further complication was to allow function pointers within that a > declaration list > > * Yet one more which came later was to add 'const', where placement > now gets confusing > > But to stay with pointers, take this expression: > > *A[i] > > C precedence rules mean this is parsed as *(A[i]), which means that a > type written as 'T *A[N]' must be an array of pointers to T (I had to > think for a few seconds!). > > But suppose you wanted a pointer to array of T? The expression for > that would be: > > (*A)[i] > > And so the declaration has to be 'T (*A)[N]' too. > > So it is unfortunate that parentheses used to control precedence in > an expression now also have to appear in type declarations (where > they are often next to () used for parameter lists, for further > confusion). > > ============================================== > > So, what would have happened with a postfix deref op? (Ignore whether > '*' would still be a good choice.) My first example would be this: > > A*[i] > > Here, it would mean that A is dereferenced, then indexed; A must then > be a pointer to an array of T. > > But suppose we wanted the original array of pointers to T, where you > index first then dereference. That is written like this: > > A[i]* > > You simply swap the order of [] and *. > > So, PARENTHESES HAVE BEEN ELIMINATED for purpose of disambiguating > array/pointer and pointer/array, both within expressions and within > type-declarations. > > How about that? Further, most of the type-spec is now LTR; only the > base-type has to stay on the left. Access terms in expressions will > be fully LTR. > > > IMO C suffers because typedef was added late in the game and > > function prototypes are much later. Prototypes need types and > > to get it one needs "hole" in variable declaration. Where the > > hole should be is specified by the C syntax, but placement of > > hole is probably least clear aspect of declarations. > > I thought that 'hole' was where 'int A[10]' mean one thing in normal > declaration but another within a parameter list. > > > IMO C declaration syntax was a mistake, but as real life shows > > it was not a fatal mistake, people can adapt. > > A mistake that could so easily have been avoid by choosing a > different precedence as shown above. Did none of the thousand people > working at Bell Labs (according to a comment in DC's follow-ip) spot > this and say anything? > Methinks there were less than 100 people exposed to C before it became too late. May be, just 50. > Had no-one even glanced at a Pascal spec, if there was no working > copy? It would have transformed C type syntax. > > (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have > been added. This could have been done 50 years ago, with the original > eventually deprecated. > > But this is a common theme of mine whether I perceive a problem that > people grudgingly admit might not be idea. But nothing was ever done > to fix it even after decades.) > It was. There are many new languages. Today, C sees little use outside of small to mid-sized mocrocontrollers and OS kernels. Most user-layer applications on general purpose computers are written in newer languages.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-21 00:01 +0100 |
| Message-ID | <11b8rrh$3eu2m$1@dont-email.me> |
| In reply to | #403388 |
On 20/10/2026 21:33, Michael S wrote: > On Tue, 20 Oct 2026 15:11:35 +0100 > bart <bc@freeuk.com> wrote: > I suppose that you wholeheartedly agree. I don't. I never found computer > language design fun. The fun part is afterwards when you use your very own language. Quite a way to get there though. > Methinks there were less than 100 people exposed to C before it became > too late. May be, just 50. Were you there? You seem confident of those figures! I've no idea what went on, myself; I can only speculate. > >> Had no-one even glanced at a Pascal spec, if there was no working >> copy? It would have transformed C type syntax. >> >> (ACTUALLY IT IS NOT TOO LATE. A secondary postfix deref op could have >> been added. This could have been done 50 years ago, with the original >> eventually deprecated. >> >> But this is a common theme of mine whether I perceive a problem that >> people grudgingly admit might not be idea. But nothing was ever done >> to fix it even after decades.) >> > > It was. There are many new languages. > Today, C sees little use outside of small to mid-sized mocrocontrollers > and OS kernels. > Most user-layer applications on general purpose computers are written > in newer languages. I still see C everywhere, for example in the APIs of libraries like SDL, STB, GTK, OpenGL, Raylib, GMP, plus the APIs for many Windows subsystems, plus Linux. It's also popular as a target language for compilers (when LLVM is too much). Amateur compiler writers also seem to love creating C or C subset compilers more than any other language (they perceive it as simpler than it really is). And many language projects are still written in C, or at bootstrapped with C. This is all desktop machines still. Of course many are also migrating to products like Rust, Go and Zig. For me, the fact that there's still an appetite for a language of this class is one reason I still persist with mine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 13:22 +0200 |
| Message-ID | <11b2a6d$131h6$1@dont-email.me> |
| In reply to | #403234 |
On 17/10/2026 13:34, bart wrote: > On 17/10/2026 04:19, Dan Cross wrote: >> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >>> Those are considered more productive. >> >> ...and you think that's because of the syntax, and not the high >> level nature of those languages? > > It's a combination. > >> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >> much. Fixed in Go and Rust, but also, I doubt you've ever in >> your life had a variable of type array of array of length 8 of >> a pointer to a pointer to a function returning an array of >> pointers to char. Finding the most ridiculous example you can >> is not really evidence of anything besides your weird obsession > > That was the first one I saw online next to a quote from K&R and I > assumed it was from the book. In fact the example from the book is this: > > char (*(*x())[])() > > I've no idea what the means either. The point is not that the examples > are ridiculous, but that they are hard to convert to and from LTR form > which is how we think. With LTR syntax it becomes utterly trivial to > read or write them, no matter how complex. > > (There's a tool called CDECL that translates types from C syntax to LTR > English or vice versa. It calls the C versions 'gibberish'. This is a > real thing!) > Putting that example in cdecl gives : "declare x as function returning pointer to array of pointer to function returning char" To me, that is just as much gibberish as the original C. No syntax is going to make sense of it - no amount of "ref" or "func" or pre-fix array notation will help. If you want complex types in a programming language, make them out of simpler, named types that express what you are trying to achieve. I think any decent typed programming language will have a way to do this - for C, "typedef" is your friend here. (And do /not/ reply by bringing up examples you have cherry-picked from code you have found, as though it was my fault they wrote incomprehensible code.) > >> with finding abstruse corner cases and holding them up as >> reasons to dislike C. > > The first example I gave was the simplest form of function pointer, > where the syntax is 'void(*)(void)'. Hardly a corner case, and it > rapidly goes downhill. Name the types at the point where they are clear, and build them up from there. typedef void (*fp_void)(void); > > If meeting C for the first time, that does not bode well. If the > designers did not care about this, that does not inspire confidence in > the rest of the language. C is not, and has never claimed to be, a beginner-friendly language. It is designed to be efficient while remaining quite a small language, which means that there are parts that are harder to use correctly, details that are important to understand, and it has plenty of scope to write code that is unclear. It works well for responsible programmers who learn the language and code carefully - but you have to learn more before you can understand and use it than, say, BASIC or Python.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 14:12 +0200 |
| Message-ID | <11b2d46$3pvda$5@dont-email.me> |
| In reply to | #403261 |
On 2026-10-18 13:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> [...]
>> char (*(*x())[])()
>> [...]
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
There's different things here with the C-declaration.
* Complexity of expression; as you say below this can be alleviated by
structuring with "subtypes" and 'typedef'.
* Cryptic syntax with many (spurious but in "C" necessary) parenthesis.
* Mixed/mangled order of component concerning its logical structure.
The 'cdecl' tool helps with point 2 and 3. - So I consider it to be
quite useful! (Although I have to admit that I've never used it myself
in practice because (for my code) I try to not compose overly complex
type definitions; and when it gets complex point 1 applies.) Especially
if you have to work with third-party code it can spare you some time,
though.
>
> To me, that is just as much gibberish as the original C. No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
I assume you're here commenting on some of bart's adopted syntactical
decisions.
FWIW; why I prefer some other language design decisions is exactly that
they use syntaxes with such keywords. They typically reduce the number
of parentheses and other "graph" characters thereby reducing the effect
of code appearing quickly more cryptic than necessary, they make the
definition more clear and better readable (IMO). Keeping (in addition)
the logical order of its components also helps IMO to easier understand
the declaration construct.
To be frank, it's beyond me why anyone wouldn't admire such consistent
declaration syntaxes. (And if bart has adopted those principles that's
certainly not a bad thing. YMMV.)
>
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
Yes. This is what we can do about the "complexity" aspect of the topic.
Janis
> [snip]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 14:33 +0100 |
| Message-ID | <11b2hr6$15thq$1@dont-email.me> |
| In reply to | #403261 |
On 18/10/2026 12:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> On 17/10/2026 04:19, Dan Cross wrote:
>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>>> Those are considered more productive.
>>>
>>> ...and you think that's because of the syntax, and not the high
>>> level nature of those languages?
>>
>> It's a combination.
>>
>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as
>>> much. Fixed in Go and Rust, but also, I doubt you've ever in
>>> your life had a variable of type array of array of length 8 of
>>> a pointer to a pointer to a function returning an array of
>>> pointers to char. Finding the most ridiculous example you can
>>> is not really evidence of anything besides your weird obsession
>>
>> That was the first one I saw online next to a quote from K&R and I
>> assumed it was from the book. In fact the example from the book is this:
>>
>> char (*(*x())[])()
>>
>> I've no idea what the means either. The point is not that the examples
>> are ridiculous, but that they are hard to convert to and from LTR form
>> which is how we think. With LTR syntax it becomes utterly trivial to
>> read or write them, no matter how complex.
>>
>> (There's a tool called CDECL that translates types from C syntax to
>> LTR English or vice versa. It calls the C versions 'gibberish'. This
>> is a real thing!)
>>
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
>
> To me, that is just as much gibberish as the original C.
That doesn't matter - the problem is not even knowing what it
represents. (That it is an actual function is a surprise. That you can't
easily tell is crazy.)
In practice there will be actual types that start to look like
gibberish, full of *, () and [] that must be in exactly the right place.
Then maybe you want to construct a pointer to such a type or an array of
it - where will be the new * or [] go? Where will the variable name go
for that matter?
This should be simple enough to do in a language without needing to
follow some back-and-forth algorithm, or use an external tool, or need
to decompose them into multiple levels using 'typedef', or need to
disambiguate with parentheses.
Typedef decomposition can be useful when types are genuinely complex (or
parts of them are used/shared elsewhere), but it should not be a crutch
for an unusable type syntax.
In any case, for me the threshold at which I need help is low. I
couldn't do these for example:
* Array of function pointers (say taking no params and returning void)
* Pointer to array of function pointers
* Function returning pointer to array (of int)
* Pointer to function returning pointer to array (int)
My tool tells me the answers are these:
void (*[])(void)
void (*(*)[])(void)
int (*(void))[]
int (*(*)(void))[]
Still gobbledygook, sorry, and these are hardly that complex or
unrealistic. (Other than 'pointer to array' being an uncommon C idiom.
It's only uncommon because other C syntax choices make it ungainly to
work with.)
Of those four lines, one is an actual function; another is a pointer to
a function. Plus there is an array, and a pointer to something else. But
this is not obvious at a glance, because the key part is buried in the
middle. In an LTR scheme, it would be first.
> No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
It will tell you what it is, which is a start. Those four examples I
gave would look like this:
[]ref proc # 'proc' is 'func -> void'
ref []ref proc
func -> ref []int
ref func -> ref []int
Using a scheme I once proposed for C, to work side-by-side with the
current syntax, I believe it would be like this:
[]*func()void
*[]*func()void p, q;
func F()*[]int {}
*func()*[]int
Variable names would go on the right as in the second example. For that
actual function however, an earlier name looks better and matches other
languages.
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
>
> (And do /not/ reply by bringing up examples you have cherry-picked from
> code you have found, as though it was my fault they wrote
> incomprehensible code.)
But that is going to happen. You will come across such types.
> C is not, and has never claimed to be, a beginner-friendly language.
If something is needlessly complex and unintuitive, that will be the
case for everyone.
For beginners to C, it is just an unnecessary obstacle. I can see many
giving up on it for that reason.
One way to simplify types is to use 'typeof' (I've no idea whether it is
still an extension or now standardised). That means being able to write:
typeof(int*) p, q, r;
instead of: 'int *p, *q, *r' which is too tempting to write as 'int* p,
q, r'.
This solves another issue where the type of any declared variable is
split up into up three pieces in three different places:
int a, b, *c[10];
The type of 'c' comprises 'int', '*' before the name, and '[]' after the
name. This makes it hard to share too. 'typeof' allows this (or along
these lines):
typeof(int*[]) x, y, z;
The type is in one tidy place, and it can be shared. This is how C
should have worked in the first place, and it wouldn't have needed that
untidy 'typeof()'.
> It
> is designed to be efficient while remaining quite a small language,
C's type declarations are actually harder to parse than a conventional
LTR scheme. That means a more complex compiler front-end.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:27 +0200 |
| Message-ID | <11b2l06$16mof$1@dont-email.me> |
| In reply to | #403269 |
On 18/10/2026 15:33, bart wrote: > On 18/10/2026 12:22, David Brown wrote: >> On 17/10/2026 13:34, bart wrote: >>> On 17/10/2026 04:19, Dan Cross wrote: >>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> >>>> wrote: >>> >>>>> Those are considered more productive. >>>> >>>> ...and you think that's because of the syntax, and not the high >>>> level nature of those languages? >>> >>> It's a combination. >>> >>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >>>> much. Fixed in Go and Rust, but also, I doubt you've ever in >>>> your life had a variable of type array of array of length 8 of >>>> a pointer to a pointer to a function returning an array of >>>> pointers to char. Finding the most ridiculous example you can >>>> is not really evidence of anything besides your weird obsession >>> >>> That was the first one I saw online next to a quote from K&R and I >>> assumed it was from the book. In fact the example from the book is this: >>> >>> char (*(*x())[])() >>> >>> I've no idea what the means either. The point is not that the >>> examples are ridiculous, but that they are hard to convert to and >>> from LTR form which is how we think. With LTR syntax it becomes >>> utterly trivial to read or write them, no matter how complex. >>> >>> (There's a tool called CDECL that translates types from C syntax to >>> LTR English or vice versa. It calls the C versions 'gibberish'. This >>> is a real thing!) >>> >> >> Putting that example in cdecl gives : >> >> "declare x as function returning pointer to array of pointer to >> function returning char" >> >> To me, that is just as much gibberish as the original C. > > That doesn't matter - the problem is not even knowing what it > represents. That is, shall we say, a strange attitude. Gibberish (since that seems to be the preferred term here) is gibberish, no matter the language or representation, and is equally meaningless and useless. > (That it is an actual function is a surprise. That you can't > easily tell is crazy.) You can tell it very easy from the C - the final bit is parentheses. > > In practice there will be actual types that start to look like > gibberish, full of *, () and [] that must be in exactly the right place. Not in my code, or the code I work with - types are clear to me. Again, experiences can vary. (Of course the syntactical elements must be in the right place!) > > Then maybe you want to construct a pointer to such a type or an array of > it - where will be the new * or [] go? Where will the variable name go > for that matter? Use a typedef. Or since C23, use type inference - that can save naming and identifying types when things get complex, and makes it easier to write more general code. Like all language features, there are times when it is appropriate, and times when it is inappropriate. But if you've got something "foo" (an object, function, type, etc.) and you want an array of 26 of that type, type inference makes that simple - the type of "foo" is "typeof(foo)" : typeof(foo) xs[26]; If you want a pointer to the object "foo", "auto * p = &foo;". This is, IMHO, a nice addition in C23, but it would have been nicer to have had it earlier. (It's been a gcc extension for a long time.) > > This should be simple enough to do in a language without needing to > follow some back-and-forth algorithm, or use an external tool, or need > to decompose them into multiple levels using 'typedef', or need to > disambiguate with parentheses. You just /have/ to whine, don't you? Whenever you complain - usually due to ignorance or prejudice - that something is difficult or complicated in C, and someone tells you how it can be handled simply and clearly, you are unable to simply say "Okay, thanks - that's good to know" or "Sorry, I was wrong, I thought it was hard". You can't help but call things workarounds, or complicated, or get your knickers in a twist about having to use a language feature that for some reason you hate.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 17:09 +0100 |
| Message-ID | <11b2qv0$19h68$1@dont-email.me> |
| In reply to | #403272 |
On 18/10/2026 15:27, David Brown wrote:
> On 18/10/2026 15:33, bart wrote:
>> On 18/10/2026 12:22, David Brown wrote:
>>> To me, that is just as much gibberish as the original C.
>>
>> That doesn't matter - the problem is not even knowing what it represents.
>
> That is, shall we say, a strange attitude. Gibberish (since that seems
> to be the preferred term here) is gibberish, no matter the language or
> representation, and is equally meaningless and useless.
'Gibberish' here refers to the representation, whether the type being
described is made-up nonsense or real.
You may want to know what some complex type is for many reasons, you
don't necessarily need to understand what it means or why it was used.
(For example I might come across a type in a C API that I want to
convert to another language.)
>> (That it is an actual function is a surprise. That you can't easily
>> tell is crazy.)
>
> You can tell it very easy from the C - the final bit is parentheses.
Both actual function declarations and function pointers end in (...).
Function definitions will have { towards the end of the signature which
is more of a clue.
But it is telling that pretty much every language using C-style syntax
has chosen to use a keyword (fn, fun, func, function or other) to
introduce a function signature.
>> In practice there will be actual types that start to look like
>> gibberish, full of *, () and [] that must be in exactly the right place.
>
> Not in my code, or the code I work with - types are clear to me. Again,
> experiences can vary.
What are you saying here, that your types never involve * () or []? That
is hard to believe.
> (Of course the syntactical elements must be in
> the right place!)
Isn't that the problem? C makes it tricky. Here are two very
straightforward declarations from my projects:
ref []ichar stringtable # ichar is ref char
[N]ref proc(T) handlertable
These are the C versions:
char *(*stringtable)[];
void (*handlertable[N)(T);
They involve * () and [] that must all be in the right place, in the
right nesting order. In C, parentheses are used to alter precedences as
well as for parameter lists. This not a thing in LTR forms.
Additionally, in C, you can sometimes mix up the order of * and [], but
since a T* value can be indexed, and a T[] value can be dereferenced,
those errors might still compile.
So it's a problem. You're saying it isn't one if you do X, Y and Z. I'm
that you shouldn't need to do X, Y and Z; if you do then it's a
language problem.
> Use a typedef. Or since C23, use type inference - that can save naming
> and identifying types when things get complex,
OK, that's a fifth kind of workaround! Although it is more of an
unrelated feature.
>> This should be simple enough to do in a language without needing to
>> follow some back-and-forth algorithm, or use an external tool, or need
>> to decompose them into multiple levels using 'typedef', or need to
>> disambiguate with parentheses.
>
> You just /have/ to whine, don't you? Whenever you complain - usually
I thought it was, for a change, a civil exchange up to now.
I'm saying that type syntax should useful without having to resort to
any of those four workarounds I mentioned.
If that happens because syntax choices (rather than genuine complexity)
would otherwise result in gibberish, then that is a failing in the language.
> complicated in C, and someone tells you how it can be handled simply and
> clearly,
No. Stuff like this is simple and clear:
ref proc
ref func -> void
* func()void
Since whatever the type, you can always read off exactly what it is from
left to right.
This is gibberish:
void(*)(void)
void(*)() (C23)
>unable to simply say "Okay, thanks - that's good to > know" or "Sorry,
I was wrong, I thought it was hard". You can't help
> but call things workarounds, or complicated, or get your knickers in a
> twist about having to use a language feature that for some reason you hate.
This one is universally disliked and even the language creators said it
was a mistake. I didn't realise that opinion was even controversial.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 21:09 +0200 |
| Message-ID | <11b35gt$1cn63$2@dont-email.me> |
| In reply to | #403282 |
On 18/10/2026 18:09, bart wrote: > On 18/10/2026 15:27, David Brown wrote: >> On 18/10/2026 15:33, bart wrote: >>> On 18/10/2026 12:22, David Brown wrote: > >>>> To me, that is just as much gibberish as the original C. >>> >>> That doesn't matter - the problem is not even knowing what it >>> represents. >> >> That is, shall we say, a strange attitude. Gibberish (since that >> seems to be the preferred term here) is gibberish, no matter the >> language or representation, and is equally meaningless and useless. > > 'Gibberish' here refers to the representation, whether the type being > described is made-up nonsense or real. > Maybe that's what /you/ mean by it, but to me the type itself there is gibberish - no matter what representation you use. > You may want to know what some complex type is for many reasons, you > don't necessarily need to understand what it means or why it was used. > > (For example I might come across a type in a C API that I want to > convert to another language.) You are just making stuff up. C API's use different named types just like any other C code, so that people can understand what they are. > >>> In practice there will be actual types that start to look like >>> gibberish, full of *, () and [] that must be in exactly the right place. >> >> Not in my code, or the code I work with - types are clear to me. >> Again, experiences can vary. > > What are you saying here, that your types never involve * () or []? That > is hard to believe. I'll cross off "false dichotomy" on my "Bart's logical fallacies" bingo card for the day. I don't write types that look like gibberish, full of *, () and []. That does not mean I do not write types that contain *, () or []. > >> (Of course the syntactical elements must be in the right place!) > > Isn't that the problem? C makes it tricky. Here are two very > straightforward declarations from my projects: > > ref []ichar stringtable # ichar is ref char > [N]ref proc(T) handlertable Are you suggesting that in your language, "stringtable" could also be declared as : ref ichar [stringtable] or ][ stringtable ichar ref ? I suspect that your language also requires the syntactical elements to be in the right place. > > These are the C versions: > > char *(*stringtable)[]; > void (*handlertable[N)(T); > > They involve * () and [] that must all be in the right place, in the > right nesting order. In C, parentheses are used to alter precedences as > well as for parameter lists. This not a thing in LTR forms. I assume that : [N] ref proc(T) handlertable and ref [N] proc(T) handlertable are different? You need to give things in the right order, or use parentheses, to get the right "type expression". It's just like any other kind of expression. The intention of the declaration syntax in C is that the declaration order follows usage. If you would not write code that /uses/ a declaration in a particular way - like so many *, () and [] sets that it is hard to comprehend - then do not write /declarations/ in that way. I don't think there is anything inherently better about C's declaration syntax than your declaration syntax, or others that are more right-to-left or more left-to-right. There's a lot of good things to say about left-to-right ordering, since that is the order for reading (in English, anyway). But it also means the declaration order and usage order are different unless your array subscript, pointer dereference and call operators are also all left-to-right. My point is not that C's syntax is wonderful (I disagree with Kenny here), but that it works fine in practice, you don't have to write incomprehensible declarations, and that if you /do/ want to write incomprehensible declarations, you can do it in any language just as easily. > > Additionally, in C, you can sometimes mix up the order of * and [], but > since a T* value can be indexed, and a T[] value can be dereferenced, > those errors might still compile. > > So it's a problem. You're saying it isn't one if you do X, Y and Z. I'm > that you shouldn't need to do X, Y and Z; if you do then it's a > language problem. > I know you say that - you are wrong to say that. If you want good, clear, correct C code, you need to write good, clear, correct C code. That's the X, Y and Z. And that applies to all languages, including yours. The details may differ, but the principles do not. You can well hold the opinion that you personally find it easier to write good, clear, correct code in your own language than you do in C. It would indeed be extraordinary if that were not the case. But your opinion there does not make it fact, or mean it applies to others. > >> Use a typedef. Or since C23, use type inference - that can save >> naming and identifying types when things get complex, > > OK, that's a fifth kind of workaround! Although it is more of an > unrelated feature. >>> This should be simple enough to do in a language without needing to >>> follow some back-and-forth algorithm, or use an external tool, or >>> need to decompose them into multiple levels using 'typedef', or need >>> to disambiguate with parentheses. >> >> You just /have/ to whine, don't you? Whenever you complain - usually > > I thought it was, for a change, a civil exchange up to now. It was - I really am trying, but you wrote one knee-jerk comment too many. I will try to reset.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 23:20 +0100 |
| Message-ID | <11b3gng$1i4mh$1@dont-email.me> |
| In reply to | #403287 |
On 18/10/2026 20:09, David Brown wrote:
> On 18/10/2026 18:09, bart wrote:
>> Isn't that the problem? C makes it tricky. Here are two very
>> straightforward declarations from my projects:
>>
>> ref []ichar stringtable # ichar is ref char
>> [N]ref proc(T) handlertable
>
> Are you suggesting that in your language, "stringtable" could also be
> declared as :
>
> ref ichar [stringtable]
> or
> ][ stringtable ichar ref
> ?
(Warning: longer post than I'd intended.)
I think you're clutching at straws.
[] or [N] means 'array of'
ref means 'pointer to'
proc means 'function returning void'
Then there is an existing standard or user type T.
You use these building blocks to construct types of any complexity. They
are simply chained together, from left to right, ending with T at the right.
If this is part of a variable declaration, then names follow on the
right (but syntaxes vary here).
So you know that ][ makes no sense. Neither does [stringtable] unless
'stringtable' is a valid array-bound expression.
Example, I want a 'pointer to an array of pointer to int':
pointer to array of pointer to int English and CDECL
ref [] ref int My syntax
So 'ref [] ref int'. Now I want to declare 3 such variables of the same
type; no problem:
ref [] ref int x, y, z
Now let's try the same exercise with C:
'pointer to' is *
'array of' is []
But how TF do they go together? Where do I start? It seems I may have to
start from the other end:
int
Now I add the pointer:
int *
I know this far! Now I need to apply [] somewhere, and then another *,
but this can't be it:
int *[]*
OK, here's one I prepared earlier (I didn't need CDECL at all...):
int *(*)[]
Now how about my three variables? Well, here's where the first goes, and
CDECL agrees with me:
int *(*x)[]
But what about y and z? It seems that, in C, the parts of typespec other
than the final T can't be shared. So it has to be this:
int *(*x)[], *(*y)[], *(z)[];
OK, obviously I lied; I had to use CDECL even for a fairly simple type,
because I find C type syntax utterly impossible.
> I suspect that your language also requires the syntactical elements to
> be in the right place.
The difference is that that is literally as simple as writing ABC. This
is the example above:
pointer to array of pointer to int x
ref [] ref int x
A B C D E
The C version is:
int *(* x)[]
D C A E B
Well it's either C A or A C; I don't know, and I don't care as
thankfully I'm not going to deal with this godforsaken language any more.
> I assume that :
>
> [N] ref proc(T) handlertable
>
> and
>
> ref [N] proc(T) handlertable
>
> are different?
Start on the left. One is an array, the other a pointer (to an array of
functions so it's not valid).
> You need to give things in the right order, or use parentheses, to get
> the right "type expression" It's just like any other kind of expression.
So, what do you think the purpose of CDECL is? Since to you, NOTHING
about C type syntax ever appears to be a problem.
Try explaining to me in English what either of those two types are.
You're going to describe them in left-to-right order just like CDECL.
This is also how I would think of them. Then my syntax merely
transcribes that exactly: I can write it as fast as I can type and I
will be 100% sure it corresponds to the type I want.
Try reading a C type spec out loud in the order it is in source code,
complete with parentheses. It just does not work!
> The intention of the declaration syntax in C is that the declaration
> order follows usage.
Which doesn't work either. If I declare P to be a pointer to int, then
it will likely be used like this in an expression:
P
I might also write &P, or *P, or P[i], or *(P + i). With a more complex
type I might also partially dereference or index it.
Now tell me that the declaration of a struct also follows its usage!
> There's a lot of good things to say about
> left-to-right ordering, since that is the order for reading (in English,
> anyway). But it also means the declaration order and usage order are
> different unless your array subscript, pointer dereference and call
> operators are also all left-to-right.
Is that important? People don't seem to have a problem writing
expressions in any language, other than quibbles about post- and pre-fix
operators.
But why is it necessary for the shape of a declaration to have anything
to do with what happens in an expression? I've showed that that can vary
anyway, and with some things (such as structs) it is meaningless.
It simply does not work in C, and just leads to confusion:
int a;
int
*p = &a;
*p = a;
The LHSs of those last two lines are the same, but the RHSs must be
different. One of them is being dereferenced, and the other isn't, even
those both /look/ as though they dereference p.
NO DEREFERENCING is done in the declaration, but it uses dereference
syntax in something that looks exactly like an assignment.
Just admit that the whole concept was a failure. The creators have
already done so.
> My point is not that C's syntax
> is wonderful (I disagree with Kenny here),
He was probably being sarcastic.
> but that it works fine in
> practice,
It works in practice with a lot of trouble, but it is not fine.
> you don't have to write incomprehensible declarations
My threshold is lower than yours. Just mix one * and one [], and I'm
already lost.
That you need to disambiguate using () to distingish *[] from (*)[] is
the wrong approach. That changes between pointer/array and
array/pointer, but mysteriously the * and [] stay in the same order?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-19 12:26 +0200 |
| Message-ID | <11b4r8h$1q18k$2@dont-email.me> |
| In reply to | #403296 |
On 19/10/2026 00:20, bart wrote: > On 18/10/2026 20:09, David Brown wrote: >> On 18/10/2026 18:09, bart wrote: > >>> Isn't that the problem? C makes it tricky. Here are two very >>> straightforward declarations from my projects: >>> >>> ref []ichar stringtable # ichar is ref char >>> [N]ref proc(T) handlertable >> >> Are you suggesting that in your language, "stringtable" could also be >> declared as : >> >> ref ichar [stringtable] >> or >> ][ stringtable ichar ref >> ? > > (Warning: longer post than I'd intended.) > > I think you're clutching at straws. I am simply mocking your suggestion that "requiring the syntactical elements to be in the right place" is a "problem" unique to C. I'm snipping the irrelevant stuff about your language - I don't know why you bother posting it. I also don't know why you bothered inventing new meaningless combinations of pointers, arrays and functions. > > So, what do you think the purpose of CDECL is? Since to you, NOTHING > about C type syntax ever appears to be a problem. I've never had any use of CDECL - it has no purpose to me. I doubt if many people use it except for extreme artificial examples. > > Just admit that the whole concept was a failure. The creators have > already done so. The early C designers have said that the declaration syntax for C ended up more complex than it could have been, and with hindsight they would have picked a different syntax. Fair enough. But they did not "admit that the whole concept was a failure". Anyone who has used C significantly (like anyone who has used any programming language significantly) has things about the language and syntax that they dislike and think could have been better. But no language has had comparable success to that of C. It is utterly laughable to say that "the whole concept of C's declaration syntax was a failure".
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 15:16 +0200 |
| Message-ID | <11b557o$1kr9u$1@dont-email.me> |
| In reply to | #403287 |
On 2026-10-18 21:09, David Brown wrote: > On 18/10/2026 18:09, bart wrote: >> [...] [ declaration syntax ] (I just want to comment on a [not unimportant] detail...) > > You need to give things in the right order, or use parentheses, to get > the right "type expression". It's just like any other kind of expression. > > The intention of the declaration syntax in C is that the declaration > order follows usage. [...] I think the first part is downplaying that languages typically indeed make a distinction between parenthesized expressions and declarations. Quite some other languages [not from the C-heritage] that I used all did not need to introduce "expression"-grouping for _declarations_ in the first place given their more consistent ways to declare entities. The second part is, as I had understood C's history, the idea behind how it got defined; needless to say that I think that was a bad idea. But that's what we've got! If they had dropped that requirement/idea the declaration syntax could have become "better" (more consistent, less cryptic, less convoluted, clearer). Now, after half a century, we just have to live with that, and folks who have "problems" with it should better not touch this language (or maybe not doing programming at all). The somewhat tragic aspect is that the "declaration follows use" idea was (IIRC) intended to _simplify_ the understanding of its concepts and use of the language; the consequences were seemingly not valued correctly. Janis
[toc] | [prev] | [next] | [standalone]
Page 17 of 24 — ← Prev page 1 … 15 16 [17] 18 19 … 24 Next page →
Back to top | Article view | comp.lang.c
csiph-web