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 328 — 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 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 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 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-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 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 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
| 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 | 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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-14 14:35 +0000 |
| Message-ID | <frMzS.2749$e_i.171@fx08.iad> |
| In reply to | #403132 |
bart <bc@freeuk.com> writes: >On 13/10/2026 01:33, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >> [...] >I've got a better idea. I added an extra keyword to my C compiler called >"breakloop". It's like 'break' but always works with the nearest >enclosing loop, even from inside switch. It's hardly a new idea. The 1967 BPL compiler at burroughs supported 'EXITLOOP', 'EXITCOND', 'EXITCASE' and 'EXITBLOCK'; each with the expected semantics for the name.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-16 03:36 -0700 |
| Message-ID | <864iemq6ds.fsf@linuxsc.com> |
| In reply to | #402988 |
Andrey Tarasevich <noone@noone.net> writes:
> On Sun 10/11/2026 6:33 AM, David Brown wrote:
>
>> It is quite obvious that it is easy to write code with loops + break
>> within a switch. It is equally obvious that it is easy to avoid
>> such constructs - there are always ways to avoid a "break" in a
>> loop, and if the code run within a switch case is complex, it is
>> often practical to refactor it into a separate function. But
>> presumably Michael has reasons not do do that.
>
> Um... The common pattern for a "search"-style loop looks as follows
>
> for (/* domain condition */)
> {
> ...
> if (/* search condition */)
> break;
> ...
> }
>
> So, loops that terminate with `break` are the mainstay of every
> competently written code. Moving the "early termination" condition
> into the loop header (i.e. lumping the search condition with the
> domain condition) is a very ugly anti-pattern in most cases. Moreover,
> majority of the loops in an average C program are such "search"-style
> loops, meaning that they do have an "early termination" condition.
>
> Now, while overwhelming majority of my loops would use `if` to check
> the "early termination", I can imagine that there sill be cases where
> switch` is applicable and more appropriate than an `if`. Yes, a
> switch` can always be replaced with an `if` ladder, but being _forced_
> to do so by a language limitation doesn't look right.
>
> And writing a separate function just to work around a weird language
> limitation... that doesn't look right either.
I'm afraid I must simply flat out disagree with some of the comments
above.
Certainly it is true that many C programs use a for-if-break pattern
in some or many places. It's fair to call it a common pattern. But
it's wrong to say it is /the/ common pattern. There are other ways
of skinning that cat, and I expect most C programmers have used some
or all of them in the normal course of program development.
Similarly, the assertion that "loops that terminate with `break` are
the mainstay of every competently written code" is an absurd
overstatement. No doubt break-exiting loops are a significant part
of many programs. Probably they are a mainstay in some of them.
But to say they are /the/ mainstay in any non-trivial program is at
best a stretch; to assert that they are /the/ mainstay in /all/
competently written code is simply wrong.
I looked at some statistics for a couple of code bases. The relative
amounts of switch() versus loops (for(), while(), do/while()) was
relatively constant, about one in six or one in seven. Use of break
varied a lot, from close to six percent to under two percents (here
percent means percentage of occurrences of all control keywords).
The biggest category was if() and return, over 80% of the total and
roughly eight times the amount of looping structures. In the scheme
of things switch() is not very important. Loops are important. The
more prominent if() and return are very important. The idea that,
one, exiting a loop with break is always an essential program element
and, two, it's important to be able to do that using switch(), isn't
a good fit for the facts on the ground.
Incidentally, the comment that writing a separate function "doesn't
look right" seems backwards. Breaking large functions into smaller
functions is a good way to make code easier to understand. By their
nature switch() statements tend to be large (in terms of lines of
code) so putting the switch() inside a separate function is likely to
be a good thing, not a bad thing. The motivation for doing that is
not about working around a language limitation, but about writing
better code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-10 16:38 -0700 |
| Message-ID | <11aei9t$24k8m$4@kst.eternal-september.org> |
| In reply to | #402890 |
Michael S <already5chosen@yahoo.com> writes:
> On Sat, 10 Oct 2026 20:08:20 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-10-10 15:11, bart wrote:
>> >
>> > Well, Algol 68 doesn't even have 'break'. For unusual control-flow
>> > it needs goto.
>>
>> Yes. - And while "C" has 'goto' as well it also supports 'break' for
>> some purposes; e.g. as a loop-exit, so it makes sense to reuse that
>> keyword for other purposes as in 'switch' where it's been useful.
>
> After practicing C programming for more than 35 years I am deeply
> convinced that reuse of the same 'break' keyword for loops and for
> switch was a mistake. But then again, DRM did not have a benefit
> of hindsight.
Actually he (DMR) did. C's parent language, BCPL, had distinct BREAK
and ENDCASE keywords.
I agree that combining them both into "break" was a mistake. At this
point, I think the best solution is named loops and "break loop_name;".
There are proposals for C2y.
A distinct "endcase" keyword would have been cleaner IMHO, but code
using the existing case/break will continue to exist approximately
forever.
--
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 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web