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 366 — 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 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 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 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 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 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 15 of 19 — ← Prev page 1 … 13 14 [15] 16 17 … 19 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-10-17 11:09 +0000 |
| Message-ID | <11avl11$poq2$1@news.xmission.com> |
| In reply to | #403230 |
In article <11audde$3oci5$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>bart <bc@freeuk.com> writes:
>[...]
>> What's often stated also is how successful C has been, but that
>> doesn't magically make the syntax wonderful.
>
>NOBODY THINKS C'S SYNTAX IS WONDERFUL.
The funny thing is: I actually do.
I may be the only person here who actually thinks the syntax of C's
"switch" statement is just fine. Once you realize that it *is* more of a
computed goto rather than a high level alternation construct like you'd
find in a real high level language (C is *not* a high level language; it is
properly referred to as a "mid level" language).
Note that the underlying issue here is easily dealt with if you do both of
the following:
a) Enable the warning in your compiler that warns about (unannotated)
fallthrough.
and
b) Always put a comment when you intentionally do fallthrough.
This issue is kind of similar to the old:
if (a = b) ...
thing - which really was a problem - right up until compilers started
warning about it. Now that all compilers warn if you do that, it is no
longer a live issue, but people still bring it up occasionally.
FWIW, to take another popular whipping boy of C, I also actually like the
variable declaration syntax - which many people like to criticize as
"backwards" or "inside out". Once you get used to it, it makes perfect
sense (to me, anyway). I have no problem with a declaration like:
int i,j,*ip,arr[10],foo(int bar);
Some would say that declares lots of different types of objects, but I
think of them all as ints (which is what the declaration is telling us).
--
The randomly chosen signature file that would have appeared here is more than 4-ish
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seneca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-17 13:11 +0100 |
| Message-ID | <11avolp$61gp$1@dont-email.me> |
| In reply to | #403233 |
On 17/10/2026 12:09, Kenny McCormack wrote:
> In article <11audde$3oci5$1@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> What's often stated also is how successful C has been, but that
>>> doesn't magically make the syntax wonderful.
>>
>> NOBODY THINKS C'S SYNTAX IS WONDERFUL.
>
> The funny thing is: I actually do.
>
> I may be the only person here who actually thinks the syntax of C's
> "switch" statement is just fine. Once you realize that it *is* more of a
> computed goto
Then maybe the syntax for it should have been:
goto (x) {}
instead of:
switch (x) {}
That would not clash with 'goto label', nor the 'goto *(x)' of gnu C.
It would make it clearer that this is a cruder construct than 'switch'
pretends to be, AND it saves a keyword!
That saving could have gone towards giving switch-break its own keyword
instead of having to share 'break' with loops (because there was
apparently a shortage of keywords in 1972).
That was always going to clash at some point, and it does.
> sense (to me, anyway). I have no problem with a declaration like:
>
> int i,j,*ip,arr[10],foo(int bar);
>
> Some would say that declares lots of different types of objects, but I
> think of them all as ints (which is what the declaration is telling us).
It's taking a bunch of unrelated types of arbitrary complexity, but
because they all end with a type T when expressed in LTR form, they all
belong together?
That doesn't work: i, ip, arr, foo all have different types.
They only have the same types when fully dereferenced, indexed or
called, when written as i, *ip, arr[i], foo(i). This is NOT when happens
within the declaration, and it might not happen when they appear in
expressions either.
It's just confusing.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-17 15:15 +0200 |
| Message-ID | <11avse9$3pvda$1@dont-email.me> |
| In reply to | #403233 |
On 2026-10-17 13:09, Kenny McCormack wrote: > In article <11audde$3oci5$1@kst.eternal-september.org>, > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> bart <bc@freeuk.com> writes: >> [...] >>> What's often stated also is how successful C has been, but that >>> doesn't magically make the syntax wonderful. >> >> NOBODY THINKS C'S SYNTAX IS WONDERFUL. > > The funny thing is: I actually do. Hah! - That's the touche when someone formulates generalizing statements about "all people" or about "nobody". :-) That said; I'd anyway never expected anyone to have chosen the attribute "wonderful", though (which was the word used here). But I also think that what Keith wanted to say was that "nobody has *said* - before your post - that C's syntax is wonderful" (in reply to bart's typical wrong imputations and hallucinations what others would have implied by some [unrelated] statement). > ['switch' topic - snipped] > ["if (a = b)" topic - snipped] > > FWIW, to take another popular whipping boy of C, I also actually like the > variable declaration syntax - (I'm reading that as "declaration syntax", i.e. without "variable".) > which many people like to criticize as > "backwards" or "inside out". Once you get used to it, it makes perfect > sense (to me, anyway). [...] But isn't that exactly the point, that you need to "get used" to something, which makes it appear as a "bad" design decision to others. (I certainly got used to many things in life, but some I then just try to avoid.) And of course "it makes sense"; if you can formally describe it - and programming language syntaxes have that property - it makes sense. Is it a "good" (or even a "wonderful") design? - I don't think so. YMMV. I like some of the programming-idioms that "C" made popular, but its syntax - and specifically that convoluted declaration syntax - is certainly not amongst them. (Or requiring 'typedef' workarounds to make some of the less-trivial declarations manageable and the code significantly better readable.) We can observe that if one spent a lot time in some context, and is used to it, and at some point even masters it, he might not be considering it as negative as someone who is more of a wanderer between worlds, for whom the advantages and disadvantages of the worlds might be more obvious. - And all those hypes... Oh! - I just noticed I'm digressing. Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-17 08:34 -0700 |
| Message-ID | <86cxt8pcia.fsf@linuxsc.com> |
| In reply to | #403230 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > bart <bc@freeuk.com> writes: > [...] > >> What's often stated also is how successful C has been, but that >> doesn't magically make the syntax wonderful. > > NOBODY THINKS C'S SYNTAX IS WONDERFUL. > > We surrender. You win. Stop fighting. If you would stop trying to engage with bart you wouldn't get so frustrated. And everyone would be happier. (It would be even nicer if other people would follow this advice too... hint hint hint). Incidentally I don't think C's declaration is wonderful, but I don't mind it either.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-17 03:19 +0000 |
| Message-ID | <11aupfl$3ul$1@reader2.panix.com> |
| In reply to | #403228 |
In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 16/10/2026 13:40, Dan Cross wrote: >> In article <11arjmc$2qid7$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >> Has it truly >> never occurred to you that many other people just don't consider >> your syntax significantly cleaner, or more productive? > >So why is this style of syntax popular within scripting languages? (Lua, >Julia, Ruby...) > >Those are considered more productive. ...and you think that's because of the syntax, and not the high level nature of those languages? Wow. >> Perhaps people dismiss what you say because, despite your >> self-aggrandizing words, you've shown that you don't actually >> know C very well, > >See the type syntax example below. How well do you need to know a >language to see that that is just effing crazy? This is supposed to be a >HLL, not a puzzle that needs to be solved or decoded via algorithms or >employing tools! 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 with finding abstruse corner cases and holding them up as reasons to dislike C. >> For someone who claims to want to discuss C objectively, you >> sure do make a lot of subjective statements. > >Concerning type declaration syntax, lots of people including the C >creators agree that it was misguided. Yup. But stupid examples are just stupid. >If lots of people agree, is that still being subjective? This is the >example I think used in K&R: > > char *(*(**foo [][8])())[]; > >Most would consider this gobbledygook even if you know the rules. It is >atrocious syntax. And what's 'foo' doing in the middle of it! Yup. That's awful. >I think being defensive about it is being subjective, as you demonstrate >here: > > >> [snip; don't care] I fail to see how me not caring about your silly examples is being defensive about C. It says nothing about what I think about C one way or the other; it only says I think your arguments are poorly grounded. >That is pretty much the attitude here in a nutshell. > >What's often stated also is how successful C has been, but that doesn't >magically make the syntax wonderful. No one is claiming that C's popularity implies it's a "good" language, however you'd like to define that. There are useful properties that come with using it, including a large ecosystem of libraries and tools, huge number of programmers who know it, lots of high-quality references, and so on. But again, that doesn't mean that C is good, just that we can leverage it's popularity _usefully_. >If DMR had instead produced a language that looked like mine (say like >one of the Algols), and I came along in 2026 and proposed a syntax that >looked like the above, what do you think the response would be? But he didn't, and you didn't, so this is a meaningless historical, "what if?" >I would rightly be laughed out of the forum. Bruh...I hate to break it to you, but.... >So being 'objective' means disregarding history and widespread adoption. Well, no...both of those are factors in choosing a language or not. We can discuss the semantics of the language, it's syntax, etc; but we can also discuss tooling, engineering resources availability (can you find programmers who know C? More like, can you find programmers who _don't_ know C, amirite?), library and platform support, and so on. >The latter doesn't make the language better, just more tolerated, with >more effort put into tools to make it practical to use (with a nice >sideline in teaching all its ins and outs). This I can almost get behind, but you miss the forest for the trees. All those resources? They exist; we can leverage them. For BartLang? Not so much. Is C a good language? Meh, it's not the worst, but far from the best I've seen. Was it a bad language in 1972, when it was targeting a PDP-11/20? No, it was pretty decent for that era. Did it do all the stuff that fancy languages with advanced compilers that ran on big machines could do? No. Did it need to? Also no. >Anyway, to me, pretty much the whole of C looked as badly and crudely >put together as that, when I first came across it in 1982. My background >had been with quite different languages. Yup. Good for you. So why do you keep posting here? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-17 12:34 +0100 |
| Message-ID | <11avmfb$55rt$1@dont-email.me> |
| In reply to | #403232 |
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!) > with finding abstruse corner cases and holding them up as > reasons to dislike C. The first example I gave was the simplest form of function pointer, where the syntax is 'void(*)(void)'. Hardly a corner case, and it rapidly goes downhill. If meeting C for the first time, that does not bode well. If the designers did not care about this, that does not inspire confidence in the rest of the language. >> If DMR had instead produced a language that looked like mine (say like >> one of the Algols), and I came along in 2026 and proposed a syntax that >> looked like the above, what do you think the response would be? > > But he didn't, and you didn't, so this is a meaningless > historical, "what if?" You don't get the point. If C had used LTR type syntax and somebody proposed using inside-out back-and-forth syntax like 'void(*)(void)', they'd think they were having a laugh, as it would be ridiculous. But this is exactly what I think about it anyway, no matter that 100 million programs have battled with it for 50 years. > >> So being 'objective' means disregarding history and widespread adoption. > > Well, no...both of those are factors in choosing a language or > not. We can discuss the semantics of the language, it's syntax, > etc; but we can also discuss tooling, engineering resources > availability (can you find programmers who know C? More like, > can you find programmers who _don't_ know C, amirite?), library > and platform support, and so on. Yes, this is my point; it is tolerated, and people learn to work with it. But how much extra effort has been expended, compared if they'd tried a bit harder to get a better language at the start? Or even during its first decade. > Is C a good language? Meh, it's not the worst, but far from the > best I've seen. Was it a bad language in 1972, when it was > targeting a PDP-11/20? No, it was pretty decent for that era. Disagree. > Did it do all the stuff that fancy languages with advanced > compilers that ran on big machines could do? No. Did it need > to? Also no. I think C was first created for PDP7 with 4K words, then moved to PDP11 (don't know the spec). My first language was created nearly a decade later on a /homemade/ microprocessor system with 32KB, but no viable storage. So compiler binary and data, editor, program source code, binary and data all had to reside in memory at the same time. That crude language had 'print x' and loops that looked like 'for i:=a to b do'. It also had a 'byte' type (ie. u8). A year or two later, with 64KB and storage, it was more full-featured. It was a viable and practical alternative to C which I had looked at, and dismissed. Fun fact: my copy of K&R1 cost me £12. My first Z80 processor cost £10. My point is you can't excuse C being what it is due to hardware limitations. I used PDP11 quite a bit (/34) and that had a decent Fortran implementation. My own stuff was done in my spare time for no extra pay, on 8-bit machines I helped develop for my company, without the backing of Bell Labs.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-17 17:58 +0000 |
| Message-ID | <11b0cvs$skc$1@reader2.panix.com> |
| In reply to | #403234 |
In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> 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. Riiiight. C++ is widely considered "more productive" than C, and yet shares most of the syntactic warts you complain about so readily. >> 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!) Yes. C's declaration syntax is famously abstruse; film at 11. >> with finding abstruse corner cases and holding them up as >> reasons to dislike C. > >The first example I gave was the simplest form of function pointer, >where the syntax is 'void(*)(void)'. Hardly a corner case, and it >rapidly goes downhill. Ok. >If meeting C for the first time, that does not bode well. If the >designers did not care about this, that does not inspire confidence in >the rest of the language. Ok. >>> If DMR had instead produced a language that looked like mine (say like >>> one of the Algols), and I came along in 2026 and proposed a syntax that >>> looked like the above, what do you think the response would be? >> >> But he didn't, and you didn't, so this is a meaningless >> historical, "what if?" > >You don't get the point. There does not appear to be one. >If C had used LTR type syntax and somebody >proposed using inside-out back-and-forth syntax like 'void(*)(void)', >they'd think they were having a laugh, as it would be ridiculous. Unknowable. >But this is exactly what I think about it anyway, no matter that 100 >million programs have battled with it for 50 years. Irrelevant. >>> So being 'objective' means disregarding history and widespread adoption. >> >> Well, no...both of those are factors in choosing a language or >> not. We can discuss the semantics of the language, it's syntax, >> etc; but we can also discuss tooling, engineering resources >> availability (can you find programmers who know C? More like, >> can you find programmers who _don't_ know C, amirite?), library >> and platform support, and so on. > >Yes, this is my point; it is tolerated, and people learn to work with >it. But how much extra effort has been expended, compared if they'd >tried a bit harder to get a better language at the start? Or even during >its first decade. Then your point is minor at best. Here's a thought experiment: suppose I suddenly came to my senses and agreed with everything you say: I'm willing to totally toss out C and adopt Bart's language yesterday. Where do I get a compiler? What learning resources exist? Oh, and I need it to generate code for an ARM Cortex-M0 part; does it do that? I also need RV64GC and x86_64 and probably aarch64, too. Might want to throw in Xtensa while we're at it: does your compiler do all of that? What if I need a debugger? Oh, and I need to use crypto libraries that are supplied from a vendor; they use the C ABI. What's the inter-op story like? >> Is C a good language? Meh, it's not the worst, but far from the >> best I've seen. Was it a bad language in 1972, when it was >> targeting a PDP-11/20? No, it was pretty decent for that era. > >Disagree. Really, the entire thread could be summed up in that one word, and it would save everyone a lot of time. >> Did it do all the stuff that fancy languages with advanced >> compilers that ran on big machines could do? No. Did it need >> to? Also no. > >I think C was first created for PDP7 with 4K words, then moved to PDP11 >(don't know the spec). No. That was B; the PDP-7 was an 18-bit word-oriented machine, and was archaic even in 1968 when they started using it. C was done on the PDP-11. An early cross-compilation environment on a GE-635 computer also existed, but the primary work on the language was on the 11/20 running Unix. You know, all of this is in Dennis Ritchie's C history paper, presented at SIGPLAN's HOPL-II, which is online. If you could get over yourself for like 20 minutes you could read it, and then not talk out your ass about history. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html I suspect your general factual resistance is one of the several reasons so few people around here take you or your language seriously. >[snip] >My point is you can't excuse C being what it is due to hardware limitations. > >I used PDP11 quite a bit (/34) and that had a decent Fortran implementation. (A very different machine from an 11/20.) >My own stuff was done in my spare time for no extra pay, on 8-bit >machines I helped develop for my company, without the backing of Bell Labs. Good for you. Totally irrelevant to the history of C. Let me forestall the inevitable: you are going to reply and just repeat the same things over again. I don't care. None of this is an objective discussion of C; and it really comes across as you just seeking affirmation, which is genuinely sad. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-17 21:40 +0100 |
| Message-ID | <11b0mfv$j5ll$1@dont-email.me> |
| In reply to | #403245 |
On 17/10/2026 18:58, Dan Cross wrote: > In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> 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. > > Riiiight. So greatly simplifying syntax, all other things being equal, does not increase productivity at all? Gotcha. > Yes. C's declaration syntax is famously abstruse; film at 11. And ... that's it? Just accept it? How about doing something about it! I'm angry because to me C was so unusable that I had to create and maintain my own products over decades. Then I later found that C had insinuated itself into every API and every open source product I wanted to use. Even ABIs, supposedly language-neutral, pay deference to it. Even as a compiler target, there was no other choice. So I ended having to deal with it anyway, but thankfully avoided have to write it. >> If C had used LTR type syntax and somebody >> proposed using inside-out back-and-forth syntax like 'void(*)(void)', >> they'd think they were having a laugh, as it would be ridiculous. > > Unknowable. You do know; you just don't want to admit it. (Imagine introducing C declarations into a current language.) > Then your point is minor at best. Here's a thought experiment: > suppose I suddenly came to my senses and agreed with everything > you say: I'm willing to totally toss out C and adopt Bart's > language yesterday. THIS IS NOT ABOUT MY LANGUAGE! Why hasn't there long been an alternative systems language that didn't have C's crazy syntax and stupid quirks? I mean like 30-50 years ago. Yes, mine has lots of examples of how some alternative features could work; so what? I am not selling my language. > Where do I get a compiler? What learning > resources exist? Oh, and I need it to generate code for an > ARM Cortex-M0 part; does it do that? I also need RV64GC and > x86_64 and probably aarch64, too. Might want to throw in > Xtensa while we're at it: does your compiler do all of that? > What if I need a debugger? Oh, and I need to use crypto > libraries that are supplied from a vendor; they use the C ABI. > What's the inter-op story like? My language was for in-house use; it was never intended as a product. (If you really want to try it, I can supply an ASM file for you to build, but it works on Windows. I can no longer supply a transpiled C version that part work on Linux; I have destroyed my C-related projects.) The C API (not ABI) point is valid, and another bugbear. Why can't APIs be expressed in a language-agnostic manner? This would help other languages that also need to solve the problem of creating bindings to libraries that primarily use a C API. C is a terrible choice for a cross-language API, as too many C-isms creep in (like C macros, or vaguely defined types, including the famous 'plain char' that exists in no other language, which is neither signed nor unsigned, and above all C preprocessor features). > Good for you. Totally irrelevant to the history of C. It means that meagre hardware resources don't have to compromise the design of a language, especially when it comes to syntax. So you can't use limited resources as an excuse for its questionable choices. Actually some choices actually made it harder to parse.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 14:32 +0200 |
| Message-ID | <11b2e9r$14ag7$1@dont-email.me> |
| In reply to | #403248 |
On 17/10/2026 22:40, bart wrote: > On 17/10/2026 18:58, Dan Cross wrote: >> In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> wrote: >>> On 17/10/2026 04:19, Dan Cross wrote: >>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> >>>> wrote: >> Yes. C's declaration syntax is famously abstruse; film at 11. I'm not sure it is. It is different from what you find in some other languages, and it is certainly possible to write declarations in C that are hard to comprehend. But it is possible to do that in any programming language, and equally you can write clear declarations in C. It is very rare that I have to think about the syntax of declarations when I write C code, or when I read C code - maybe that's just my own experience, but it is simply not an issue for me. Mind you, I don't write code with the rubbish that you bring up as "examples" - maybe my experience is different from that of other people. > > And ... that's it? Just accept it? How about doing something about it! > What, exactly, do you think any of us should do about it? Let's hear a clear, realistic, concrete plan for how people here, the readers of comp.lang.c, can go about changing the syntax for C declarations. Note that continually posting complaints to people who did not design the C language, do not implement C compilers, and are not part of the C standards committee, is not a realistic or concrete plan for change. Nor is continually badgering people to "admit" that C is a terrible language.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-19 01:19 +0000 |
| Message-ID | <11b3r71$6me$1@reader2.panix.com> |
| In reply to | #403248 |
In article <11b0mfv$j5ll$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 17/10/2026 18:58, Dan Cross wrote:
>> In article <11avmfb$55rt$1@dont-email.me>, bart <bc@freeuk.com> 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.
>>
>> Riiiight.
>
>So greatly simplifying syntax, all other things being equal, does not
>increase productivity at all? Gotcha.
Logical fallacy. I didn't say it did not; I said the languages
you pointed out as being "more productive" than C had other
attributes that make them more productive that you ignored in
your fervor to focus solely on syntax.
I see that you convenient snipped out my comment about C++,
which is the direct counter example. C++ shares much syntax
with C, but also has attributes that make it (generally) more
productive than C; for example, a broad standard library of
generic types and a useful `std::string` type.
Go and Rust both similarly share lots of syntactic elements with
C, yet both are also broadly more "productive".
>> Yes. C's declaration syntax is famously abstruse; film at 11.
>
>And ... that's it? Just accept it? How about doing something about it!
One time, shortly before I deployed to Afghanistan, my (then)
girlfriend and I were sleeping in my apartment in the far
northern reaches of Manhattan when a very (VERY) loud party
started blaring music outside; it was about 1am, and it woke us
both up. "Well, aren't you going to _do_ something about it?"
she asked me, to which I replied, "what, exactly, would you like
me to do?"
I survived that deployment, but the relationship did not.
>I'm angry because to me C was so unusable that I had to create and
>maintain my own products over decades.
"Had" is a strong word; dare I say it...a subjective word.
In fact, there have been all kinds of alternatives for years.
In the earlish 1980s, there was Modula-2, PL/M, Forth, Ada, CLU,
BLISS, and so on. You yourself admit you started from Algol68.
By the late 1980s you had Oberon, decent versions of ML, C++
and Objective-C, etc; by the 1990s, there were more than you
could shake a stick at. Now? Take your pick.
You never "had" to use your own language.
>Then I later found that C had insinuated itself into every API and every
>open source product I wanted to use. Even ABIs, supposedly
>language-neutral, pay deference to it. Even as a compiler target, there
>was no other choice.
>
>So I ended having to deal with it anyway, but thankfully avoided have to
>write it.
See my earlier post. That ecosystem is one of the things that
makes C _useful_. /eyeroll
>>> If C had used LTR type syntax and somebody
>>> proposed using inside-out back-and-forth syntax like 'void(*)(void)',
>>> they'd think they were having a laugh, as it would be ridiculous.
>>
>> Unknowable.
>
>You do know; you just don't want to admit it. (Imagine introducing C
>declarations into a current language.)
No, really; C's declaration syntax was inspired by FORTRAN, and
generations of scientists and engineers have managed that
language just fine. Generations of programmers have handled C's
all right as well.
>> Then your point is minor at best. Here's a thought experiment:
>> suppose I suddenly came to my senses and agreed with everything
>> you say: I'm willing to totally toss out C and adopt Bart's
>> language yesterday.
>
>THIS IS NOT ABOUT MY LANGUAGE!
Then why do you keep bringing your language up, showing snippets
of its syntax, and so on?
>Why hasn't there long been an alternative systems language that didn't
>have C's crazy syntax and stupid quirks? I mean like 30-50 years ago.
There...have been? And still are?
>Yes, mine has lots of examples of how some alternative features could
>work; so what? I am not selling my language.
Oh good, so you'll stop bringing it up?
>> Where do I get a compiler? What learning
>> resources exist? Oh, and I need it to generate code for an
>> ARM Cortex-M0 part; does it do that? I also need RV64GC and
>> x86_64 and probably aarch64, too. Might want to throw in
>> Xtensa while we're at it: does your compiler do all of that?
>> What if I need a debugger? Oh, and I need to use crypto
>> libraries that are supplied from a vendor; they use the C ABI.
>> What's the inter-op story like?
>
>My language was for in-house use; it was never intended as a product.
>
>(If you really want to try it, I can supply an ASM file for you to
>build, but it works on Windows. I can no longer supply a transpiled C
>version that part work on Linux;
Not really, no. I don't do Windows, and I have no desire to
waste my time mucking about with random assembler to get it to
run on something I do have.
But this sort of thing is exactly what I'm talking about: your
language is not useful beyond a userbase of one. You solved a
set of "problems" that you defined for yourself, whether they
were real or not, and now are now sitting here trying to use
that as evidence about a general argument based on false
premises ("there was no alternative! I _had_ to do my own
thing!" "Oh, can I look at it?" "Oh, no; it only works for me,
on my laptop." "....").
>I have destroyed my C-related projects.)
Uh, ok.
>The C API (not ABI) point is valid, and another bugbear. Why can't APIs
>be expressed in a language-agnostic manner? This would help other
>languages that also need to solve the problem of creating bindings to
>libraries that primarily use a C API.
In fact, there have been efforts to do this for _years_. From
heavy weight IDLs and ORBs to wrappers like `swig`, and all of
the languages that used common ABIs (like the VAX Calling
Standard). They all suffer from one of two primary categories
of problems: a) either the mechanisms are too heavyweight or
cumbersome for easy use, or b) the semantics of languages vary
far too much between languages, so even if you can do something
simple like define compatible data types, language A may not be
able to meet all the constraints imposed by language B.
>C is a terrible choice for a cross-language API, as too many C-isms
>creep in (like C macros, or vaguely defined types, including the famous
>'plain char' that exists in no other language, which is neither signed
>nor unsigned, and above all C preprocessor features).
That's why ABIs matter.
Look at the Vax-11 Procedure Calling and Condition Handling
Standard from VMS 2.0; they simply wrote down what this stuff
meant, and you could call between essentially any language on
that system, whether it was C, Fortran, Bliss, COBOL, or
whatever.
>> Good for you. Totally irrelevant to the history of C.
>
>It means that meagre hardware resources don't have to compromise the
>design of a language, especially when it comes to syntax.
>
>So you can't use limited resources as an excuse for its questionable
>choices. Actually some choices actually made it harder to parse.
The team that created C was familiar with, and rather liked,
Richard Martin's BCPL. B was created as sort of a chopped down
BCPL that could fit on the PDP-7, a machine with 4KW of 18-bit
core memory, at an access time of ~1.5ms, where most
instructions touch memory twice. Oh, and that machine was
running a multitasking, multiuser operating system and was
self-hosting. And you are seriously comparing your single-user
home PC with 64k of RAM to that environment? I'm not sure you
know what "hardware limitations" are.
As mentioned, C came from B, once they got a PDP-11; it was an
incremental evolution of a language they already had. The type
syntax you find so distasteful was inspired by FORTRAN.
It's so weird to me that you make such absolute pronouncements
about C and the choices that into its design, but are so
ajbectly ignorant of the actual history. Bluntly, you just are
not very well informed about it to make cogent comments.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 13:22 +0200 |
| Message-ID | <11b2a6d$131h6$1@dont-email.me> |
| In reply to | #403234 |
On 17/10/2026 13:34, bart wrote: > On 17/10/2026 04:19, Dan Cross wrote: >> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >>> Those are considered more productive. >> >> ...and you think that's because of the syntax, and not the high >> level nature of those languages? > > It's a combination. > >> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >> much. Fixed in Go and Rust, but also, I doubt you've ever in >> your life had a variable of type array of array of length 8 of >> a pointer to a pointer to a function returning an array of >> pointers to char. Finding the most ridiculous example you can >> is not really evidence of anything besides your weird obsession > > That was the first one I saw online next to a quote from K&R and I > assumed it was from the book. In fact the example from the book is this: > > char (*(*x())[])() > > I've no idea what the means either. The point is not that the examples > are ridiculous, but that they are hard to convert to and from LTR form > which is how we think. With LTR syntax it becomes utterly trivial to > read or write them, no matter how complex. > > (There's a tool called CDECL that translates types from C syntax to LTR > English or vice versa. It calls the C versions 'gibberish'. This is a > real thing!) > Putting that example in cdecl gives : "declare x as function returning pointer to array of pointer to function returning char" To me, that is just as much gibberish as the original C. No syntax is going to make sense of it - no amount of "ref" or "func" or pre-fix array notation will help. If you want complex types in a programming language, make them out of simpler, named types that express what you are trying to achieve. I think any decent typed programming language will have a way to do this - for C, "typedef" is your friend here. (And do /not/ reply by bringing up examples you have cherry-picked from code you have found, as though it was my fault they wrote incomprehensible code.) > >> with finding abstruse corner cases and holding them up as >> reasons to dislike C. > > The first example I gave was the simplest form of function pointer, > where the syntax is 'void(*)(void)'. Hardly a corner case, and it > rapidly goes downhill. Name the types at the point where they are clear, and build them up from there. typedef void (*fp_void)(void); > > If meeting C for the first time, that does not bode well. If the > designers did not care about this, that does not inspire confidence in > the rest of the language. C is not, and has never claimed to be, a beginner-friendly language. It is designed to be efficient while remaining quite a small language, which means that there are parts that are harder to use correctly, details that are important to understand, and it has plenty of scope to write code that is unclear. It works well for responsible programmers who learn the language and code carefully - but you have to learn more before you can understand and use it than, say, BASIC or Python.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 14:12 +0200 |
| Message-ID | <11b2d46$3pvda$5@dont-email.me> |
| In reply to | #403261 |
On 2026-10-18 13:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> [...]
>> char (*(*x())[])()
>> [...]
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
There's different things here with the C-declaration.
* Complexity of expression; as you say below this can be alleviated by
structuring with "subtypes" and 'typedef'.
* Cryptic syntax with many (spurious but in "C" necessary) parenthesis.
* Mixed/mangled order of component concerning its logical structure.
The 'cdecl' tool helps with point 2 and 3. - So I consider it to be
quite useful! (Although I have to admit that I've never used it myself
in practice because (for my code) I try to not compose overly complex
type definitions; and when it gets complex point 1 applies.) Especially
if you have to work with third-party code it can spare you some time,
though.
>
> To me, that is just as much gibberish as the original C. No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
I assume you're here commenting on some of bart's adopted syntactical
decisions.
FWIW; why I prefer some other language design decisions is exactly that
they use syntaxes with such keywords. They typically reduce the number
of parentheses and other "graph" characters thereby reducing the effect
of code appearing quickly more cryptic than necessary, they make the
definition more clear and better readable (IMO). Keeping (in addition)
the logical order of its components also helps IMO to easier understand
the declaration construct.
To be frank, it's beyond me why anyone wouldn't admire such consistent
declaration syntaxes. (And if bart has adopted those principles that's
certainly not a bad thing. YMMV.)
>
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
Yes. This is what we can do about the "complexity" aspect of the topic.
Janis
> [snip]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 14:33 +0100 |
| Message-ID | <11b2hr6$15thq$1@dont-email.me> |
| In reply to | #403261 |
On 18/10/2026 12:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> On 17/10/2026 04:19, Dan Cross wrote:
>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>>> Those are considered more productive.
>>>
>>> ...and you think that's because of the syntax, and not the high
>>> level nature of those languages?
>>
>> It's a combination.
>>
>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as
>>> much. Fixed in Go and Rust, but also, I doubt you've ever in
>>> your life had a variable of type array of array of length 8 of
>>> a pointer to a pointer to a function returning an array of
>>> pointers to char. Finding the most ridiculous example you can
>>> is not really evidence of anything besides your weird obsession
>>
>> That was the first one I saw online next to a quote from K&R and I
>> assumed it was from the book. In fact the example from the book is this:
>>
>> char (*(*x())[])()
>>
>> I've no idea what the means either. The point is not that the examples
>> are ridiculous, but that they are hard to convert to and from LTR form
>> which is how we think. With LTR syntax it becomes utterly trivial to
>> read or write them, no matter how complex.
>>
>> (There's a tool called CDECL that translates types from C syntax to
>> LTR English or vice versa. It calls the C versions 'gibberish'. This
>> is a real thing!)
>>
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
>
> To me, that is just as much gibberish as the original C.
That doesn't matter - the problem is not even knowing what it
represents. (That it is an actual function is a surprise. That you can't
easily tell is crazy.)
In practice there will be actual types that start to look like
gibberish, full of *, () and [] that must be in exactly the right place.
Then maybe you want to construct a pointer to such a type or an array of
it - where will be the new * or [] go? Where will the variable name go
for that matter?
This should be simple enough to do in a language without needing to
follow some back-and-forth algorithm, or use an external tool, or need
to decompose them into multiple levels using 'typedef', or need to
disambiguate with parentheses.
Typedef decomposition can be useful when types are genuinely complex (or
parts of them are used/shared elsewhere), but it should not be a crutch
for an unusable type syntax.
In any case, for me the threshold at which I need help is low. I
couldn't do these for example:
* Array of function pointers (say taking no params and returning void)
* Pointer to array of function pointers
* Function returning pointer to array (of int)
* Pointer to function returning pointer to array (int)
My tool tells me the answers are these:
void (*[])(void)
void (*(*)[])(void)
int (*(void))[]
int (*(*)(void))[]
Still gobbledygook, sorry, and these are hardly that complex or
unrealistic. (Other than 'pointer to array' being an uncommon C idiom.
It's only uncommon because other C syntax choices make it ungainly to
work with.)
Of those four lines, one is an actual function; another is a pointer to
a function. Plus there is an array, and a pointer to something else. But
this is not obvious at a glance, because the key part is buried in the
middle. In an LTR scheme, it would be first.
> No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
It will tell you what it is, which is a start. Those four examples I
gave would look like this:
[]ref proc # 'proc' is 'func -> void'
ref []ref proc
func -> ref []int
ref func -> ref []int
Using a scheme I once proposed for C, to work side-by-side with the
current syntax, I believe it would be like this:
[]*func()void
*[]*func()void p, q;
func F()*[]int {}
*func()*[]int
Variable names would go on the right as in the second example. For that
actual function however, an earlier name looks better and matches other
languages.
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
>
> (And do /not/ reply by bringing up examples you have cherry-picked from
> code you have found, as though it was my fault they wrote
> incomprehensible code.)
But that is going to happen. You will come across such types.
> C is not, and has never claimed to be, a beginner-friendly language.
If something is needlessly complex and unintuitive, that will be the
case for everyone.
For beginners to C, it is just an unnecessary obstacle. I can see many
giving up on it for that reason.
One way to simplify types is to use 'typeof' (I've no idea whether it is
still an extension or now standardised). That means being able to write:
typeof(int*) p, q, r;
instead of: 'int *p, *q, *r' which is too tempting to write as 'int* p,
q, r'.
This solves another issue where the type of any declared variable is
split up into up three pieces in three different places:
int a, b, *c[10];
The type of 'c' comprises 'int', '*' before the name, and '[]' after the
name. This makes it hard to share too. 'typeof' allows this (or along
these lines):
typeof(int*[]) x, y, z;
The type is in one tidy place, and it can be shared. This is how C
should have worked in the first place, and it wouldn't have needed that
untidy 'typeof()'.
> It
> is designed to be efficient while remaining quite a small language,
C's type declarations are actually harder to parse than a conventional
LTR scheme. That means a more complex compiler front-end.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:27 +0200 |
| Message-ID | <11b2l06$16mof$1@dont-email.me> |
| In reply to | #403269 |
On 18/10/2026 15:33, bart wrote: > On 18/10/2026 12:22, David Brown wrote: >> On 17/10/2026 13:34, bart wrote: >>> On 17/10/2026 04:19, Dan Cross wrote: >>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> >>>> wrote: >>> >>>>> Those are considered more productive. >>>> >>>> ...and you think that's because of the syntax, and not the high >>>> level nature of those languages? >>> >>> It's a combination. >>> >>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >>>> much. Fixed in Go and Rust, but also, I doubt you've ever in >>>> your life had a variable of type array of array of length 8 of >>>> a pointer to a pointer to a function returning an array of >>>> pointers to char. Finding the most ridiculous example you can >>>> is not really evidence of anything besides your weird obsession >>> >>> That was the first one I saw online next to a quote from K&R and I >>> assumed it was from the book. In fact the example from the book is this: >>> >>> char (*(*x())[])() >>> >>> I've no idea what the means either. The point is not that the >>> examples are ridiculous, but that they are hard to convert to and >>> from LTR form which is how we think. With LTR syntax it becomes >>> utterly trivial to read or write them, no matter how complex. >>> >>> (There's a tool called CDECL that translates types from C syntax to >>> LTR English or vice versa. It calls the C versions 'gibberish'. This >>> is a real thing!) >>> >> >> Putting that example in cdecl gives : >> >> "declare x as function returning pointer to array of pointer to >> function returning char" >> >> To me, that is just as much gibberish as the original C. > > That doesn't matter - the problem is not even knowing what it > represents. That is, shall we say, a strange attitude. Gibberish (since that seems to be the preferred term here) is gibberish, no matter the language or representation, and is equally meaningless and useless. > (That it is an actual function is a surprise. That you can't > easily tell is crazy.) You can tell it very easy from the C - the final bit is parentheses. > > In practice there will be actual types that start to look like > gibberish, full of *, () and [] that must be in exactly the right place. Not in my code, or the code I work with - types are clear to me. Again, experiences can vary. (Of course the syntactical elements must be in the right place!) > > Then maybe you want to construct a pointer to such a type or an array of > it - where will be the new * or [] go? Where will the variable name go > for that matter? Use a typedef. Or since C23, use type inference - that can save naming and identifying types when things get complex, and makes it easier to write more general code. Like all language features, there are times when it is appropriate, and times when it is inappropriate. But if you've got something "foo" (an object, function, type, etc.) and you want an array of 26 of that type, type inference makes that simple - the type of "foo" is "typeof(foo)" : typeof(foo) xs[26]; If you want a pointer to the object "foo", "auto * p = &foo;". This is, IMHO, a nice addition in C23, but it would have been nicer to have had it earlier. (It's been a gcc extension for a long time.) > > This should be simple enough to do in a language without needing to > follow some back-and-forth algorithm, or use an external tool, or need > to decompose them into multiple levels using 'typedef', or need to > disambiguate with parentheses. You just /have/ to whine, don't you? Whenever you complain - usually due to ignorance or prejudice - that something is difficult or complicated in C, and someone tells you how it can be handled simply and clearly, you are unable to simply say "Okay, thanks - that's good to know" or "Sorry, I was wrong, I thought it was hard". You can't help but call things workarounds, or complicated, or get your knickers in a twist about having to use a language feature that for some reason you hate.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 17:09 +0100 |
| Message-ID | <11b2qv0$19h68$1@dont-email.me> |
| In reply to | #403272 |
On 18/10/2026 15:27, David Brown wrote:
> On 18/10/2026 15:33, bart wrote:
>> On 18/10/2026 12:22, David Brown wrote:
>>> To me, that is just as much gibberish as the original C.
>>
>> That doesn't matter - the problem is not even knowing what it represents.
>
> That is, shall we say, a strange attitude. Gibberish (since that seems
> to be the preferred term here) is gibberish, no matter the language or
> representation, and is equally meaningless and useless.
'Gibberish' here refers to the representation, whether the type being
described is made-up nonsense or real.
You may want to know what some complex type is for many reasons, you
don't necessarily need to understand what it means or why it was used.
(For example I might come across a type in a C API that I want to
convert to another language.)
>> (That it is an actual function is a surprise. That you can't easily
>> tell is crazy.)
>
> You can tell it very easy from the C - the final bit is parentheses.
Both actual function declarations and function pointers end in (...).
Function definitions will have { towards the end of the signature which
is more of a clue.
But it is telling that pretty much every language using C-style syntax
has chosen to use a keyword (fn, fun, func, function or other) to
introduce a function signature.
>> In practice there will be actual types that start to look like
>> gibberish, full of *, () and [] that must be in exactly the right place.
>
> Not in my code, or the code I work with - types are clear to me. Again,
> experiences can vary.
What are you saying here, that your types never involve * () or []? That
is hard to believe.
> (Of course the syntactical elements must be in
> the right place!)
Isn't that the problem? C makes it tricky. Here are two very
straightforward declarations from my projects:
ref []ichar stringtable # ichar is ref char
[N]ref proc(T) handlertable
These are the C versions:
char *(*stringtable)[];
void (*handlertable[N)(T);
They involve * () and [] that must all be in the right place, in the
right nesting order. In C, parentheses are used to alter precedences as
well as for parameter lists. This not a thing in LTR forms.
Additionally, in C, you can sometimes mix up the order of * and [], but
since a T* value can be indexed, and a T[] value can be dereferenced,
those errors might still compile.
So it's a problem. You're saying it isn't one if you do X, Y and Z. I'm
that you shouldn't need to do X, Y and Z; if you do then it's a
language problem.
> Use a typedef. Or since C23, use type inference - that can save naming
> and identifying types when things get complex,
OK, that's a fifth kind of workaround! Although it is more of an
unrelated feature.
>> This should be simple enough to do in a language without needing to
>> follow some back-and-forth algorithm, or use an external tool, or need
>> to decompose them into multiple levels using 'typedef', or need to
>> disambiguate with parentheses.
>
> You just /have/ to whine, don't you? Whenever you complain - usually
I thought it was, for a change, a civil exchange up to now.
I'm saying that type syntax should useful without having to resort to
any of those four workarounds I mentioned.
If that happens because syntax choices (rather than genuine complexity)
would otherwise result in gibberish, then that is a failing in the language.
> complicated in C, and someone tells you how it can be handled simply and
> clearly,
No. Stuff like this is simple and clear:
ref proc
ref func -> void
* func()void
Since whatever the type, you can always read off exactly what it is from
left to right.
This is gibberish:
void(*)(void)
void(*)() (C23)
>unable to simply say "Okay, thanks - that's good to > know" or "Sorry,
I was wrong, I thought it was hard". You can't help
> but call things workarounds, or complicated, or get your knickers in a
> twist about having to use a language feature that for some reason you hate.
This one is universally disliked and even the language creators said it
was a mistake. I didn't realise that opinion was even controversial.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 21:09 +0200 |
| Message-ID | <11b35gt$1cn63$2@dont-email.me> |
| In reply to | #403282 |
On 18/10/2026 18:09, bart wrote: > On 18/10/2026 15:27, David Brown wrote: >> On 18/10/2026 15:33, bart wrote: >>> On 18/10/2026 12:22, David Brown wrote: > >>>> To me, that is just as much gibberish as the original C. >>> >>> That doesn't matter - the problem is not even knowing what it >>> represents. >> >> That is, shall we say, a strange attitude. Gibberish (since that >> seems to be the preferred term here) is gibberish, no matter the >> language or representation, and is equally meaningless and useless. > > 'Gibberish' here refers to the representation, whether the type being > described is made-up nonsense or real. > Maybe that's what /you/ mean by it, but to me the type itself there is gibberish - no matter what representation you use. > You may want to know what some complex type is for many reasons, you > don't necessarily need to understand what it means or why it was used. > > (For example I might come across a type in a C API that I want to > convert to another language.) You are just making stuff up. C API's use different named types just like any other C code, so that people can understand what they are. > >>> In practice there will be actual types that start to look like >>> gibberish, full of *, () and [] that must be in exactly the right place. >> >> Not in my code, or the code I work with - types are clear to me. >> Again, experiences can vary. > > What are you saying here, that your types never involve * () or []? That > is hard to believe. I'll cross off "false dichotomy" on my "Bart's logical fallacies" bingo card for the day. I don't write types that look like gibberish, full of *, () and []. That does not mean I do not write types that contain *, () or []. > >> (Of course the syntactical elements must be in the right place!) > > Isn't that the problem? C makes it tricky. Here are two very > straightforward declarations from my projects: > > ref []ichar stringtable # ichar is ref char > [N]ref proc(T) handlertable Are you suggesting that in your language, "stringtable" could also be declared as : ref ichar [stringtable] or ][ stringtable ichar ref ? I suspect that your language also requires the syntactical elements to be in the right place. > > These are the C versions: > > char *(*stringtable)[]; > void (*handlertable[N)(T); > > They involve * () and [] that must all be in the right place, in the > right nesting order. In C, parentheses are used to alter precedences as > well as for parameter lists. This not a thing in LTR forms. I assume that : [N] ref proc(T) handlertable and ref [N] proc(T) handlertable are different? You need to give things in the right order, or use parentheses, to get the right "type expression". It's just like any other kind of expression. The intention of the declaration syntax in C is that the declaration order follows usage. If you would not write code that /uses/ a declaration in a particular way - like so many *, () and [] sets that it is hard to comprehend - then do not write /declarations/ in that way. I don't think there is anything inherently better about C's declaration syntax than your declaration syntax, or others that are more right-to-left or more left-to-right. There's a lot of good things to say about left-to-right ordering, since that is the order for reading (in English, anyway). But it also means the declaration order and usage order are different unless your array subscript, pointer dereference and call operators are also all left-to-right. My point is not that C's syntax is wonderful (I disagree with Kenny here), but that it works fine in practice, you don't have to write incomprehensible declarations, and that if you /do/ want to write incomprehensible declarations, you can do it in any language just as easily. > > Additionally, in C, you can sometimes mix up the order of * and [], but > since a T* value can be indexed, and a T[] value can be dereferenced, > those errors might still compile. > > So it's a problem. You're saying it isn't one if you do X, Y and Z. I'm > that you shouldn't need to do X, Y and Z; if you do then it's a > language problem. > I know you say that - you are wrong to say that. If you want good, clear, correct C code, you need to write good, clear, correct C code. That's the X, Y and Z. And that applies to all languages, including yours. The details may differ, but the principles do not. You can well hold the opinion that you personally find it easier to write good, clear, correct code in your own language than you do in C. It would indeed be extraordinary if that were not the case. But your opinion there does not make it fact, or mean it applies to others. > >> Use a typedef. Or since C23, use type inference - that can save >> naming and identifying types when things get complex, > > OK, that's a fifth kind of workaround! Although it is more of an > unrelated feature. >>> This should be simple enough to do in a language without needing to >>> follow some back-and-forth algorithm, or use an external tool, or >>> need to decompose them into multiple levels using 'typedef', or need >>> to disambiguate with parentheses. >> >> You just /have/ to whine, don't you? Whenever you complain - usually > > I thought it was, for a change, a civil exchange up to now. It was - I really am trying, but you wrote one knee-jerk comment too many. I will try to reset.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 23:20 +0100 |
| Message-ID | <11b3gng$1i4mh$1@dont-email.me> |
| In reply to | #403287 |
On 18/10/2026 20:09, David Brown wrote:
> On 18/10/2026 18:09, bart wrote:
>> Isn't that the problem? C makes it tricky. Here are two very
>> straightforward declarations from my projects:
>>
>> ref []ichar stringtable # ichar is ref char
>> [N]ref proc(T) handlertable
>
> Are you suggesting that in your language, "stringtable" could also be
> declared as :
>
> ref ichar [stringtable]
> or
> ][ stringtable ichar ref
> ?
(Warning: longer post than I'd intended.)
I think you're clutching at straws.
[] or [N] means 'array of'
ref means 'pointer to'
proc means 'function returning void'
Then there is an existing standard or user type T.
You use these building blocks to construct types of any complexity. They
are simply chained together, from left to right, ending with T at the right.
If this is part of a variable declaration, then names follow on the
right (but syntaxes vary here).
So you know that ][ makes no sense. Neither does [stringtable] unless
'stringtable' is a valid array-bound expression.
Example, I want a 'pointer to an array of pointer to int':
pointer to array of pointer to int English and CDECL
ref [] ref int My syntax
So 'ref [] ref int'. Now I want to declare 3 such variables of the same
type; no problem:
ref [] ref int x, y, z
Now let's try the same exercise with C:
'pointer to' is *
'array of' is []
But how TF do they go together? Where do I start? It seems I may have to
start from the other end:
int
Now I add the pointer:
int *
I know this far! Now I need to apply [] somewhere, and then another *,
but this can't be it:
int *[]*
OK, here's one I prepared earlier (I didn't need CDECL at all...):
int *(*)[]
Now how about my three variables? Well, here's where the first goes, and
CDECL agrees with me:
int *(*x)[]
But what about y and z? It seems that, in C, the parts of typespec other
than the final T can't be shared. So it has to be this:
int *(*x)[], *(*y)[], *(z)[];
OK, obviously I lied; I had to use CDECL even for a fairly simple type,
because I find C type syntax utterly impossible.
> I suspect that your language also requires the syntactical elements to
> be in the right place.
The difference is that that is literally as simple as writing ABC. This
is the example above:
pointer to array of pointer to int x
ref [] ref int x
A B C D E
The C version is:
int *(* x)[]
D C A E B
Well it's either C A or A C; I don't know, and I don't care as
thankfully I'm not going to deal with this godforsaken language any more.
> I assume that :
>
> [N] ref proc(T) handlertable
>
> and
>
> ref [N] proc(T) handlertable
>
> are different?
Start on the left. One is an array, the other a pointer (to an array of
functions so it's not valid).
> You need to give things in the right order, or use parentheses, to get
> the right "type expression" It's just like any other kind of expression.
So, what do you think the purpose of CDECL is? Since to you, NOTHING
about C type syntax ever appears to be a problem.
Try explaining to me in English what either of those two types are.
You're going to describe them in left-to-right order just like CDECL.
This is also how I would think of them. Then my syntax merely
transcribes that exactly: I can write it as fast as I can type and I
will be 100% sure it corresponds to the type I want.
Try reading a C type spec out loud in the order it is in source code,
complete with parentheses. It just does not work!
> The intention of the declaration syntax in C is that the declaration
> order follows usage.
Which doesn't work either. If I declare P to be a pointer to int, then
it will likely be used like this in an expression:
P
I might also write &P, or *P, or P[i], or *(P + i). With a more complex
type I might also partially dereference or index it.
Now tell me that the declaration of a struct also follows its usage!
> There's a lot of good things to say about
> left-to-right ordering, since that is the order for reading (in English,
> anyway). But it also means the declaration order and usage order are
> different unless your array subscript, pointer dereference and call
> operators are also all left-to-right.
Is that important? People don't seem to have a problem writing
expressions in any language, other than quibbles about post- and pre-fix
operators.
But why is it necessary for the shape of a declaration to have anything
to do with what happens in an expression? I've showed that that can vary
anyway, and with some things (such as structs) it is meaningless.
It simply does not work in C, and just leads to confusion:
int a;
int
*p = &a;
*p = a;
The LHSs of those last two lines are the same, but the RHSs must be
different. One of them is being dereferenced, and the other isn't, even
those both /look/ as though they dereference p.
NO DEREFERENCING is done in the declaration, but it uses dereference
syntax in something that looks exactly like an assignment.
Just admit that the whole concept was a failure. The creators have
already done so.
> My point is not that C's syntax
> is wonderful (I disagree with Kenny here),
He was probably being sarcastic.
> but that it works fine in
> practice,
It works in practice with a lot of trouble, but it is not fine.
> you don't have to write incomprehensible declarations
My threshold is lower than yours. Just mix one * and one [], and I'm
already lost.
That you need to disambiguate using () to distingish *[] from (*)[] is
the wrong approach. That changes between pointer/array and
array/pointer, but mysteriously the * and [] stay in the same order?
[toc] | [prev] | [next] | [standalone]
| From | 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]
Page 15 of 19 — ← Prev page 1 … 13 14 [15] 16 17 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web