Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-13 23:19 +0100 |
| Articles | 20 on this page of 382 — 21 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:48 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 12:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:09 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:34 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:13 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:52 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:16 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 20:47 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 22:38 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 11:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 03:50 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:59 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 14:35 +0000
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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 19:39 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 18:23 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:36 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 21:03 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 10:30 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-17 10:54 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:18 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:38 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 19:25 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 08:34 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 21:40 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:32 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement 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 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 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 David Brown <david.brown@hesbynett.no> - 2026-10-18 21:11 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 18:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
| 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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-19 15:46 +0200 |
| Message-ID | <11b56uo$1q18k$5@dont-email.me> |
| In reply to | #403317 |
On 19/10/2026 15:16, Janis Papanagnou wrote: > On 2026-10-18 21:09, David Brown wrote: >> On 18/10/2026 18:09, bart wrote: >>> [...] > [ declaration syntax ] > > (I just want to comment on a [not unimportant] detail...) > >> >> You need to give things in the right order, or use parentheses, to get >> the right "type expression". It's just like any other kind of >> expression. >> >> The intention of the declaration syntax in C is that the declaration >> order follows usage. [...] > > I think the first part is downplaying that languages typically indeed > make a distinction between parenthesized expressions and declarations. > Quite some other languages [not from the C-heritage] that I used all > did not need to introduce "expression"-grouping for _declarations_ in > the first place given their more consistent ways to declare entities. > > The second part is, as I had understood C's history, the idea behind > how it got defined; needless to say that I think that was a bad idea. > But that's what we've got! If they had dropped that requirement/idea > the declaration syntax could have become "better" (more consistent, > less cryptic, less convoluted, clearer). Now, after half a century, > we just have to live with that, and folks who have "problems" with it > should better not touch this language (or maybe not doing programming > at all). The somewhat tragic aspect is that the "declaration follows > use" idea was (IIRC) intended to _simplify_ the understanding of its > concepts and use of the language; the consequences were seemingly not > valued correctly. > There are a number of things that I don't particularly like about C's declaration syntax, or where I think it would have been better if it were different. But the "inside-to-outside" ordering is not one of them. That is not because I think it is better or clearer than left-to-right ordering, but because when I compare to, say, Pascal, it's not a big issue for me. Far bigger are : 1. People put too much into a single type declaration, rather than building types out of logical parts with a purpose and a name. They don't do it as much as Bart likes to pretend, but some people do it too much for my liking. The language doesn't force you to do that - it's programmer style. IMHO there is never a reason for a "pointer to an array of function pointers taking int and returning void" - no matter what syntax is used. Give a name to the function pointer type that reflects the usage (/not/ a name that reflects the definition), and build up from there. 2. Being able to declare variables and functions with different types in the same declaration. Very occasionally, I find it convenient to declare more than one variable at once - "int a, b, c;". It is rare in my code - generally it is one variable with an initialiser (and perhaps a comment) at a time. But it is - IMHO - a bad thing that you can write "int a, xs[20], *p, (*f)(void);" in one declaration. Both of these are overcome by simply not writing code that way. Obviously that is easy to achieve in my own code, but other people may use a different style.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 16:03 +0200 |
| Message-ID | <11b57vh$1kr9u$3@dont-email.me> |
| In reply to | #403319 |
On 2026-10-19 15:46, David Brown wrote: > On 19/10/2026 15:16, Janis Papanagnou wrote: >> [...] >> > There are a number of things that I don't particularly like about C's > declaration syntax, or where I think it would have been better if it > were different. But the "inside-to-outside" ordering is not one of > them. That is not because I think it is better or clearer than left-to- > right ordering, but because when I compare to, say, Pascal, it's not a > big issue for me. Far bigger are : > > 1. People put too much into a single type declaration, rather than > building types out of logical parts with a purpose and a name. Yes, that can be regularly observed, and not only in case of the declaration but generally; with known building blocks you can construct arbitrary complex expressions incrementally, so it might not appear as a problem at the time one writes it. But then parsing complex expressions - say, if that code is from another person or source - it gets difficult. (Topic reminds me Regexp expressions.) But also program composition in general is sometimes following an incremental growing process. Structuring is the key. > They > don't do it as much as Bart likes to pretend, but some people do it too > much for my liking. The language doesn't force you to do that - it's > programmer style. IMHO there is never a reason for a "pointer to an > array of function pointers taking int and returning void" - no matter > what syntax is used. Give a name to the function pointer type that > reflects the usage (/not/ a name that reflects the definition), and > build up from there. I fully agree. Where I obviously have a different valuation is that I saw in other languages' contexts that there's less issues with this topic. > > 2. Being able to declare variables and functions with different types in > the same declaration. Very occasionally, I find it convenient to > declare more than one variable at once - "int a, b, c;". It is rare in > my code - generally it is one variable with an initialiser (and perhaps > a comment) at a time. Absolutely the same for me. > But it is - IMHO - a bad thing that you can write > "int a, xs[20], *p, (*f)(void);" in one declaration. I agree. - But as opposed to other posters that's no serious problem; "if it hurts, just don't do it". > > Both of these are overcome by simply not writing code that way. (I should have read your post to the end before my previous statement.) > Obviously that is easy to achieve in my own code, but other people may > use a different style. And that's why companies instantiate coding standards. Janis
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-19 08:46 +0000 |
| Message-ID | <11b4le0$4fik$1@paganini.bofh.team> |
| In reply to | #403282 |
bart <bc@freeuk.com> wrote:
> On 18/10/2026 15:27, David Brown wrote:
>> On 18/10/2026 15:33, bart wrote:
>>> On 18/10/2026 12:22, David Brown wrote:
>
>>>> To me, that is just as much gibberish as the original C.
>>>
>>> That doesn't matter - the problem is not even knowing what it represents.
>>
>> That is, shall we say, a strange attitude. Gibberish (since that seems
>> to be the preferred term here) is gibberish, no matter the language or
>> representation, and is equally meaningless and useless.
>
> 'Gibberish' here refers to the representation, whether the type being
> described is made-up nonsense or real.
>
> You may want to know what some complex type is for many reasons, you
> don't necessarily need to understand what it means or why it was used.
>
> (For example I might come across a type in a C API that I want to
> convert to another language.)
You say that you had commercial product, but you are apparently not
aware of basic marketing principles. You do not win in the market
by making easy switch from your product to competitor product. You
may want to make it easy to switch _to_ your product. But you want
to make switching to competing products as hard as possible. Of
course there are constraints on this, in the process you do not want
to deteriorate quality of your product too much and you have finite
development resources.
Judging on this criteria you should admit that C is pretty good:
people wrote translators from various languages to C, but there
seem to be no success story going in opposite direction. C++
managed to take over nontrivial part of market previously occupied
by C, but they did this by embedding largish subset of C and by
massvie pileup of extra features.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-19 15:00 +0100 |
| Message-ID | <11b57p2$246h2$1@dont-email.me> |
| In reply to | #403308 |
On 19/10/2026 09:46, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 18/10/2026 15:27, David Brown wrote: >>> On 18/10/2026 15:33, bart wrote: >>>> On 18/10/2026 12:22, David Brown wrote: >> >>>>> To me, that is just as much gibberish as the original C. >>>> >>>> That doesn't matter - the problem is not even knowing what it represents. >>> >>> That is, shall we say, a strange attitude. Gibberish (since that seems >>> to be the preferred term here) is gibberish, no matter the language or >>> representation, and is equally meaningless and useless. >> >> 'Gibberish' here refers to the representation, whether the type being >> described is made-up nonsense or real. >> >> You may want to know what some complex type is for many reasons, you >> don't necessarily need to understand what it means or why it was used. >> >> (For example I might come across a type in a C API that I want to >> convert to another language.) > > You say that you had commercial product, but you are apparently not > aware of basic marketing principles. You do not win in the market > by making easy switch from your product to competitor product. You > may want to make it easy to switch _to_ your product. But you want > to make switching to competing products as hard as possible. Of > course there are constraints on this, in the process you do not want > to deteriorate quality of your product too much and you have finite > development resources. > > Judging on this criteria you should admit that C is pretty good: > people wrote translators from various languages to C, but there > seem to be no success story going in opposite direction. There are lots of reasons why not. C is popular as a compiler target because it is lower level than the source language. It has a weak type system which is easy to circumvent. It has 'goto'! (Many languages don't) There are well established, ubiquitous optimising compilers for it. Now, what would be the reasons for going the other way? There aren't any! (Well, some languages may have a feature to translate C programs into their syntax so that development can proceed in the new language. But the start point here is not C code being used for development, with some other HLL as an intermediate form.) So for that purpose, C is probably the most practical of current HLLs. Even if it is still not ideal and there are features which are awkward to express as C. C's UBs also get in the way. I've tried several times myself both with high-level and low-level generated C. (However, as a target language, I recently tried my own for that purpose, and it worked perfectly! Some features such as out-of-order definitions made it easier than C. Of course, my product does not have optimising compilers and very limited targets, due to not having an army of 1000s taking care of that as happens with C. But it shows that the creating such a suitable language design is not hard.) > C++ > managed to take over nontrivial part of market previously occupied > by C, but they did this by embedding largish subset of C and by > massvie pileup of extra features. So why IS C still around given that C++ compiler can build C programs, more or less?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 17:24 +0300 |
| Message-ID | <20261018172446.00002d43@yahoo.com> |
| In reply to | #403261 |
On Sun, 18 Oct 2026 13:22:52 +0200 David Brown <david.brown@hesbynett.no> wrote: > > To me, that is just as much gibberish as the original C. No syntax > is going to make sense of it - no amount of "ref" or "func" or > pre-fix array notation will help. > [O.T.] Prefix array notation would not. But postfix * notation would, somewhat. It would be interesting to find out why designers of C, or of one of its ancestors decided that * as prefix is preferable to * as postfix. Were they afraid of confusion with usage of * as multiplication? Probably not, because confusion can arise about equally both for prefix and for postfix.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:58 +0200 |
| Message-ID | <11b2mqu$16mof$3@dont-email.me> |
| In reply to | #403271 |
On 18/10/2026 16:24, Michael S wrote: > On Sun, 18 Oct 2026 13:22:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> To me, that is just as much gibberish as the original C. No syntax >> is going to make sense of it - no amount of "ref" or "func" or >> pre-fix array notation will help. >> > > [O.T.] > Prefix array notation would not. But postfix * notation would, somewhat. > I can agree that notational changes might make it marginally easier to understand complex declarations - or mean that declarations could be marginally more complex while still being easily understood. But nothing can make Bart's exaggerated examples meaningful. > It would be interesting to find out why designers of C, or of one of its > ancestors decided that * as prefix is preferable to * as postfix. > Were they afraid of confusion with usage of * as multiplication? > Probably not, because confusion can arise about equally both for prefix > and for postfix. > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 18:26 +0300 |
| Message-ID | <20261018182627.00001934@yahoo.com> |
| In reply to | #403277 |
On Sun, 18 Oct 2026 16:58:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 18/10/2026 16:24, Michael S wrote: > > On Sun, 18 Oct 2026 13:22:52 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> To me, that is just as much gibberish as the original C. No syntax > >> is going to make sense of it - no amount of "ref" or "func" or > >> pre-fix array notation will help. > >> > > > > [O.T.] > > Prefix array notation would not. But postfix * notation would, > > somewhat. > > I can agree that notational changes might make it marginally easier > to understand complex declarations - or mean that declarations could > be marginally more complex while still being easily understood. But > nothing can make Bart's exaggerated examples meaningful. > > > It would be interesting to find out why designers of C, or of one > > of its ancestors decided that * as prefix is preferable to * as > > postfix. Were they afraid of confusion with usage of * as > > multiplication? Probably not, because confusion can arise about > > equally both for prefix and for postfix. > > > > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" > and similar expressions, felt "(p++)* = (q++)*" was unclear? > Why would it require parentheses?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 18:11 +0200 |
| Message-ID | <11b2r36$3pvda$8@dont-email.me> |
| In reply to | #403280 |
On 2026-10-18 17:26, Michael S wrote: > On Sun, 18 Oct 2026 16:58:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 18/10/2026 16:24, Michael S wrote: [...] >>> It would be interesting to find out why designers of C, or of one >>> of its ancestors decided that * as prefix is preferable to * as >>> postfix. Because it is more "natural" when read, easier to grasp? Simpler for compilers? More consistent if all other, especially standard operators known from daily use are used in prefix-form (-5, +42, !false, ~bitset) in expressions? I don't recall to have used any language with infix-expressions that would have their monadic operators defined in postfix form. The only exception was "C" (and C-oriented languages) with their special case of post-increment/post-decrement operators. (Think also about the quirk in C++ to define monadic postfix operators that require a syntactic dummy type argument). (In low-level RPN systems it may appear more "natural", but that just aside.) >>> Were they afraid of confusion with usage of * as >>> multiplication? Probably not, because confusion can arise about >>> equally both for prefix and for postfix. >> >> I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" >> and similar expressions, felt "(p++)* = (q++)*" was unclear? > > Why would it require parentheses? Not necessarily (I think). Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 19:32 +0300 |
| Message-ID | <20261018193201.00000b13@yahoo.com> |
| In reply to | #403283 |
On Sun, 18 Oct 2026 18:11:18 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-10-18 17:26, Michael S wrote: > > On Sun, 18 Oct 2026 16:58:38 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/10/2026 16:24, Michael S wrote: > [...] > >>> It would be interesting to find out why designers of C, or of one > >>> of its ancestors decided that * as prefix is preferable to * as > >>> postfix. > > Because it is more "natural" when read, easier to grasp? IMHO, no. >Simpler for compilers? 100% no. > More consistent if all other, especially standard > operators known from daily use are used in prefix-form (-5, +42, > !false, ~bitset) in expressions? Unary * is more similar in function to postfix operators like [] and () than to those you mentioned. > > I don't recall to have used any language with infix-expressions > that would have their monadic operators defined in postfix form. I am a Bear of Very Little Brain, and long words Bother Me. By chance, did you never use Pascal? > The only exception was "C" (and C-oriented languages) with their > special case of post-increment/post-decrement operators. (Think > also about the quirk in C++ to define monadic postfix operators > that require a syntactic dummy type argument). (In low-level RPN > systems it may appear more "natural", but that just aside.) > > >>> Were they afraid of confusion with usage of * as > >>> multiplication? Probably not, because confusion can arise about > >>> equally both for prefix and for postfix. > >> > >> I don't know why it is prefix. Maybe they were keen on "*p++ = > >> *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear? > >> > > > > Why would it require parentheses? > > Not necessarily (I think). > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 15:44 +0200 |
| Message-ID | <11b56s8$1kr9u$2@dont-email.me> |
| In reply to | #403284 |
On 2026-10-18 18:32, Michael S wrote: > On Sun, 18 Oct 2026 18:11:18 +0200 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-10-18 17:26, Michael S wrote: >>> On Sun, 18 Oct 2026 16:58:38 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 18/10/2026 16:24, Michael S wrote: >> [...] >>>>> It would be interesting to find out why designers of C, or of one >>>>> of its ancestors decided that * as prefix is preferable to * as >>>>> postfix. >> >> Because it is more "natural" when read, easier to grasp? > > IMHO, no. Okay, if you think so. > >> Simpler for compilers? > > 100% no. I've read that would be a, albeit small, existing factor (when resolving ambiguities or some such; but I don't recall details). Anyway, I just want to mention some existing purported arguments, so I take your word as granted. > >> More consistent if all other, especially standard >> operators known from daily use are used in prefix-form (-5, +42, >> !false, ~bitset) in expressions? > > Unary * is more similar in function to postfix operators like [] and () > than to those you mentioned. I don't know how you come to that opinion. Personally I've learned the concepts in abstract, non-language-specific forms as 'deref'; "deref p" not "p deref"; to me the former looks more natural, but we can agree that this may be just our personal preferences). (A less low-level language will ideally anyway abstract from any explicit dereferentiation, but since we're speaking about "C" I'm not expanding further on that.) > >> >> I don't recall to have used any language with infix-expressions >> that would have their monadic operators defined in postfix form. > > I am a Bear of Very Little Brain, and long words Bother Me. (If that quote is important for your argument, please explain.) > > By chance, did you never use Pascal? Oh, yes, how could I forget that! (I stand corrected.) - I suppose it's because I considered that more an "accessor" than an operator (like the array or struct selectors); that's also why it's often not listed in Pascal's operator precedence tables. - So thanks for the reminder. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 21:11 +0200 |
| Message-ID | <11b35kn$1cn63$3@dont-email.me> |
| In reply to | #403280 |
On 18/10/2026 17:26, Michael S wrote: > On Sun, 18 Oct 2026 16:58:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/10/2026 16:24, Michael S wrote: >>> On Sun, 18 Oct 2026 13:22:52 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> >>>> To me, that is just as much gibberish as the original C. No syntax >>>> is going to make sense of it - no amount of "ref" or "func" or >>>> pre-fix array notation will help. >>>> >>> >>> [O.T.] >>> Prefix array notation would not. But postfix * notation would, >>> somewhat. >> >> I can agree that notational changes might make it marginally easier >> to understand complex declarations - or mean that declarations could >> be marginally more complex while still being easily understood. But >> nothing can make Bart's exaggerated examples meaningful. >> >>> It would be interesting to find out why designers of C, or of one >>> of its ancestors decided that * as prefix is preferable to * as >>> postfix. Were they afraid of confusion with usage of * as >>> multiplication? Probably not, because confusion can arise about >>> equally both for prefix and for postfix. >>> >> >> I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" >> and similar expressions, felt "(p++)* = (q++)*" was unclear? >> > > Why would it require parentheses? > Maybe it would not - but I think perhaps "p++* = q++*" would be even less clear. But again, I have no idea here, and if dereferencing had been postfix, it might have had knock-on effects to other aspects of operator ordering or precedence.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 18:34 +0100 |
| Message-ID | <11b2vvq$1bilt$1@dont-email.me> |
| In reply to | #403271 |
On 18/10/2026 15:24, Michael S wrote: > On Sun, 18 Oct 2026 13:22:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> To me, that is just as much gibberish as the original C. No syntax >> is going to make sense of it - no amount of "ref" or "func" or >> pre-fix array notation will help. >> > > [O.T.] > Prefix array notation would not. But postfix * notation would, somewhat. > > It would be interesting to find out why designers of C, or of one of its > ancestors decided that * as prefix is preferable to * as postfix. > Were they afraid of confusion with usage of * as multiplication? > Probably not, because confusion can arise about equally both for prefix > and for postfix. With all the other questionable choices, there probably wasn't much rationale involved. And there seemed to be little oversight too: other people weighing in with their opinions. That particular choice had several consequences: * If P is a pointer to a struct, then you have to write (*P).m instead of P*.m. * That led to people using "->" instead (I don't know if that was introduced for this reason). But that only works for one level: (**Q).m still needs (*Q)->m. With postfix it's tidier and consistent: Q**.m * The same when P is a pointer to an array. Pointers to arrays (real ones of type (T(*)[] not the T* idiom), are rarely used in C, possibly for the reason that indexing would look like (*P)[i], instead of P[i]. With postfix, it would be the marginally tidier P*[i]. Although here, even if unambiguous, the use of "*" looks odd. In the event, everybody uses T* for 'array pointers' instead, which is less type-safe. With function pointer derefs, it would be P*(x) which /is/ ambiguous, although for some obscure reason, function pointers don't need to be dereferenced: P(x) would still work. * Then we get to type syntax. I think this simplifies a little: * and [] modifiers will always be to the right of a variable. Parentheses for precedence might disappear too. Types will be a little easier to get right and to grok. When C was created, Pascal with its '^' postfix deref op already existed. Although C claims to have some Algol 68 influence (I can't see it!) it seems to have ignored Pascal completely.
[toc] | [prev] | [next] | [standalone]
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web