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-11 22:12 +0000 |
| Articles | 20 on this page of 237 — 20 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 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 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-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 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 11:16 +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 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -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 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
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 16:08 -0700 |
| Message-ID | <11a3v19$2cj40$4@dont-email.me> |
| In reply to | #402741 |
On 10/6/2026 3:41 AM, David Brown wrote: [...] > Anyone who sometimes makes mistakes should enable warnings. And that > means /everyone/ should enable copious warnings. [...] Coin that!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-06 23:45 +0000 |
| Message-ID | <11a417c$2d9m7$3@dont-email.me> |
| In reply to | #402766 |
On Tue, 6 Oct 2026 16:08:25 -0700, Chris M. Thomasson wrote: > On 10/6/2026 3:41 AM, David Brown wrote: > >> Anyone who sometimes makes mistakes should enable warnings. And >> that means /everyone/ should enable copious warnings. > > Coin that! Then there is “confirmation fatigue”, where you get too inured to ignoring spurious warnings, and miss the important one(s) in among the noise. I don’t think there is any idiot-proof way to avoid being an idiot ...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 17:08 -0700 |
| Message-ID | <11a42ia$2dppj$2@dont-email.me> |
| In reply to | #402769 |
On 10/6/2026 4:45 PM, Lawrence D’Oliveiro wrote: > On Tue, 6 Oct 2026 16:08:25 -0700, Chris M. Thomasson wrote: > >> On 10/6/2026 3:41 AM, David Brown wrote: >> >>> Anyone who sometimes makes mistakes should enable warnings. And >>> that means /everyone/ should enable copious warnings. >> >> Coin that! > > Then there is “confirmation fatigue”, where you get too inured to > ignoring spurious warnings, and miss the important one(s) in among the > noise. > > I don’t think there is any idiot-proof way to avoid being an idiot ... Some where out there a pro has made a mistake...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 10:35 +0200 |
| Message-ID | <11a508q$2m3b3$1@dont-email.me> |
| In reply to | #402769 |
On 07/10/2026 01:45, Lawrence D’Oliveiro wrote: > On Tue, 6 Oct 2026 16:08:25 -0700, Chris M. Thomasson wrote: > >> On 10/6/2026 3:41 AM, David Brown wrote: >> >>> Anyone who sometimes makes mistakes should enable warnings. And >>> that means /everyone/ should enable copious warnings. >> >> Coin that! > > Then there is “confirmation fatigue”, where you get too inured to > ignoring spurious warnings, and miss the important one(s) in among the > noise. Enabling lots of warning options does not mean triggering lots of warnings! > > I don’t think there is any idiot-proof way to avoid being an idiot ...
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-06 12:33 +0100 |
| Message-ID | <11a2maj$1sode$1@dont-email.me> |
| In reply to | #402733 |
On 06/10/2026 08:49, David Brown wrote:
> On 06/10/2026 01:11, bart wrote:
>> * Is the transgression serious? Is so then report an error and fail to
>> compile
>
> Who decides what is serious or not?
I consider these serious:
int F(){} // no return statement
int F(){return;} // no return value
int F(){
F(1,2,3); // nonsensical calls
F("HELLO");
}
None of gcc 10, gcc 14, clang 19, tcc report a hard error in default mode.
Here I find it hard to believe that the language actually allows this.
There are also:
int* A[10]; // array of pointer to int
*A[i]; // index array then deref ptr
(*A)[i]; // deref array then index ptr - WTF?
Compilers say nothing; but they can't because it is how C works.
Also:
for (i = 0; i <= n; ++n);
printf("%f", i)
A few things going on here: "<=" likely wrong; so is "++n"; so is that
first ");"; so is that format.
The gccs say nothing. Clang warns on that ");" and the "%f".
Then:
if (i = 0) {}
i == 0;
Those =/== are most likely the wrong way around, but only clang warns.
But then:
if (i = F()){}
gives me the same warning, even though this is likely correct.
> Some people in this group would say that shadowing an existing
> identifier is a serious transgression, and should not be allowed in the
> code. Others say it is entirely fine. The C language standards are
> clear on exactly how it works, and that it is legal C - so a C compiler
> should not complain about it by default. But for those that think it is
> bad, gcc gives you the option and lets you choose if you see it as an
> error, a warning, or you will ignore it. It lets you fine-tune some
> aspects of which type of shadowing you want to catch or allow. It lets
> you have a general "no shadowing" policy but mark cases in code where
> you allow exceptions. The /programmer/ makes the choices here.
That is not a great solution. Everyone then creates their own dialect.
Ideally, if you have a C program written to a particular standard, then
any C compiler for that standard should be able to build it without any
special options.
> As usual, you live and think within your little bubble where /you/ are
> the language designer, the toolchain writer, and the sole user - you get
> to decide everything,
I get to enforce not only what /I/ think is right, but what would
generally be agreed to be right.
Most of those issues above (and dozens more examples I could show) are
impossible to express in my language.
In the case of mixing up =/==, then for me it would be ':=/=', where it
is less likely I'd write 'i := 0' for a condition. While this:
i == 0;
which would be 'i = 0' in my syntax, is disallowed. (I used to write
this by mistake after working with C or Python.)
>> But, since it is valid code, I would still say leave to an explicit
>> linker. (Here, gcc won't report it unless instructed, but it doesn't
>> make the compiler much faster if those options are turned off! I could
>> be wrong though; maybe they make it even slower when turned on.)
>>
>
> Key here is that this is /valid/ code, and merely /likely/ to be false.
> Compilers should, by default, accept it at face value - and they should
> make it easy to enable warnings that spot such likely bad code. This
> should not be something that you find later on, when you get round to
> running a linter.
The problem is the whole language is kaput, and fixing it by detecting a
few patterns is just touching the surface.
This:
sizeof(A)/sizeof(B[0])
is probably a mistake. Clang will warn, gcc can warn, except that
sometimes you may well want to divide one size by another, but the same
warning is produced with sizeof(A)/sizeof(B).
It's a mess. This is a non-issue in my language because I just write A.len.
In 1975 somebody could have simply added a lengthof() macro to C, if
making it built-in was too problematic.
So C just consistently keeps making a rod for its own back.
>>>> However I don't believe that what we're talking about here really is
>>>> linting either, since it isn't /its/ job to make up for shortcomings of
>>>> a language.
>>>
>>> If you think you have a language that has no shortcomings, and
>>> are still writing a linting tool, of course you must believe that
>>> the tool does something other than address shortcomings
>>> in the language.
>>
>> My own languages will have plenty of their own problems, but not the
>> kinds of howlers that you get in C.
>>
>> Linting (via the advanced options of gcc, clang etc) is what is
>> advocated here but I don't think much of it as it doesn't fix the
>> underlying problem, which is a poorly designed language.
>>
>
> "There are two sorts of programming languages - the ones people complain
> about, and the ones no one uses."
So, I'm complaining about it!
The problem is that people coming into C think that that systems
language as this level necessarily needs to be like this. It doesn't.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 17:16 +0200 |
| Message-ID | <11a33ce$218om$1@dont-email.me> |
| In reply to | #402746 |
On 06/10/2026 13:33, bart wrote:
> On 06/10/2026 08:49, David Brown wrote:
>> On 06/10/2026 01:11, bart wrote:
>
>>> * Is the transgression serious? Is so then report an error and fail to
>>> compile
>>
>> Who decides what is serious or not?
>
>
> I consider these serious:
Ok, but those are mostly just opinions (even if I, and many other
people, share those opinions). When you are writing a compiler that
only you will ever use, you can implement your opinions as hard errors.
When someone is writing a compiler for vast numbers of other users, and
those users expect it to accept the same code earlier versions accepted,
you don't get to play dictator.
>
> int F(){} // no return statement
So enable basic warnings -Wall, and you get a complaint. Make these
basic warnings errors with -Werror=all, and you get errors.
I'd prefer if compilers considered that a compile-stopping error in
their default modes, and required a flag to accept it. But I understand
exactly why real-world tools have to allow it - the C standard says it
is allowed, due to compatibility with older C. It is UB to attempt to
use the value "returned" by calling F(), but it is not UB to call F()
without using the return value. None of this is a "design flaw" in C,
or a problem with C compilers - it is an unfortunate side-effect of the
way the language evolved along with the requirement of backwards
compatibility. Remember, C is a real-life mainstream language, not a
one-man project where you can change the language to match the colour of
your socks. Few people would design a /new/ language that allowed "int
F() {}", but C is not a new language.
Of course, none of this is a problem in reality for anyone remotely
capable of using a C compiler.
>
> int F(){return;} // no return value
That is a constraint violation - standards-compliant C compilers are
required to issue a diagnostic (not necessarily an error). gcc has done
so, without requiring any additional flags, since version 5. (gcc, as
you know, is not standards-compliant by default.) "gcc -Wall" has done
so for much longer. Since gcc 14, it is an error by default and
requires an explicit flag to allow it to compile.
>
> int F(){
> F(1,2,3); // nonsensical calls
> F("HELLO");
> }
These are not nonsensical, in that this has well-defined behaviour in
terms of C (up to C23). No language can stop you writing silly things.
By writing "int F() {", you said that "F" is a function that returns an
int, and you - the programmer - take /full/ responsibility for ensuring
that the number and type of parameters in the call are compatible with
the definition of the function. You don't get to tell the compiler
"trust me - even if I write something that seems wrong, I know what I am
doing" and then complain when it believes you.
In C23, "int f()" means the same as "int f(void)", so from gcc 15
onwards (where "gnu23" is the default standard) it is a constraint
error, leading to a compile-time error.
With "-Wall", you get a warning that there is no "int" return, and from
gcc 12 onwards it gives you a warning that there is infinite recursion.
So a simple "gcc -Wall" - which any user of gcc should manage - gives
you all that you want, and more. A bit more careful use gives you
errors instead of warnings, in case the user is incapable of paying
attention to warning messages.
And yet at the same time, you think it is terrible that compilers
provide warnings and checks, and you don't want to waste precious
microseconds using them. The hypocrisy is unbounded.
>
> None of gcc 10, gcc 14, clang 19, tcc report a hard error in default mode.
>
> Here I find it hard to believe that the language actually allows this.
For someone who claims to have written a C compiler, you are remarkably
ignorant about the language.
>
> There are also:
<snip more cherry-picking whines about C that are not relevant here>
If you want to program in C, you should :
a) Learn basic C;
b) Learn to use real compilers;
c) Stop writing intentionally stupid code.
You are most of the way through "a". Try to complete the other tasks.
>
>> Some people in this group would say that shadowing an existing
>> identifier is a serious transgression, and should not be allowed in
>> the code. Others say it is entirely fine. The C language standards
>> are clear on exactly how it works, and that it is legal C - so a C
>> compiler should not complain about it by default. But for those that
>> think it is bad, gcc gives you the option and lets you choose if you
>> see it as an error, a warning, or you will ignore it. It lets you
>> fine-tune some aspects of which type of shadowing you want to catch or
>> allow. It lets you have a general "no shadowing" policy but mark
>> cases in code where you allow exceptions. The /programmer/ makes the
>> choices here.
>
> That is not a great solution. Everyone then creates their own dialect.
People /want/, indeed /need/, different "dialects". I don't use the
same style of English when chatting with my kids as I would in a letter
to my bank manager. The style of C code used for a program on Windows
is different from the style of C code appropriate for a small
microcontroller.
>
> Ideally, if you have a C program written to a particular standard, then
> any C compiler for that standard should be able to build it without any
> special options.
Why should that be an "ideal" ?
Code is typically written to a particular standard, but if a compiler
provides extensions that are useful to a given project, and the project
does not need to be portable to other compilers, then use those
extensions. If your project is better from the use of special options,
use those special options. (Ideally, the code should exhibit
compile-time failures if it relies on features that are not provided by
another compiler or option-set.)
If you are writing code that must be highly portable, then you need to
stick strictly to standards - but the great majority of code either has
no need of portability, or has limits on how portable it must be.
And anyway, choice of warning options is about picking a /subset/ of the
language that you want to use. All the warnings I use do not stop my
code from being standard C (of a particular given standard number) with
occasional gcc extensions.
>
>
>> As usual, you live and think within your little bubble where /you/ are
>> the language designer, the toolchain writer, and the sole user - you
>> get to decide everything,
>
> I get to enforce not only what /I/ think is right, but what would
> generally be agreed to be right.
It's your language. You have a North Korean democracy - one man, one
vote, and you are that man. What is "generally agreed" is what you
personally think.
As for gcc, the developers are wise enough to know that pretending there
is any general consensus is a fools' game. They make the options
available, and let people choose what they want. Some options can be
collected together in groups like "-Wall", or "-O2", or enabled by
default - but those are based on the general agreement of the gcc
developers and anyone who talks about them in mailing lists and issue
reports. They don't claim to know what is "generally agreed", despite
having vastly more experience of vastly more types of C code than you do.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-06 16:41 -0700 |
| Message-ID | <11a40vm$2dcfl$1@kst.eternal-september.org> |
| In reply to | #402746 |
bart <bc@freeuk.com> writes:
> On 06/10/2026 08:49, David Brown wrote:
>> On 06/10/2026 01:11, bart wrote:
>>> * Is the transgression serious? Is so then report an error and fail to
>>> compile
>> Who decides what is serious or not?
>
> I consider these serious:
>
> int F(){} // no return statement
>
> int F(){return;} // no return value
>
> int F(){
> F(1,2,3); // nonsensical calls
> F("HELLO");
> }
>
> None of gcc 10, gcc 14, clang 19, tcc report a hard error in default mode.
[...]
The distinction between hard errors and nonexisting warnings is not
as significant as you seem to think it is. gcc produces non-fatal
warnings for many things that are actually constraint violations.
Either pay closer attention to warnings, or invoke gcc in a way
that produces the hard errors you want. You know how to do this.
For the first example, simply requiring a return statement in any
non-void function wouldn't do much good. It would catch trivial
errors like your example, but wouldn't catch cases like:
int F() {
if (condition) {
return 1;
}
}
where some execution paths reach the closing `}` and some do not.
I'd like to see a language change that covers cases like this,
and I've discussed it in this newsgroup. C# has some interesting
rules in this area, and I'd like to C adopt something similar.
"gcc -Wall" warns about your first example: "control reaches end of
non-void function".
The second example has been a constraint violation since C99. gcc
correctly diagnoses it. If some versions issue a non-fatal warning,
that's a gcc issue, not a C issue. If you're using a version of gcc
that assumes C90 by default, that's solvable by using a newer version.
In the third case, C23 makes both calls constraint violations. gcc
on my system (version 15.2.0, defaulting to C23 with GNU extensions)
flags both calls as hard errors.
Most of the problems you're complaining about have been fixed.
--
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 | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-10-06 12:14 +0200 |
| Message-ID | <11a2hma$1b7c$1@news.gegeweb.eu> |
| In reply to | #402721 |
On 10/6/26 01:11, bart wrote:
> With C, that leaves the question of what to do about common errors due
> to shortcomings:
>
> if (a = 0)
Yoda coding use you must :
if (0 = a)
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 12:43 +0200 |
| Message-ID | <11a2jcp$1qu9n$2@dont-email.me> |
| In reply to | #402740 |
On 06/10/2026 12:14, tTh wrote: > On 10/6/26 01:11, bart wrote: >> With C, that leaves the question of what to do about common errors due >> to shortcomings: >> >> if (a = 0) > > Yoda coding use you must : > > if (0 = a) > Yoda would prefer Forth : a @ 0= if
[toc] | [prev] | [next] | [standalone]
| From | Jim Jackson <jj@franjam.org.uk> |
|---|---|
| Date | 2026-10-06 11:47 +0000 |
| Message-ID | <slrn11c9ntt.2dn.jj@iridium.wf32df> |
| In reply to | #402721 |
On 2026-10-05, bart <bc@freeuk.com> wrote: > On 05/10/2026 22:48, Kaz Kylheku wrote: >> On 2026-10-05, bart <bc@freeuk.com> wrote: >>> A lot of what big compilers do is what used to be called 'linting'. >> >> I don't suspect you can get rid of that in any language. >> >> The reason is that as experience with the given language grows, it is >> found that programmers make certain mistakes, where making formal >> syntactic and semantic rules against those mistakes, and sticking >> them into the language, would be a poor idea. >> >> At some point, you are trying to design a pencil that cannot be >> used to draw an optical illusion. >> >>> I don't consider that to be their job, which should be to verify my >>> program and turn it into runnable code, and not give opinions. >> >> That's a waste of potential; why would you refuse a machine that >> can apply hundreds of deterministic pattern matching rules against >> possible trouble situations in hundreds of thousands of lines of code, >> in seconds. > > I simply don't care about it. I don't have seconds to waste either. Sorry? How long did it take you to write the long screed below? From the number and length of your posts you obviously have lots of time to waste! > Here are some common C-compiling scenarios: > > * You want to build a finished, working, debugged program from source. > This does need the compiler spending time double-guessing the author's > intentions, and in any case the person building it is not going to > mess with the source > > * You are building a program which is machine-transpiled C code. It > should be valid C with no errors. (If there are, that is the > responsibility of the transpiler author.) But again you don't care > about style, or the fact that there are lots of unused labels for > example (common in such code) > > * You've made a one-line change and just quickly want to run it again. > You don't want a style analysis on the same few thousand lines that > has already been recently done. > > Linting is something you might do every so often - not for routine builds. > > However, with C compilers it is common for warnings to be generated > rather than hard errors. > > This is blurring the line between compiling and linting: > > * Is the transgression serious? Is so then report an error and fail to > compile > > * If not then leave it to a linter. (These days that just means running > it through a big compiler.) > > With C, that leaves the question of what to do about common errors due > to shortcomings: > > if (a = 0) > > Here it is likely that this was supposed to be 'a == 0' (otherwise this > will always be false). > > But, since it is valid code, I would still say leave to an explicit > linker. (Here, gcc won't report it unless instructed, but it doesn't > make the compiler much faster if those options are turned off! I could > be wrong though; maybe they make it even slower when turned on.) > >>> However I don't believe that what we're talking about here really is >>> linting either, since it isn't /its/ job to make up for shortcomings of >>> a language. >> >> If you think you have a language that has no shortcomings, and >> are still writing a linting tool, of course you must believe that >> the tool does something other than address shortcomings >> in the language. > > My own languages will have plenty of their own problems, but not the > kinds of howlers that you get in C. > > Linting (via the advanced options of gcc, clang etc) is what is > advocated here but I don't think much of it as it doesn't fix the > underlying problem, which is a poorly designed language. > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 16:05 -0700 |
| Message-ID | <11a3usl$2cj40$3@dont-email.me> |
| In reply to | #402721 |
On 10/5/2026 4:11 PM, bart wrote: > On 05/10/2026 22:48, Kaz Kylheku wrote: >> On 2026-10-05, bart <bc@freeuk.com> wrote: >>> A lot of what big compilers do is what used to be called 'linting'. >> >> I don't suspect you can get rid of that in any language. >> >> The reason is that as experience with the given language grows, it is >> found that programmers make certain mistakes, where making formal >> syntactic and semantic rules against those mistakes, and sticking >> them into the language, would be a poor idea. >> >> At some point, you are trying to design a pencil that cannot be >> used to draw an optical illusion. >> >>> I don't consider that to be their job, which should be to verify my >>> program and turn it into runnable code, and not give opinions. >> >> That's a waste of potential; why would you refuse a machine that >> can apply hundreds of deterministic pattern matching rules against >> possible trouble situations in hundreds of thousands of lines of code, >> in seconds. > > I simply don't care about it. I don't have seconds to waste either. Why not? [...] >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-07 00:42 +0000 |
| Message-ID | <20261006171259.512@kylheku.com> |
| In reply to | #402721 |
On 2026-10-05, bart <bc@freeuk.com> wrote: > On 05/10/2026 22:48, Kaz Kylheku wrote: >> On 2026-10-05, bart <bc@freeuk.com> wrote: >>> A lot of what big compilers do is what used to be called 'linting'. >> >> I don't suspect you can get rid of that in any language. >> >> The reason is that as experience with the given language grows, it is >> found that programmers make certain mistakes, where making formal >> syntactic and semantic rules against those mistakes, and sticking >> them into the language, would be a poor idea. >> >> At some point, you are trying to design a pencil that cannot be >> used to draw an optical illusion. >> >>> I don't consider that to be their job, which should be to verify my >>> program and turn it into runnable code, and not give opinions. >> >> That's a waste of potential; why would you refuse a machine that >> can apply hundreds of deterministic pattern matching rules against >> possible trouble situations in hundreds of thousands of lines of code, >> in seconds. > > I simply don't care about it. I don't have seconds to waste either. Your implementation of the same thing would take milliseconds, of course. > Here are some common C-compiling scenarios: > > * You want to build a finished, working, debugged program from source. > This does need the compiler spending time double-guessing the author's > intentions, and in any case the person building it is not going to > mess with the source > > * You are building a program which is machine-transpiled C code. It > should be valid C with no errors. (If there are, that is the > responsibility of the transpiler author.) But again you don't care > about style, or the fact that there are lots of unused labels for > example (common in such code) Then * you still want linting in the source language. * even if you are generating C you could do something wrong that can be flagged by a C linter --- and you are in the best possible position to do something about it. THin about it: suppose you transpile 500,000 lines of code to about as many lines of C, and the C linter identifies 50,000 instances of the same error. You may be able to fix all of them with a one line change in your translator!!! (By contrast, if you have 50,000 individually hand-written instances of a lint violation, good luck ...) If you're in a great position to take advantage of linting, do it. > > * You've made a one-line change and just quickly want to run it again. > You don't want a style analysis on the same few thousand lines that > has already been recently done. > > Linting is something you might do every so often - not for routine builds. If you are in a closed loop already in which you have addressed all linting errors or else turned off specific diagnostics you're not interested in fixing, in fact you do follow up to all new lint issues caused by a change. It becomes like any other diagnostic. > However, with C compilers it is common for warnings to be generated > rather than hard errors. > > This is blurring the line between compiling and linting: No diagnosable situation in C according to ISO C is required to terminate translation immediately, or mark it unsuccessful. All diagnostic requirements are linting. :) > * Is the transgression serious? Is so then report an error and fail to > compile For instance, converting among incompatible pointer types without a cast is a required diagnostic by ISO C; it is "serious" in that it defeats the type system and can be the root cause of a crash. But it's just a formality in that you can insert the cast to request it and then the conversion doesn't require a diagnostic. (If the lack of the cast formality was the only thing stopping it from being correct, then it is correct; otherwise it stays incorrect.) The bottom line is that a program which converts among incompatible pointer types is not necessarily incorrect. It can be translated and it can work. There has been historically a "loosey goosey" attitude across the C landscape whereby the expectation is that compilers try to accept code and at worst grumble about it. A lot of the time this would actually just work by dumb luck; weird code that worked on one system on its compiler worked on another system with its compiler, and so the /apparent/ work of porting something to a new platform was reduced, even if it was by fluke. You are right in that this does not fly in all necks of the woods. Can you imagine Haskell people saying, oh, type checks are just gonna be warnings now ... :) Postel's Law, being "liberal in what you accept [etc]", isn't such a great idea. Hypothesis: was Postel inspired to that by exposure to C? History has brought us to a kind of reckoning. Attitudes of new people are different, the compilers have marched on, yet things are saddled with the historic baggage at the same time. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 13:52 +0100 |
| Message-ID | <11a5fa7$2sg9n$1@dont-email.me> |
| In reply to | #402775 |
On 07/10/2026 01:42, Kaz Kylheku wrote:
> On 2026-10-05, bart <bc@freeuk.com> wrote:
>> On 05/10/2026 22:48, Kaz Kylheku wrote:
>>> On 2026-10-05, bart <bc@freeuk.com> wrote:
>>>> A lot of what big compilers do is what used to be called 'linting'.
>>>
>>> I don't suspect you can get rid of that in any language.
>>>
>>> The reason is that as experience with the given language grows, it is
>>> found that programmers make certain mistakes, where making formal
>>> syntactic and semantic rules against those mistakes, and sticking
>>> them into the language, would be a poor idea.
>>>
>>> At some point, you are trying to design a pencil that cannot be
>>> used to draw an optical illusion.
>>>
>>>> I don't consider that to be their job, which should be to verify my
>>>> program and turn it into runnable code, and not give opinions.
>>>
>>> That's a waste of potential; why would you refuse a machine that
>>> can apply hundreds of deterministic pattern matching rules against
>>> possible trouble situations in hundreds of thousands of lines of code,
>>> in seconds.
>>
>> I simply don't care about it. I don't have seconds to waste either.
>
> Your implementation of the same thing would take milliseconds, of
> course.
I wouldn't want it at all.
But if I had to implement it, I don't know how long it would take. If I
found that it was taking disproportionately long (compared to the main
task of generating a binary), then I would separate it out from the
compiler, as I've suggested.
For example, if 90% of compile-time was spent on it.
>> Here are some common C-compiling scenarios:
>>
>> * You want to build a finished, working, debugged program from source.
>> This does need the compiler spending time double-guessing the author's
>> intentions, and in any case the person building it is not going to
>> mess with the source
>>
>> * You are building a program which is machine-transpiled C code. It
>> should be valid C with no errors. (If there are, that is the
>> responsibility of the transpiler author.) But again you don't care
>> about style, or the fact that there are lots of unused labels for
>> example (common in such code)
>
> Then
>
> * you still want linting in the source language.
Possibly. I don't care too much about that either. In my stuff, I do
very little in the way of advisory reports, which are only enabled
infrequently.
But the context here is using linting to warn about things that are a
consequence of C's design, such as switch 'break' that is the subject of
the thread.
I prefer to deal with that with a better language design.
> * even if you are generating C you could do something wrong
> that can be flagged by a C linter --- and you are in the best possible
> position to do something about it. THin about it: suppose you transpile
> 500,000 lines of code to about as many lines of C, and the C linter
> identifies 50,000 instances of the same error.
Example?
For transpiled C, the only problems in the C should be related to the
translation process (that is, in the transpiler source) and not to the
program being transpiled.
Once those are fixed, there is usually little need to look at the
generated C, and there should never be any messages about it.
Unless somebody decides to ramp up the warnings, but every generated C
file has a comment with suggested build instructions.
>> * Is the transgression serious? Is so then report an error and fail to
>> compile
>
> For instance, converting among incompatible pointer types without a cast
> is a required diagnostic by ISO C; it is "serious" in that it defeats
> the type system and can be the root cause of a crash.
Then it should be an error. If I try and compile this:
int *p, *q;
char *r;
p=r;
I get:
gcc 14 error
gcc 10 warning
clang 19 warning
tcc warning
bcc error
Clang is surprising here as it's normally a lot stricter by default than
gcc.
But why are even some compilers not downright failing this? If such an
assignment is known to be safe for a particular program, then it is a
small imposition to use a cast.
> But it's just a formality in that you can insert the cast to request
> it and then the conversion doesn't require a diagnostic.
> (If the lack of the cast formality was the only thing stopping it from
> being correct, then it is correct; otherwise it stays incorrect.)
>
> The bottom line is that a program which converts among incompatible
> pointer types is not necessarily incorrect. It can be translated
> and it can work.
Requiring a cast makes a program safer as it forces you to think about
it if compilation can't proceed otherwise.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-07 14:06 -0700 |
| Message-ID | <11a6c92$38ago$1@dont-email.me> |
| In reply to | #402796 |
On 10/7/2026 5:52 AM, bart wrote: > On 07/10/2026 01:42, Kaz Kylheku wrote: >> On 2026-10-05, bart <bc@freeuk.com> wrote: >>> On 05/10/2026 22:48, Kaz Kylheku wrote: >>>> On 2026-10-05, bart <bc@freeuk.com> wrote: >>>>> A lot of what big compilers do is what used to be called 'linting'. >>>> >>>> I don't suspect you can get rid of that in any language. >>>> >>>> The reason is that as experience with the given language grows, it is >>>> found that programmers make certain mistakes, where making formal >>>> syntactic and semantic rules against those mistakes, and sticking >>>> them into the language, would be a poor idea. >>>> >>>> At some point, you are trying to design a pencil that cannot be >>>> used to draw an optical illusion. >>>> >>>>> I don't consider that to be their job, which should be to verify my >>>>> program and turn it into runnable code, and not give opinions. >>>> >>>> That's a waste of potential; why would you refuse a machine that >>>> can apply hundreds of deterministic pattern matching rules against >>>> possible trouble situations in hundreds of thousands of lines of code, >>>> in seconds. >>> >>> I simply don't care about it. I don't have seconds to waste either. >> >> Your implementation of the same thing would take milliseconds, of >> course. > > I wouldn't want it at all. > > But if I had to implement it, I don't know how long it would take. If I > found that it was taking disproportionately long (compared to the main > task of generating a binary), then I would separate it out from the > compiler, as I've suggested. > > For example, if 90% of compile-time was spent on it. > > >>> Here are some common C-compiling scenarios: >>> >>> * You want to build a finished, working, debugged program from source. >>> This does need the compiler spending time double-guessing the >>> author's >>> intentions, and in any case the person building it is not going to >>> mess with the source >>> >>> * You are building a program which is machine-transpiled C code. It >>> should be valid C with no errors. (If there are, that is the >>> responsibility of the transpiler author.) But again you don't care >>> about style, or the fact that there are lots of unused labels for >>> example (common in such code) >> >> Then >> >> * you still want linting in the source language. > > Possibly. I don't care too much about that either. In my stuff, I do > very little in the way of advisory reports, which are only enabled > infrequently. > > But the context here is using linting to warn about things that are a > consequence of C's design, such as switch 'break' that is the subject of > the thread. > > I prefer to deal with that with a better language design. Are you making a "new" C?[...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 23:31 +0100 |
| Message-ID | <11a6h8e$3a3g6$1@dont-email.me> |
| In reply to | #402818 |
On 07/10/2026 22:06, Chris M. Thomasson wrote: > On 10/7/2026 5:52 AM, bart wrote: >> On 07/10/2026 01:42, Kaz Kylheku wrote: >>> On 2026-10-05, bart <bc@freeuk.com> wrote: >>>> On 05/10/2026 22:48, Kaz Kylheku wrote: >>>>> On 2026-10-05, bart <bc@freeuk.com> wrote: >>>>>> A lot of what big compilers do is what used to be called 'linting'. >>>>> >>>>> I don't suspect you can get rid of that in any language. >>>>> >>>>> The reason is that as experience with the given language grows, it is >>>>> found that programmers make certain mistakes, where making formal >>>>> syntactic and semantic rules against those mistakes, and sticking >>>>> them into the language, would be a poor idea. >>>>> >>>>> At some point, you are trying to design a pencil that cannot be >>>>> used to draw an optical illusion. >>>>> >>>>>> I don't consider that to be their job, which should be to verify my >>>>>> program and turn it into runnable code, and not give opinions. >>>>> >>>>> That's a waste of potential; why would you refuse a machine that >>>>> can apply hundreds of deterministic pattern matching rules against >>>>> possible trouble situations in hundreds of thousands of lines of code, >>>>> in seconds. >>>> >>>> I simply don't care about it. I don't have seconds to waste either. >>> >>> Your implementation of the same thing would take milliseconds, of >>> course. >> >> I wouldn't want it at all. >> >> But if I had to implement it, I don't know how long it would take. If >> I found that it was taking disproportionately long (compared to the >> main task of generating a binary), then I would separate it out from >> the compiler, as I've suggested. >> >> For example, if 90% of compile-time was spent on it. >> >> >>>> Here are some common C-compiling scenarios: >>>> >>>> * You want to build a finished, working, debugged program from source. >>>> This does need the compiler spending time double-guessing the >>>> author's >>>> intentions, and in any case the person building it is not going to >>>> mess with the source >>>> >>>> * You are building a program which is machine-transpiled C code. It >>>> should be valid C with no errors. (If there are, that is the >>>> responsibility of the transpiler author.) But again you don't care >>>> about style, or the fact that there are lots of unused labels for >>>> example (common in such code) >>> >>> Then >>> >>> * you still want linting in the source language. >> >> Possibly. I don't care too much about that either. In my stuff, I do >> very little in the way of advisory reports, which are only enabled >> infrequently. >> >> But the context here is using linting to warn about things that are a >> consequence of C's design, such as switch 'break' that is the subject >> of the thread. >> >> I prefer to deal with that with a better language design. > > Are you making a "new" C?[...] I'm not making anything. I have long maintained a personal systems language which fixes most of my moans about C (and even deals with some of fir's needs, but those seem to change erratically). It would have been good for /someone else/ to have evolved C in a direction I'd have found useful, but current evolvement of C is not interesting to me and IMO misguided. Since I have my own solutions for the little coding I do now, this doesn't matter so much - let C aficionados be masochists if they want. But I am still interested in tooling (which has its own masochists!).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-05 21:32 +0000 |
| Message-ID | <20261005142208.51@kylheku.com> |
| In reply to | #402655 |
On 2026-10-03, bart <bc@freeuk.com> wrote: > On 03/10/2026 17:02, David Brown wrote: >> On 03/10/2026 10:43, Lawrence D’Oliveiro wrote: >>> How not to forget to end each case-sequence in a switch statement with >>> a break-statement: put the break at the same indentation level as the >>> case-clause as well as the switch-expression. That way, you can scan >>> your eye down a single line for each switch-statement to be sure that >>> no breaks are missing. A reasonably-complex example, with a nested >>> switch for added interest: >>> >> >> gcc -Werror=implict-fallthrough > > > I assume this is for non-empty blocks? Otherwise this will be an error: > > case 'A': case 'B': case 'C': > // deal with ABC Note that syntactically: case 'A': case 'B': case 'C': ; // note semicolon are a nested case statement, and not consecutive statement syntax. The semicolon null statement is prefixed, or "labeled", if you will, by case 'C', making a case statement. Then case 'B' similarly prefixes this case statement to make a more nested case statement. Ditto with case 'C'. So there is no fallthrough here through statements at the same level of nesting. When control passes to case 'A' it is staying in the 'A' case statement right through the semicolon null statement, entering two more case statements along the way. I would hope that the compiler deos give you the warning if you have this: case 'A': ; case 'B': case 'C': ; // note another semicolon No we have a case 'A' statement, falling through to a case 'B' statement. In terms of how we think about this as C programmers, it clearly communicates the intent that 'A', 'B' and 'C' are one logical case reacting to three values. The programmer would not have the intent that in case 'A': case 'B', they would like case 'A' to stand apart as an empty case (whose break happens to be missing), followed by an unrelated case 'B'. It's not 100% impossible to have this kind of mistake, but it probably doesn't happen often enough to warrant tooling. Anyway the syntactic difference allows the compiler not to have to implement heuristics regarding guessing about intent, in this regard. It just has to do something like: look for complete case statements not embedded in other case statements which are not followed by a break. >> Let the tools handle the little stuff, so that you can spend time on >> more important things. > > Another hack! At least, a workaround for poor design in the language. If > only the creators had made a little more effort. Yes; effectively, with a diagnostic about missing breaks, we have created a modified dialect of C. That's one possible version of the "effort": one small adjustment in the specification. The scanning of the comment /is/ undeniably a hack, since it violates the idea that comments are only discarded by the translator. Once you have this kind of hack, you need to compound it. What if the programmer makes a typo like // fllthrough? In this case, the behavior of acting as if the comment is not there will work. Do you diagnose unnecessary uses of the comment? Say that // fallthrough precedes a break;, making it contradictory. Diagnose or not? And what if /that/ one is misspelled? If you ignore it, the issue is swept under the rug. The // fllthrough typo looks as if the programmer expected fallthrough, but somehow a break ended up there, but since we didn't recognize the comment due to the typo, it went undiagnosed. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-06 06:07 +0800 |
| Message-ID | <WcVwS.5186$Nbkf.3845@fx03.ams4> |
| In reply to | #402715 |
On 10/6/2026 5:32 AM, Kaz Kylheku wrote: > Do you diagnose unnecessary uses of the comment? Say that // fallthrough > precedes a break;, making it contradictory. Diagnose or not? > And what if/that/ one is misspelled? If you ignore it, the issue > is swept under the rug. The // fllthrough typo looks as if the > programmer expected fallthrough, but somehow a break ended up there, but > since we didn't recognize the comment due to the typo, it went > undiagnosed. We can take this further, and add spell chequer [1] to the compiler. Then we can trivially keep track of if the comments are spelled the same as the identifiers in the code, and can flag such things as errors, when Doxygen'd documents refer to nonexistent functions. It also has the added benefit of -- hopefully -- avoiding embarrassing mystakes, like spelling "referrer" with a single R, just like the H.T.T.P. standard mandates [2]. I mean, creat() is a famous example in Posix. Do you know more? [1] Some Americans are want to insist everything not in the spell chequer is a typo, but here I simply refer to the Oxfordian English Dictionary. https://www.oed.com/dictionary/chequer_n1?tl=true [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:; Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-05 16:42 -0700 |
| Message-ID | <11a1clv$1dg97$1@kst.eternal-september.org> |
| In reply to | #402715 |
Kaz Kylheku <046-301-5902@kylheku.com> writes:
> On 2026-10-03, bart <bc@freeuk.com> wrote:
>> On 03/10/2026 17:02, David Brown wrote:
[...]
>>> gcc -Werror=implict-fallthrough
>>
>> I assume this is for non-empty blocks? Otherwise this will be an error:
>>
>> case 'A': case 'B': case 'C':
>> // deal with ABC
>
> Note that syntactically:
>
> case 'A': case 'B': case 'C': ; // note semicolon
>
> are a nested case statement, and not consecutive statement
> syntax.
More precisely, it's a single labeled-statement. Breaking it down
according to the grammar:
; is a null statement
case 'C': ; is a labeled-statement
case 'B': case 'C': ; is a labeled-statement
case 'A': case 'B': case 'C': ; is a labeled-statement
Terminology aside, you're right. I've always thought of the three
case labels as three separate targets, with the switch statement
jumping to case 'A', for example, and falling through the others,
but that's not the best way to think about it.
On the other hand, the standard says control jumps to "the statement or
declaration following the matched case label". So if the controlling
expression evaluates to 'B', control jumps to the labeled statement
case 'B': case 'C': ;
while if it evaluates to 'C', control jumps to the labeled statement
case 'C': ;
Is that a "fallthrough"? Maybe. Should a compiler warn about it? No.
C23 adds some more complications by changing the grammatical
structure surrounding labels. A label is now a "block-item",
at the same syntactic level as a statement or declaration within
a block. I'll post about that separately.
gcc's documentation doesn't mention this. I've submitted a bug report :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127722
[...]
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-05 18:05 -0700 |
| Message-ID | <11a1hge$1gpor$1@kst.eternal-september.org> |
| In reply to | #402723 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Kaz Kylheku <046-301-5902@kylheku.com> writes:
>> On 2026-10-03, bart <bc@freeuk.com> wrote:
>>> On 03/10/2026 17:02, David Brown wrote:
> [...]
>>>> gcc -Werror=implict-fallthrough
>>>
>>> I assume this is for non-empty blocks? Otherwise this will be an error:
>>>
>>> case 'A': case 'B': case 'C':
>>> // deal with ABC
>>
>> Note that syntactically:
>>
>> case 'A': case 'B': case 'C': ; // note semicolon
>>
>> are a nested case statement, and not consecutive statement
>> syntax.
>
> More precisely, it's a single labeled-statement. Breaking it down
> according to the grammar:
>
> ; is a null statement
> case 'C': ; is a labeled-statement
> case 'B': case 'C': ; is a labeled-statement
> case 'A': case 'B': case 'C': ; is a labeled-statement
>
> Terminology aside, you're right. I've always thought of the three
> case labels as three separate targets, with the switch statement
> jumping to case 'A', for example, and falling through the others,
> but that's not the best way to think about it.
>
> On the other hand, the standard says control jumps to "the statement or
> declaration following the matched case label". So if the controlling
> expression evaluates to 'B', control jumps to the labeled statement
>
> case 'B': case 'C': ;
>
> while if it evaluates to 'C', control jumps to the labeled statement
>
> case 'C': ;
>
> Is that a "fallthrough"? Maybe. Should a compiler warn about it? No.
>
> C23 adds some more complications by changing the grammatical
> structure surrounding labels. A label is now a "block-item",
> at the same syntactic level as a statement or declaration within
> a block. I'll post about that separately.
[...]
I was going to start a new thread in comp.std.c, but the issues
have already been discussed, so I'll just post a followup here.
The following is language-lawyering that probably doesn't have
much effect on most programmers, so feel free to skip it.
The above discussion is valid for C17 and earlier, but not in C23.
C23 made some changes with the goal of allowing a label to be
immediately followed by a declaration or `}`. It did so by changing
the grammar for a compound-statement:
compound-statement:
{ block-item-list[opt] }
block-item-list:
block-item
block-item-list block-item
block-item:
declaration
unlabeled-statement
label
This means that in
switch (x) {
case 'A':
case 'B':
case 'C':
puts("blah");
}
*there is no labeled-statement*. Instead, each of `case 'A':`,
`case 'B':`, `case 'C':`, and `puts("blah");` is a block-item, and all
the block-items are at the same syntactic level within the
compound-statement. (The indentation is still appropriate IMHO.)
Since control jumps to "the statement or declaration following the
matched case label", there is no fallthrough. If x == 'A', control
jumps directly to the puts() call.
In C17 and earlier, the same wording implies that when x=='A', control
jumps to the statement
case 'B': case 'C': puts("blah");
so one might arguably refer to that as "fallthrough". In C23,
case 'B': case 'C': puts("blah");
is not a statement.
A weird but mostly harmless consequence of this is that C23 keeps
the syntactic construct of a *labeled-statement*, but it's used
extremely rarely. Any C17-or-earlier labeled-statement at the
top level of an enclosing compound-statement is no longer a C23
labeled-statement, even though it looks like one. In C23, a
labeled-statement can only occur in an odd construct like this:
if (condition)
LABEL: statement;
The proposal that led to this suggested an optional additional change,
making labels outside of compound statements an obsolescent feature.
That part of the proposal was not adopted.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf
If labels outside of compound statement were eventually removed,
the syntactic construct "labeled-statement" would become entirely
unnecessary -- and some existing but rare valid code would become
invalid.
(A syntactic construct exists in a program only if there's a
grammatical production that leads to it, not if a sequence of
tokens happens to match the construct's grammar. For example,
in `x * y + z`, `y + z` *looks like* an additive-expression, but
it isn't one because a parser never sees it as one. Similarly,
something that looks like a labeled-statement isn't necessarily
a labeled-statement.)
--
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-06 09:04 +0200 |
| Message-ID | <11a26hc$ef4n$2@dont-email.me> |
| In reply to | #402726 |
On 2026-10-06 03:05, Keith Thompson wrote: > [...] > > A weird but mostly harmless consequence of this is that C23 keeps > the syntactic construct of a *labeled-statement*, but it's used > extremely rarely. Any C17-or-earlier labeled-statement at the > top level of an enclosing compound-statement is no longer a C23 > labeled-statement, even though it looks like one. In C23, a > labeled-statement can only occur in an odd construct like this: > > if (condition) > LABEL: statement; You've been arguing on the implicit difference in the language definition here. That's all a fine explanation. What I wonder about is what you find "odd" with that construct. For folks who use jumps and labels (not me) that looks not too odd to me; I can imagine programming cases where that may be useful. Janis > [...]
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web