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 351 — 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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +0200
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 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 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 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 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 14:12 +0200 |
| Message-ID | <11b2d46$3pvda$5@dont-email.me> |
| In reply to | #403261 |
On 2026-10-18 13:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> [...]
>> char (*(*x())[])()
>> [...]
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
There's different things here with the C-declaration.
* Complexity of expression; as you say below this can be alleviated by
structuring with "subtypes" and 'typedef'.
* Cryptic syntax with many (spurious but in "C" necessary) parenthesis.
* Mixed/mangled order of component concerning its logical structure.
The 'cdecl' tool helps with point 2 and 3. - So I consider it to be
quite useful! (Although I have to admit that I've never used it myself
in practice because (for my code) I try to not compose overly complex
type definitions; and when it gets complex point 1 applies.) Especially
if you have to work with third-party code it can spare you some time,
though.
>
> To me, that is just as much gibberish as the original C. No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
I assume you're here commenting on some of bart's adopted syntactical
decisions.
FWIW; why I prefer some other language design decisions is exactly that
they use syntaxes with such keywords. They typically reduce the number
of parentheses and other "graph" characters thereby reducing the effect
of code appearing quickly more cryptic than necessary, they make the
definition more clear and better readable (IMO). Keeping (in addition)
the logical order of its components also helps IMO to easier understand
the declaration construct.
To be frank, it's beyond me why anyone wouldn't admire such consistent
declaration syntaxes. (And if bart has adopted those principles that's
certainly not a bad thing. YMMV.)
>
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
Yes. This is what we can do about the "complexity" aspect of the topic.
Janis
> [snip]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 14:33 +0100 |
| Message-ID | <11b2hr6$15thq$1@dont-email.me> |
| In reply to | #403261 |
On 18/10/2026 12:22, David Brown wrote:
> On 17/10/2026 13:34, bart wrote:
>> On 17/10/2026 04:19, Dan Cross wrote:
>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>>> Those are considered more productive.
>>>
>>> ...and you think that's because of the syntax, and not the high
>>> level nature of those languages?
>>
>> It's a combination.
>>
>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as
>>> much. Fixed in Go and Rust, but also, I doubt you've ever in
>>> your life had a variable of type array of array of length 8 of
>>> a pointer to a pointer to a function returning an array of
>>> pointers to char. Finding the most ridiculous example you can
>>> is not really evidence of anything besides your weird obsession
>>
>> That was the first one I saw online next to a quote from K&R and I
>> assumed it was from the book. In fact the example from the book is this:
>>
>> char (*(*x())[])()
>>
>> I've no idea what the means either. The point is not that the examples
>> are ridiculous, but that they are hard to convert to and from LTR form
>> which is how we think. With LTR syntax it becomes utterly trivial to
>> read or write them, no matter how complex.
>>
>> (There's a tool called CDECL that translates types from C syntax to
>> LTR English or vice versa. It calls the C versions 'gibberish'. This
>> is a real thing!)
>>
>
> Putting that example in cdecl gives :
>
> "declare x as function returning pointer to array of pointer to function
> returning char"
>
> To me, that is just as much gibberish as the original C.
That doesn't matter - the problem is not even knowing what it
represents. (That it is an actual function is a surprise. That you can't
easily tell is crazy.)
In practice there will be actual types that start to look like
gibberish, full of *, () and [] that must be in exactly the right place.
Then maybe you want to construct a pointer to such a type or an array of
it - where will be the new * or [] go? Where will the variable name go
for that matter?
This should be simple enough to do in a language without needing to
follow some back-and-forth algorithm, or use an external tool, or need
to decompose them into multiple levels using 'typedef', or need to
disambiguate with parentheses.
Typedef decomposition can be useful when types are genuinely complex (or
parts of them are used/shared elsewhere), but it should not be a crutch
for an unusable type syntax.
In any case, for me the threshold at which I need help is low. I
couldn't do these for example:
* Array of function pointers (say taking no params and returning void)
* Pointer to array of function pointers
* Function returning pointer to array (of int)
* Pointer to function returning pointer to array (int)
My tool tells me the answers are these:
void (*[])(void)
void (*(*)[])(void)
int (*(void))[]
int (*(*)(void))[]
Still gobbledygook, sorry, and these are hardly that complex or
unrealistic. (Other than 'pointer to array' being an uncommon C idiom.
It's only uncommon because other C syntax choices make it ungainly to
work with.)
Of those four lines, one is an actual function; another is a pointer to
a function. Plus there is an array, and a pointer to something else. But
this is not obvious at a glance, because the key part is buried in the
middle. In an LTR scheme, it would be first.
> No syntax is
> going to make sense of it - no amount of "ref" or "func" or pre-fix
> array notation will help.
It will tell you what it is, which is a start. Those four examples I
gave would look like this:
[]ref proc # 'proc' is 'func -> void'
ref []ref proc
func -> ref []int
ref func -> ref []int
Using a scheme I once proposed for C, to work side-by-side with the
current syntax, I believe it would be like this:
[]*func()void
*[]*func()void p, q;
func F()*[]int {}
*func()*[]int
Variable names would go on the right as in the second example. For that
actual function however, an earlier name looks better and matches other
languages.
> If you want complex types in a programming language, make them out of
> simpler, named types that express what you are trying to achieve. I
> think any decent typed programming language will have a way to do this -
> for C, "typedef" is your friend here.
>
> (And do /not/ reply by bringing up examples you have cherry-picked from
> code you have found, as though it was my fault they wrote
> incomprehensible code.)
But that is going to happen. You will come across such types.
> C is not, and has never claimed to be, a beginner-friendly language.
If something is needlessly complex and unintuitive, that will be the
case for everyone.
For beginners to C, it is just an unnecessary obstacle. I can see many
giving up on it for that reason.
One way to simplify types is to use 'typeof' (I've no idea whether it is
still an extension or now standardised). That means being able to write:
typeof(int*) p, q, r;
instead of: 'int *p, *q, *r' which is too tempting to write as 'int* p,
q, r'.
This solves another issue where the type of any declared variable is
split up into up three pieces in three different places:
int a, b, *c[10];
The type of 'c' comprises 'int', '*' before the name, and '[]' after the
name. This makes it hard to share too. 'typeof' allows this (or along
these lines):
typeof(int*[]) x, y, z;
The type is in one tidy place, and it can be shared. This is how C
should have worked in the first place, and it wouldn't have needed that
untidy 'typeof()'.
> It
> is designed to be efficient while remaining quite a small language,
C's type declarations are actually harder to parse than a conventional
LTR scheme. That means a more complex compiler front-end.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:27 +0200 |
| Message-ID | <11b2l06$16mof$1@dont-email.me> |
| In reply to | #403269 |
On 18/10/2026 15:33, bart wrote: > On 18/10/2026 12:22, David Brown wrote: >> On 17/10/2026 13:34, bart wrote: >>> On 17/10/2026 04:19, Dan Cross wrote: >>>> In article <11auad0$3no1k$1@dont-email.me>, bart <bc@freeuk.com> >>>> wrote: >>> >>>>> Those are considered more productive. >>>> >>>> ...and you think that's because of the syntax, and not the high >>>> level nature of those languages? >>> >>> It's a combination. >>> >>>> Yes, the syntax is pretty gnarly; Dennis Ritchie even said as >>>> much. Fixed in Go and Rust, but also, I doubt you've ever in >>>> your life had a variable of type array of array of length 8 of >>>> a pointer to a pointer to a function returning an array of >>>> pointers to char. Finding the most ridiculous example you can >>>> is not really evidence of anything besides your weird obsession >>> >>> That was the first one I saw online next to a quote from K&R and I >>> assumed it was from the book. In fact the example from the book is this: >>> >>> char (*(*x())[])() >>> >>> I've no idea what the means either. The point is not that the >>> examples are ridiculous, but that they are hard to convert to and >>> from LTR form which is how we think. With LTR syntax it becomes >>> utterly trivial to read or write them, no matter how complex. >>> >>> (There's a tool called CDECL that translates types from C syntax to >>> LTR English or vice versa. It calls the C versions 'gibberish'. This >>> is a real thing!) >>> >> >> Putting that example in cdecl gives : >> >> "declare x as function returning pointer to array of pointer to >> function returning char" >> >> To me, that is just as much gibberish as the original C. > > That doesn't matter - the problem is not even knowing what it > represents. That is, shall we say, a strange attitude. Gibberish (since that seems to be the preferred term here) is gibberish, no matter the language or representation, and is equally meaningless and useless. > (That it is an actual function is a surprise. That you can't > easily tell is crazy.) You can tell it very easy from the C - the final bit is parentheses. > > In practice there will be actual types that start to look like > gibberish, full of *, () and [] that must be in exactly the right place. Not in my code, or the code I work with - types are clear to me. Again, experiences can vary. (Of course the syntactical elements must be in the right place!) > > Then maybe you want to construct a pointer to such a type or an array of > it - where will be the new * or [] go? Where will the variable name go > for that matter? Use a typedef. Or since C23, use type inference - that can save naming and identifying types when things get complex, and makes it easier to write more general code. Like all language features, there are times when it is appropriate, and times when it is inappropriate. But if you've got something "foo" (an object, function, type, etc.) and you want an array of 26 of that type, type inference makes that simple - the type of "foo" is "typeof(foo)" : typeof(foo) xs[26]; If you want a pointer to the object "foo", "auto * p = &foo;". This is, IMHO, a nice addition in C23, but it would have been nicer to have had it earlier. (It's been a gcc extension for a long time.) > > This should be simple enough to do in a language without needing to > follow some back-and-forth algorithm, or use an external tool, or need > to decompose them into multiple levels using 'typedef', or need to > disambiguate with parentheses. You just /have/ to whine, don't you? Whenever you complain - usually due to ignorance or prejudice - that something is difficult or complicated in C, and someone tells you how it can be handled simply and clearly, you are unable to simply say "Okay, thanks - that's good to know" or "Sorry, I was wrong, I thought it was hard". You can't help but call things workarounds, or complicated, or get your knickers in a twist about having to use a language feature that for some reason you hate.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-18 17:09 +0100 |
| Message-ID | <11b2qv0$19h68$1@dont-email.me> |
| In reply to | #403272 |
On 18/10/2026 15:27, David Brown wrote:
> On 18/10/2026 15:33, bart wrote:
>> On 18/10/2026 12:22, David Brown wrote:
>>> To me, that is just as much gibberish as the original C.
>>
>> That doesn't matter - the problem is not even knowing what it represents.
>
> That is, shall we say, a strange attitude. Gibberish (since that seems
> to be the preferred term here) is gibberish, no matter the language or
> representation, and is equally meaningless and useless.
'Gibberish' here refers to the representation, whether the type being
described is made-up nonsense or real.
You may want to know what some complex type is for many reasons, you
don't necessarily need to understand what it means or why it was used.
(For example I might come across a type in a C API that I want to
convert to another language.)
>> (That it is an actual function is a surprise. That you can't easily
>> tell is crazy.)
>
> You can tell it very easy from the C - the final bit is parentheses.
Both actual function declarations and function pointers end in (...).
Function definitions will have { towards the end of the signature which
is more of a clue.
But it is telling that pretty much every language using C-style syntax
has chosen to use a keyword (fn, fun, func, function or other) to
introduce a function signature.
>> In practice there will be actual types that start to look like
>> gibberish, full of *, () and [] that must be in exactly the right place.
>
> Not in my code, or the code I work with - types are clear to me. Again,
> experiences can vary.
What are you saying here, that your types never involve * () or []? That
is hard to believe.
> (Of course the syntactical elements must be in
> the right place!)
Isn't that the problem? C makes it tricky. Here are two very
straightforward declarations from my projects:
ref []ichar stringtable # ichar is ref char
[N]ref proc(T) handlertable
These are the C versions:
char *(*stringtable)[];
void (*handlertable[N)(T);
They involve * () and [] that must all be in the right place, in the
right nesting order. In C, parentheses are used to alter precedences as
well as for parameter lists. This not a thing in LTR forms.
Additionally, in C, you can sometimes mix up the order of * and [], but
since a T* value can be indexed, and a T[] value can be dereferenced,
those errors might still compile.
So it's a problem. You're saying it isn't one if you do X, Y and Z. I'm
that you shouldn't need to do X, Y and Z; if you do then it's a
language problem.
> Use a typedef. Or since C23, use type inference - that can save naming
> and identifying types when things get complex,
OK, that's a fifth kind of workaround! Although it is more of an
unrelated feature.
>> This should be simple enough to do in a language without needing to
>> follow some back-and-forth algorithm, or use an external tool, or need
>> to decompose them into multiple levels using 'typedef', or need to
>> disambiguate with parentheses.
>
> You just /have/ to whine, don't you? Whenever you complain - usually
I thought it was, for a change, a civil exchange up to now.
I'm saying that type syntax should useful without having to resort to
any of those four workarounds I mentioned.
If that happens because syntax choices (rather than genuine complexity)
would otherwise result in gibberish, then that is a failing in the language.
> complicated in C, and someone tells you how it can be handled simply and
> clearly,
No. Stuff like this is simple and clear:
ref proc
ref func -> void
* func()void
Since whatever the type, you can always read off exactly what it is from
left to right.
This is gibberish:
void(*)(void)
void(*)() (C23)
>unable to simply say "Okay, thanks - that's good to > know" or "Sorry,
I was wrong, I thought it was hard". You can't help
> but call things workarounds, or complicated, or get your knickers in a
> twist about having to use a language feature that for some reason you hate.
This one is universally disliked and even the language creators said it
was a mistake. I didn't realise that opinion was even controversial.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 17:24 +0300 |
| Message-ID | <20261018172446.00002d43@yahoo.com> |
| In reply to | #403261 |
On Sun, 18 Oct 2026 13:22:52 +0200 David Brown <david.brown@hesbynett.no> wrote: > > To me, that is just as much gibberish as the original C. No syntax > is going to make sense of it - no amount of "ref" or "func" or > pre-fix array notation will help. > [O.T.] Prefix array notation would not. But postfix * notation would, somewhat. It would be interesting to find out why designers of C, or of one of its ancestors decided that * as prefix is preferable to * as postfix. Were they afraid of confusion with usage of * as multiplication? Probably not, because confusion can arise about equally both for prefix and for postfix.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:58 +0200 |
| Message-ID | <11b2mqu$16mof$3@dont-email.me> |
| In reply to | #403271 |
On 18/10/2026 16:24, Michael S wrote: > On Sun, 18 Oct 2026 13:22:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> To me, that is just as much gibberish as the original C. No syntax >> is going to make sense of it - no amount of "ref" or "func" or >> pre-fix array notation will help. >> > > [O.T.] > Prefix array notation would not. But postfix * notation would, somewhat. > I can agree that notational changes might make it marginally easier to understand complex declarations - or mean that declarations could be marginally more complex while still being easily understood. But nothing can make Bart's exaggerated examples meaningful. > It would be interesting to find out why designers of C, or of one of its > ancestors decided that * as prefix is preferable to * as postfix. > Were they afraid of confusion with usage of * as multiplication? > Probably not, because confusion can arise about equally both for prefix > and for postfix. > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 18:26 +0300 |
| Message-ID | <20261018182627.00001934@yahoo.com> |
| In reply to | #403277 |
On Sun, 18 Oct 2026 16:58:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 18/10/2026 16:24, Michael S wrote: > > On Sun, 18 Oct 2026 13:22:52 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> To me, that is just as much gibberish as the original C. No syntax > >> is going to make sense of it - no amount of "ref" or "func" or > >> pre-fix array notation will help. > >> > > > > [O.T.] > > Prefix array notation would not. But postfix * notation would, > > somewhat. > > I can agree that notational changes might make it marginally easier > to understand complex declarations - or mean that declarations could > be marginally more complex while still being easily understood. But > nothing can make Bart's exaggerated examples meaningful. > > > It would be interesting to find out why designers of C, or of one > > of its ancestors decided that * as prefix is preferable to * as > > postfix. Were they afraid of confusion with usage of * as > > multiplication? Probably not, because confusion can arise about > > equally both for prefix and for postfix. > > > > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" > and similar expressions, felt "(p++)* = (q++)*" was unclear? > Why would it require parentheses?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 18:11 +0200 |
| Message-ID | <11b2r36$3pvda$8@dont-email.me> |
| In reply to | #403280 |
On 2026-10-18 17:26, Michael S wrote: > On Sun, 18 Oct 2026 16:58:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 18/10/2026 16:24, Michael S wrote: [...] >>> It would be interesting to find out why designers of C, or of one >>> of its ancestors decided that * as prefix is preferable to * as >>> postfix. Because it is more "natural" when read, easier to grasp? Simpler for compilers? More consistent if all other, especially standard operators known from daily use are used in prefix-form (-5, +42, !false, ~bitset) in expressions? I don't recall to have used any language with infix-expressions that would have their monadic operators defined in postfix form. The only exception was "C" (and C-oriented languages) with their special case of post-increment/post-decrement operators. (Think also about the quirk in C++ to define monadic postfix operators that require a syntactic dummy type argument). (In low-level RPN systems it may appear more "natural", but that just aside.) >>> Were they afraid of confusion with usage of * as >>> multiplication? Probably not, because confusion can arise about >>> equally both for prefix and for postfix. >> >> I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" >> and similar expressions, felt "(p++)* = (q++)*" was unclear? > > Why would it require parentheses? Not necessarily (I think). Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 19:32 +0300 |
| Message-ID | <20261018193201.00000b13@yahoo.com> |
| In reply to | #403283 |
On Sun, 18 Oct 2026 18:11:18 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-10-18 17:26, Michael S wrote: > > On Sun, 18 Oct 2026 16:58:38 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/10/2026 16:24, Michael S wrote: > [...] > >>> It would be interesting to find out why designers of C, or of one > >>> of its ancestors decided that * as prefix is preferable to * as > >>> postfix. > > Because it is more "natural" when read, easier to grasp? IMHO, no. >Simpler for compilers? 100% no. > More consistent if all other, especially standard > operators known from daily use are used in prefix-form (-5, +42, > !false, ~bitset) in expressions? Unary * is more similar in function to postfix operators like [] and () than to those you mentioned. > > I don't recall to have used any language with infix-expressions > that would have their monadic operators defined in postfix form. I am a Bear of Very Little Brain, and long words Bother Me. By chance, did you never use Pascal? > The only exception was "C" (and C-oriented languages) with their > special case of post-increment/post-decrement operators. (Think > also about the quirk in C++ to define monadic postfix operators > that require a syntactic dummy type argument). (In low-level RPN > systems it may appear more "natural", but that just aside.) > > >>> Were they afraid of confusion with usage of * as > >>> multiplication? Probably not, because confusion can arise about > >>> equally both for prefix and for postfix. > >> > >> I don't know why it is prefix. Maybe they were keen on "*p++ = > >> *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear? > >> > > > > Why would it require parentheses? > > Not necessarily (I think). > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-15 05:17 -0700 |
| Message-ID | <86bj8vqhtl.fsf@linuxsc.com> |
| In reply to | #403173 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote: > >> On 14/10/2026 20:30, Dan Cross wrote: >> [snip more of the same already hashed and rehashed ad naseum] >> >> As for multiple nested loops, this will fix that too, that's great. We >> just require some real examples of that being needed! > > Here's a pretty terrible way to write part of a lexical > analyzer. I just typed this in an hour or so ago. > > [200+ lines of code] This code provides an excellent example of why multi-level breaks should not be added to C. The code would be easier to understand if all the 'break <label>;' lines were replaced with one of 'goto TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate, and with the loop labels being removed and the two new labels put in at the appropriate places.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-15 14:37 +0000 |
| Message-ID | <11aqoep$82u$1@reader2.panix.com> |
| In reply to | #403187 |
In article <86bj8vqhtl.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> >>> On 14/10/2026 20:30, Dan Cross wrote: >>> [snip more of the same already hashed and rehashed ad naseum] >>> >>> As for multiple nested loops, this will fix that too, that's great. We >>> just require some real examples of that being needed! >> >> Here's a pretty terrible way to write part of a lexical >> analyzer. I just typed this in an hour or so ago. >> >> [200+ lines of code] > >This code provides an excellent example of why multi-level breaks >should not be added to C. It is probably true that this snippet is a good example of how labeled break/continue can be abused. The code is awful. However, the current C2y draft standard already has labeled break and continue; the probability that it won't make it into the next standard revision is low. Moreover, other languages have had it for years (in some cases, decades) at this point and the sky has not fallen. One bad example, meant only to illustrate a couple of use cases, should not be used as evidence either way to draw a general conclusion about, well, anything. >The code would be easier to understand >if all the 'break <label>;' lines were replaced with one of 'goto >TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate, >and with the loop labels being removed and the two new labels put >in at the appropriate places. Whenever one says that, "the code would be easier to understand" one is necessarily making a subjective judgement. In this case, _I_ think that code would be far easier to understand written in an entirely different way that didn't reach for `goto` at all. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-15 20:50 +0200 |
| Message-ID | <11ar7a6$206gg$1@dont-email.me> |
| In reply to | #403189 |
On 2026-10-15 16:37, Dan Cross wrote: > In article <86bj8vqhtl.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> [...] > > It is probably true that this snippet is a good example of how > labeled break/continue can be abused. [...] Else-thread (in a reply to bart) you had already written: > > The point was to illustrate a contrived > example where one might break out of nested switch statements, > loops inside of switch, switch inside of loops, loops inside of > switch inside of loops, and so on. In a newsgroup (also generally) where part of the audience isn't interested in understanding the context and intention of such examples it's "good" fodder for those to continue their campaign. Of course your example with its intent were obvious and clear. Your formerly posted explanations without code had already been clear. (I.e., for those that were interested to understand the point. For those that aren't, with every additional post, and especially with lots of code, you just feed the... - campaigners. Wasted time, IMO.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-15 19:59 +0100 |
| Message-ID | <11ar7rb$2mb01$1@dont-email.me> |
| In reply to | #403187 |
On 15/10/2026 13:17, Tim Rentsch wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>
>>> On 14/10/2026 20:30, Dan Cross wrote:
>>> [snip more of the same already hashed and rehashed ad naseum]
>>>
>>> As for multiple nested loops, this will fix that too, that's great. We
>>> just require some real examples of that being needed!
>>
>> Here's a pretty terrible way to write part of a lexical
>> analyzer. I just typed this in an hour or so ago.
>>
>> [200+ lines of code]
>
> This code provides an excellent example of why multi-level breaks
> should not be added to C.
Actually most of those 'break-labels' are not multi-level breaks.
But they have to use that form because they are inside 'switch'.
(Unless you consider 'levels' to include switch statements as loops; I
don't. I mean, there is a 'continue' in there too inside switch, which
doesn't use the label. So how can that not be multi-level but 'break' is?)
It all goes back to that bad decision about 'break' that everyone is
playing down.
> The code would be easier to understand
> if all the 'break <label>;' lines were replaced with one of 'goto
> TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate,
> and with the loop labels being removed and the two new labels put
> in at the appropriate places.
Once you have to write /actual labels/, which aren't even in local scope
within the loop, then 'break label' doesn't buy much over 'goto label':
loop:
while () {
switch () {
case x:
break loop;
}
}
while () {
switch () {
case x:
goto loopend;
}
}
loopend:
The latter will at least work with every compiler.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-15 20:49 +0000 |
| Message-ID | <11are89$peu$1@reader2.panix.com> |
| In reply to | #403194 |
In article <11ar7rb$2mb01$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 15/10/2026 13:17, Tim Rentsch wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>> In article <11aoqa9$1rgda$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>
>>>> On 14/10/2026 20:30, Dan Cross wrote:
>>>> [snip more of the same already hashed and rehashed ad naseum]
>>>>
>>>> As for multiple nested loops, this will fix that too, that's great. We
>>>> just require some real examples of that being needed!
>>>
>>> Here's a pretty terrible way to write part of a lexical
>>> analyzer. I just typed this in an hour or so ago.
>>>
>>> [200+ lines of code]
>>
>> This code provides an excellent example of why multi-level breaks
>> should not be added to C.
>
>Actually most of those 'break-labels' are not multi-level breaks.
>
>But they have to use that form because they are inside 'switch'.
>
>(Unless you consider 'levels' to include switch statements as loops; I
>don't. I mean, there is a 'continue' in there too inside switch, which
>doesn't use the label. So how can that not be multi-level but 'break' is?)
>
>It all goes back to that bad decision about 'break' that everyone is
>playing down.
>
>> The code would be easier to understand
>> if all the 'break <label>;' lines were replaced with one of 'goto
>> TOKEN_COMPLETE;' or 'goto COMMENT_COMPLETE;', as appropriate,
>> and with the loop labels being removed and the two new labels put
>> in at the appropriate places.
>
>
>Once you have to write /actual labels/, which aren't even in local scope
>within the loop, then 'break label' doesn't buy much over 'goto label':
>
> loop:
> while () {
> switch () {
> case x:
> break loop;
> }
> }
>
> while () {
> switch () {
> case x:
> goto loopend;
> }
> }
> loopend:
>
>The latter will at least work with every compiler.
I mentioned this already; labeled continue and labeled break
both consume only one label; `goto` would require two:
outer:
for (i = 0; i < n; i++)
for (j = 0; j < m; j++)
if (condx(i, j)) break outer;
else if (condy(i, j)) continue outer;
vs:
for (i = 0; i < n; i++) {
for (j = 0; j < m; j++)
if (condx(i, j)) goto outer_break;
else if (condy(i, j)) goto outer_continue;
outer_continue:
}
outer_break:
And so forth.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-14 18:51 +0100 |
| Message-ID | <11aoff0$1n82v$1@dont-email.me> |
| In reply to | #403150 |
On 14/10/2026 13:38, Dan Cross wrote:
> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
> Yes, I am aware that you will tell me that it is justified
> because that problem is actually the one worth solving, and the
> others are not; you needn't bother. Simply put, I disagree that
> that one problem is sufficiently important to warrant its own
> solution, particularly when something more general is already
> known and available in the language (labeled break/continue).
I missed this bit.
Is labeled break now available in C?
If so, how would it be used here:
while (1) {
switch (x) {
case y:
Break;
where that Break is meant to quit the loop.
Remember that if DMR hadn't made that screw-up in 1972 it would simply
have been as it is above with his choice of keyword in place of Break.
But I would be interested in trying out the new feature.
[toc] | [prev] | [next] | [standalone]
| From | "Peyton" <peyton@solacium.com> |
|---|---|
| Date | 2026-10-14 11:04 -0700 |
| Message-ID | <87zewgxip7.fsf@peyton-d> |
| In reply to | #403159 |
bart <bc@freeuk.com> writes:
> On 14/10/2026 13:38, Dan Cross wrote:
>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>> Yes, I am aware that you will tell me that it is justified
>> because that problem is actually the one worth solving, and the
>> others are not; you needn't bother. Simply put, I disagree that
>> that one problem is sufficiently important to warrant its own
>> solution, particularly when something more general is already
>> known and available in the language (labeled break/continue).
>
> I missed this bit.
>
> Is labeled break now available in C?
>
> If so, how would it be used here:
>
>
> while (1) {
> switch (x) {
> case y:
> Break;
>
> where that Break is meant to quit the loop.
>
> Remember that if DMR hadn't made that screw-up in 1972 it would simply
> have been as it is above with his choice of keyword in place of Break.
>
> But I would be interested in trying out the new feature.
>
>
No it's definetely not supported yet. I am very much in support of it
though. Not sure when or if. In the meantime I guess you can use the
forbidden goto like so:
while(1) {
switch(x) {
case 1:
doThing();
break;
case 2:
goto exitLoop;
default:
break;
}
}
exitLoop;
--
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-14 19:47 +0000 |
| Message-ID | <11aom8a$6sa$1@reader2.panix.com> |
| In reply to | #403159 |
In article <11aoff0$1n82v$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 14/10/2026 13:38, Dan Cross wrote:
>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>> Yes, I am aware that you will tell me that it is justified
>> because that problem is actually the one worth solving, and the
>> others are not; you needn't bother. Simply put, I disagree that
>> that one problem is sufficiently important to warrant its own
>> solution, particularly when something more general is already
>> known and available in the language (labeled break/continue).
>
>I missed this bit.
>
>Is labeled break now available in C?
It's in C2y, and has been implemented in (at least) LLVM/clang
and GCC. I don't know about other compilers.
>If so, how would it be used here:
>
>
> while (1) {
> switch (x) {
> case y:
> Break;
>
>where that Break is meant to quit the loop.
term% cat lb.c
#include <stdio.h>
int
main(void)
{
int sum = 0;
outer:
for (int i = 0; i < 100; i++) {
for (int j = 0; j < 100; j++) {
int p = i * j;
switch (p) {
case 500:
break outer;
default:
sum += p;
break;
}
}
}
printf("sum = %d\n", sum);
return 0;
}
term% clang-23 -std=c2y -o lb lb.c
term% ./lb
sum = 235000
term% gcc-16 -std=c2y -o lb lb.c
term% ./lb
sum = 235000
term% sed 's/outer./\;/' lb.c >lb2.c
term% clang-23 -std=c2y -o lb2 lb2.c
term% ./lb2
sum = 24500500
term%
>Remember that if DMR hadn't made that screw-up in 1972 it would simply
>have been as it is above with his choice of keyword in place of Break.
As I said in my other post, you incorrectly assume that that was
the fundamental issue, when really it's just a detail: the
problem was that no facility to break out of nested control
structures as provided. Remedied now!
>But I would be interested in trying out the new feature.
So do it. You don't need me to hold your hand.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-14 13:58 -0700 |
| Message-ID | <11aoqed$1qib2$1@kst.eternal-september.org> |
| In reply to | #403159 |
bart <bc@freeuk.com> writes:
> On 14/10/2026 13:38, Dan Cross wrote:
>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>> Yes, I am aware that you will tell me that it is justified
>> because that problem is actually the one worth solving, and the
>> others are not; you needn't bother. Simply put, I disagree that
>> that one problem is sufficiently important to warrant its own
>> solution, particularly when something more general is already
>> known and available in the language (labeled break/continue).
>
> I missed this bit.
How?? I've mentioned it more than once in this thread.
> Is labeled break now available in C?
It's proposed for C2y, and implemented as an extension in gcc and clang.
The latest C2y draft is
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf
6.8.2 describes named iteration and switch statements.
6.8.7.3 and 6.8.7.4 describe the "continue" and "break" statements.
> If so, how would it be used here:
>
> while (1) {
> switch (x) {
> case y:
> Break;
>
> where that Break is meant to quit the loop.
I have no doubt that you can figure it out after reading the cited
sections. (I'm not sure why you spelled "break" with an uppercase 'B'.)
[...]
Elsewhere, you've mentioned that labels have function scope.
That's not a problem. A named "break" or "continue" can only
refer to the label of an enclosing iteration or switch statement.
"break FOO;" where FOO does not apply to an enclosing loop or switch
is a constraint violation. But "goto FOO;" is valid as long as
"FOO:" is within the same function (with some restrictions that
aren't relevant here).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-15 12:08 +0200 |
| Message-ID | <11aq8nn$206gh$1@dont-email.me> |
| In reply to | #403168 |
On 2026-10-14 22:58, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 14/10/2026 13:38, Dan Cross wrote: >>> In article <11anobe$1dt0e$1@dont-email.me>, bart <bc@freeuk.com> wrote: >> >>> Yes, I am aware that you will tell me that it is justified >>> because that problem is actually the one worth solving, and the >>> others are not; you needn't bother. Simply put, I disagree that >>> that one problem is sufficiently important to warrant its own >>> solution, particularly when something more general is already >>> known and available in the language (labeled break/continue). >> >> I missed this bit. > > How?? If operating one's intellect in a batten-down-the-hatches mode, or if a brain is working in /dev/null mode, are two possibilities that occur to me to miss that. I also see the possibility that in a heated discussion one might be tempted to prioritize a rebuttal in a post without beforehand taking the time thinking about the provided information. (Although the former two possibilities seem more likely in this case.) > I've mentioned it more than once in this thread. A couple other posters as well. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-14 14:23 -0700 |
| Message-ID | <11aorsh$1qib2$2@kst.eternal-september.org> |
| In reply to | #403148 |
bart <bc@freeuk.com> writes:
[...]
>> But as Keith pointed out, W14 is now entertaining proposals to
>> add labeled `break` to the language. I haven't looked myself,
>> but if that is usable in a `switch` context, then it would solve
>> the problem for good.
>
> OK. Although in that form, it really is little different from
> 'goto'. I believe the main difference is that the label goes at the
> beginning of the loop rather than the end!
Hardly.
Like most or all "structured" control flow constructs, it's a kind of
restricted goto -- and it's the restrictions that make it useful in
writing clear code.
"break", with or without a label, can only jump forward. That makes it
much more difficult to use it to write spaghetti code.
Yes, "break FOO;" is equivalent to a goto, given an appropriately placed
label. So what?
FOO:
for (blah;blah;blah) {
BAR:
while (blah) {
if (cond1) {
break FOO;
}
else if (cond2) {
break BAR;
}
}
}
"break FOO" is implemented as a jump to a point just after the end
of the outer loop. But the way I think of it is that "FOO" is the
name of the entire outer loop, not just a single point in the code.
"break FOO;" applies to the named loop, causing execution of the
loop to terminate. The fact that it's equivalent to a goto (just
as "break;" is) is an implementation detail.
One very minor infelicity is that the same syntax is used for labels
intended to be the targets of gotos and labels intended to name
loops and switch statements. I think this same issue occurs in
most languages that have named breaks. (Ada is an exception; it
uses a deliberately heavy syntax for goto labels, "<<LABEL>>", and
a simpler syntax for loop names, "NAME:". But Ada had both gotos
and named loops from the begining.) There has been a proposal to
use a different syntax for named loops ("for NAME (;;)"), but it's
not reflected in the latest C2y draft. The fact that a loop name
can also be used as the target of a goto is a trivial problem,
perhaps a non-problem, solved by just not doing that.
> And maybe those scoping rules will be different: goto labels have
> function-wide scope.
See the C2y draft.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web