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 189 — 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 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 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 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 1 of 10 [1] 2 3 … 10 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-03 08:43 +0000 |
| Subject | Taming The Switch-Statement |
| Message-ID | <119qf6l$2rmg3$1@dont-email.me> |
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:
real stack_calc
(
stackcalc_op op,
...
)
/* starting with an empty operand stack, carries out the specified
operations on the specified operands, at the end of which there
should be just a single value on the operand stack. This value is
popped and returned as the function result. */
{
real * opstack = NULL;
size_t
opstacklen = 0,
opstackalloc = 0;
real result;
va_list args;
va_start(args, op);
bool first = true;
bool done = false;
for (;;)
{
if (not first)
{
op = va_arg(args, stackcalc_op);
} /*if*/
first = false;
switch (op)
{
case STACKCALC_END:
done = true;
break;
case STACKCALC_PUSH:
{
if (opstacklen == opstackalloc)
{
opstackalloc += 16;
opstack = realloc(opstack, opstackalloc * sizeof(real));
bugcheck(opstack != NULL, "unable to expand operand stack beyond %d", opstacklen);
} /*if*/
opstack[opstacklen] = va_arg(args, real);
++opstacklen;
}
break;
case STACKCALC_ADD:
case STACKCALC_SUB:
case STACKCALC_MUL:
case STACKCALC_DIV:
bugcheck(opstacklen >= 2, "not enough operands for operator %d", op);
{
const real op2 = opstack[opstacklen - 1];
real op1 = opstack[opstacklen - 2];
switch (op)
{
case STACKCALC_ADD:
op1 += op2;
break;
case STACKCALC_SUB:
op1 -= op2;
break;
case STACKCALC_MUL:
op1 *= op2;
break;
case STACKCALC_DIV:
op1 /= op2;
break;
} /*switch*/
--opstacklen;
opstack[opstacklen - 1] = op1;
}
break;
default:
bugcheck(false, "invalid operator %d", op);
break;
} /*switch*/
if (done)
break;
} /*for*/
va_end(args);
bugcheck(opstacklen == 1, "expecting exactly one result left on stack");
result = opstack[0];
free(opstack);
return result;
} /*stack_calc*/
[toc] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-03 11:24 +0100 |
| Message-ID | <119ql55$2ttec$1@dont-email.me> |
| In reply to | #402647 |
On 03/10/2026 09: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.
I used to use a syntax wrapper for C that was converted to proper C via
a script. For Switch, I would write:
switch (x)
when a, b then
when c then
elsesw
endsw
and it would convert it to:
switch (x) {
break; case a: case b:
break; case c:
break; default:;
}
It was done like this in order to have 1:1 line correspondence with the
original (for compiler errors).
However there's no reason this wouldn't work in manually written code.
Alternately, create a macro like 'endcase' that expands to 'break', for
a more structured appearance.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-05 22:15 +0000 |
| Message-ID | <20261005145131.487@kylheku.com> |
| In reply to | #402649 |
On 2026-10-03, bart <bc@freeuk.com> wrote:
> On 03/10/2026 09: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.
>
>
> I used to use a syntax wrapper for C that was converted to proper C via
> a script. For Switch, I would write:
>
> switch (x)
> when a, b then
> when c then
> elsesw
> endsw
I did something like this for the Awk language, using the C preprocessor
in the "cppawk" project (C pre-processed Awk).
GNU Awk has a nonstandard switch statement as an extension, not in the
POSIX standard and not found in all other Awks.
I made a case statement using the preprocessor which transpiles to
a GNU Awk switch, or portable code.
https://www.kylheku.com/cgit/cppawk/tree/cppawk-case.1
Cases must end with a "cbreak" (deliberate curses pun), "cret"
or "cfall", otherwise syntactically invalid output is generated that triggers a
diagnostic.
I will forward the main example from the above man page here:
#include <case.h>
case (expr) {
of ("abc")
print "single key abc case"
cbreak
of (1, 2, 3)
print "multi-key 1, 2, 3 case"
cfall # fall through
matching (/regex1/, /regex2/, /regex3/)
print "regex case"
cbreak
mixed (("def", "ghi"), (/regex4/, /regex5/))
otherwise
print "default case"
}
We have "case" to introduce the statement, then "of" and "matching"
for two kinds of clauses, both variadic, taking multiple values
combined as a logical disjunction/"or".
The "mixed" clause has two sub-argument lists: an "of" style
argument list and "matching" kind of argument list,
to handle values and regexes in one case.
> switch (x) {
> break; case a: case b:
> break; case c:
> break; default:;
> }
$ cppawk --prepro-only -f -
#include <case.h>
case (expr) {
of ("abc")
print "single key abc case"
cbreak
of (1, 2, 3)
print "multi-key 1, 2, 3 case"
cfall # fall through
matching (/regex1/, /regex2/, /regex3/)
print "regex case"
cbreak
mixed (("def", "ghi"), (/regex4/, /regex5/))
otherwise
print "default case"
}
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "<stdin>"
# 1 "-"
# 1 "/home/kaz/bin/cppawk-include/case.h" 1
# 32 "/home/kaz/bin/cppawk-include/case.h"
# 1 "/home/kaz/bin/cppawk-include/case-priv.h" 1
# 32 "/home/kaz/bin/cppawk-include/case-priv.h"
# 1 "/home/kaz/bin/cppawk-include/narg-priv.h" 1
# 32 "/home/kaz/bin/cppawk-include/narg-priv.h"
# 1 "/home/kaz/bin/cppawk-include/base.h" 1
# 33 "/home/kaz/bin/cppawk-include/narg-priv.h" 2
# 33 "/home/kaz/bin/cppawk-include/case-priv.h" 2
# 33 "/home/kaz/bin/cppawk-include/case.h" 2
# 2 "-" 2
switch (expr) {
case "abc": {{{
print "single key abc case"
break; }}}
case 1: case 2: case 3: {{{
print "multi-key 1, 2, 3 case"
}}} # fall through
case/regex1/: case /regex2/: case /regex3/: {{{
print "regex case"
break; }}}
case "def": case "ghi": case/regex4/: case /regex5/: {{{
default: {{{
print "default case"
}
The portable code looks like this:
for ((__once = 1) && (__pass = 0) || (__val = expr); __once; __once = 0) {
if (__pass || ((__val == ("abc"))) && (__pass = 1)) {{{
print "single key abc case"
break; }}}
if (__pass || ((__val == (1)) || (__val == (2)) || (__val == (3))) && (__pass = 1)) {{{
print "multi-key 1, 2, 3 case"
}}} # fall through
if (__pass || ((__val ~ (/regex1/)) || (__val ~ (/regex2/)) || (__val ~ (/regex3/))) && (__pass = 1)) {{{
print "regex case"
break; }}}
if (__pass || ((__val == ("def")) || (__val == ("ghi")) || (__val ~ (/regex4/)) || (__val ~ (/regex5/))) && (__pass = 1)) {{{
if (__pass = 1) {{{
print "default case"
}
Just a crappy sequence of ifs wrapped in a one-teration loop.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-03 14:22 +0200 |
| Message-ID | <119qs32$1n4p6$1@dont-email.me> |
| In reply to | #402647 |
On 2026-10-03 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.
Layout preference (and specific types of programming errors) are
certainly a very personal thing, so it's probably unsatisfying to
discuss that. - Skip post, if you agree. ;-)
But there's more about it; so a few comments...
What I find confusing is the additional own indent of parenthesis
and braces. I'd also prefer to not mix style of command sequences
in a 'case'; once you have the command as it is, in another place
you have the command sequence surrounded with braces (despite no
block), in a third case we see one statement alone and the other
statements as block; mixed styles and optical incoherence doesn't
support a good perception to create error free code and spot the
omissions, 'break' or else. YMMV.
Obviously what you are aiming at is having something like a block
of "begin" and "end" (which are typically aligned) when you write
case
...
break;
For my eyes that's not a sensible choice, since I want the labels
clearly indicating the entries in the 'switch', and in your style
the 'break' optically conflates with the next (unrelated) 'case'.
In case of very long 'switch' constructs I prefer to make the exit
places, the 'break' (as with the 'return' or 'exit' statements) to
be followed by an empty line
case 1:
...
break;
case 2:
...
break;
For terse 'case' constructs - that I'd apply in an embedded 'switch'
as seen in your example with ..._{ADD,SUB,...} - I'd probably write
each on a line instead. (Although in your case I'd try to choose a
program structure to not repeat the outer 'switch' case-labels in
the inner 'switch', in the first place, if possible. Just aside.)
In many cases it helps to define functions (or macros) for primitives
(like the stack operations, the "push" and "pop", in the code below).
Using functions makes the whole 'switch' statement better legible,
and as a side effect less error-prone for profane things like missing
breaks (if that is your major concern here). That would also resemble
its nature as a FSM better, makes it clearer, and the function names
could reflect the FSM actions in the technical specification of your
software (presuming folks here write such documents; I'm not sure).
Besides these points that were all related to your subject to prevent
accidental omissions of 'break' there's yet more options to make the
code better legible (thus also serving spotting or avoiding mistakes).
One is all these /*end-of-construct*/ _technical_ comments; especially
the two /*switch*/ comments for the embedded 'switch' seems arguable.
Or the /*if*/ comment in a one-line construct, where it just adds load
without really helping. YMMV.
Concerning clarity I'd certainly prefer any variant with less ballast
like
if (not first)
op = va_arg (args, stackcalc_op);
first = false;
As conclusion to what I initially said, and given that most folks here
have developed their own style [in their personal domain] for decades I
think that neither suggestion (not yours, nor mine) will affect anyone.
Given that such code as below may emerge in development one can change
some things beyond the 'break' indents by refactoring, though, to make
some inherent issues with it non-issues in practice.
There's yet more things that could be argued about; e.g. I think the
"forever"-loop with the "done"-'break' handling could be made nicer;
the final "if (done) break" reminds me legacy code from the 1960's. :-)
BTW; I'd have expected that modern compilers could warn about omitted
'break'. - A quick check on the Net supports that expectation. So any
issue with missing 'break' is void, and any workarounds with arguable
layout choices seem unnecessary.
Janis
> A reasonably-complex example, with a nested
> switch for added interest:
>
> real stack_calc
> (
> stackcalc_op op,
> ...
> )
> /* starting with an empty operand stack, carries out the specified
> operations on the specified operands, at the end of which there
> should be just a single value on the operand stack. This value is
> popped and returned as the function result. */
> {
> real * opstack = NULL;
> size_t
> opstacklen = 0,
> opstackalloc = 0;
> real result;
> va_list args;
> va_start(args, op);
> bool first = true;
> bool done = false;
> for (;;)
> {
> if (not first)
> {
> op = va_arg(args, stackcalc_op);
> } /*if*/
> first = false;
> switch (op)
> {
> case STACKCALC_END:
> done = true;
> break;
> case STACKCALC_PUSH:
> {
> if (opstacklen == opstackalloc)
> {
> opstackalloc += 16;
> opstack = realloc(opstack, opstackalloc * sizeof(real));
> bugcheck(opstack != NULL, "unable to expand operand stack beyond %d", opstacklen);
> } /*if*/
> opstack[opstacklen] = va_arg(args, real);
> ++opstacklen;
> }
> break;
> case STACKCALC_ADD:
> case STACKCALC_SUB:
> case STACKCALC_MUL:
> case STACKCALC_DIV:
> bugcheck(opstacklen >= 2, "not enough operands for operator %d", op);
> {
> const real op2 = opstack[opstacklen - 1];
> real op1 = opstack[opstacklen - 2];
> switch (op)
> {
> case STACKCALC_ADD:
> op1 += op2;
> break;
> case STACKCALC_SUB:
> op1 -= op2;
> break;
> case STACKCALC_MUL:
> op1 *= op2;
> break;
> case STACKCALC_DIV:
> op1 /= op2;
> break;
> } /*switch*/
> --opstacklen;
> opstack[opstacklen - 1] = op1;
> }
> break;
> default:
> bugcheck(false, "invalid operator %d", op);
> break;
> } /*switch*/
> if (done)
> break;
> } /*for*/
> va_end(args);
> bugcheck(opstacklen == 1, "expecting exactly one result left on stack");
> result = opstack[0];
> free(opstack);
> return result;
> } /*stack_calc*/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-03 18:02 +0200 |
| Message-ID | <119r8u3$34nce$1@dont-email.me> |
| In reply to | #402647 |
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 Now forgetting a "break" is a compile-time error. If you want a fall-through, use [[fallthrough]] or a "// fallthrough" comment. This is easier, more flexible and clearer than a special layout. And it doesn't involve trying to scan column alignments in a long function. Let the tools handle the little stuff, so that you can spend time on more important things.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-04 00:24 +0800 |
| Message-ID | <1%9wS.256$Ob1f.21@fx05.ams4> |
| In reply to | #402652 |
On 10/4/2026 12:02 AM, 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 > > Now forgetting a "break" is a compile-time error. If you want a fall- > through, use [[fallthrough]] or a "// fallthrough" comment. This is > easier, more flexible and clearer than a special layout. And it doesn't > involve trying to scan column alignments in a long function. > > Let the tools handle the little stuff, so that you can spend time on > more important things. Of course, that won't help if you write a book on coding in C, but you can always teach this in the first chapter. Plus, thank you; but I rarely use G.C.C. these days. Does M.S.V.C. have an equivalent error? Best wishes, and happy authoring books on coding in C! -- 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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-03 17:36 +0100 |
| Message-ID | <119rau4$35ugq$1@dont-email.me> |
| In reply to | #402652 |
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
Here I don't believe writing 26 lots of [[fallthrough]] when there are
26 cases to deal with is the way to go.
But then in this example:
case 'D':
<stuff>
case 'E':
If <stuff> is currently empty because there's no code it, or it's been
commented out, or it's a macro that expands to nothing, then this would
also be a false positive.
>
> Now forgetting a "break" is a compile-time error. If you want a fall-
> through, use [[fallthrough]] or a "// fallthrough" comment. This is
> easier, more flexible and clearer than a special layout. And it doesn't
> involve trying to scan column alignments in a long function.
>
> 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.
Now everyone is forced to use some big, slow compiler to catch these issues.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-03 16:31 -0700 |
| Message-ID | <119s386$3e68n$1@kst.eternal-september.org> |
| In reply to | #402655 |
bart <bc@freeuk.com> writes:
> On 03/10/2026 17:02, David Brown wrote:
[...]
>> gcc -Werror=implict-fallthrough
Typo alert.
> I assume this is for non-empty blocks? Otherwise this will be an error:
>
> case 'A': case 'B': case 'C':
> // deal with ABC
Yes (as you could have found out before posting by trying it).
> Here I don't believe writing 26 lots of [[fallthrough]] when there are
> 26 cases to deal with is the way to go.
Yes, they thought of that.
> But then in this example:
>
> case 'D':
> <stuff>
> case 'E':
>
> If <stuff> is currently empty because there's no code it, or it's been
> commented out, or it's a macro that expands to nothing, then this
> would also be a false positive.
Doctor, it hurts when I do this.
I'd add the "break" as soon as I add the "case". I find it useful to
think of the "break" as part of the syntax of the switch statement
(though of course I know it isn't).
[...]
> Another hack! At least, a workaround for poor design in the
> language. If only the creators had made a little more effort.
>
> Now everyone is forced to use some big, slow compiler to catch these issues.
Yes, yet another opportunity for you to waste everyone's time whining
about something that everybody here is already aware of and nobody
here can possibly do anything about.
--
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-04 10:23 +0200 |
| Message-ID | <119t2dn$3gshg$1@dont-email.me> |
| In reply to | #402665 |
On 2026-10-04 01:31, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> [...]
>
> Doctor, it hurts when I do this.
>
> I'd add the "break" as soon as I add the "case". I find it useful to
> think of the "break" as part of the syntax of the switch statement
> (though of course I know it isn't).
While I don't think of it as part of the syntax I also do that
for practical considerations; when creating a program and some
(or all) 'case' tags are clear and identified I also immediately
add breaks even if its "body" is yet empty, if only to just have
a compilable code at every stage of the incremental programming
and stepwise refinement. (Sometimes, in postponed implementation
of some code, I even add a printf("yet unimplemented\n"); at
such places, which is probably considered a burden to some.)
> [...]
>
>> Another hack! At least, a workaround for poor design in the
>> language. If only the creators had made a little more effort.
The creators had some paragons and some ideas about the language
that they implemented, and "C" became a very successful language!
(Yours don't, BTW. - I suppose you can't get over that fact.)
That perpetual whining about an old language with well known
advantages and disadvantages helps no one; you obviously can't
get over it, but why are you constantly complaining instead of
just not using that language and omitting the discussions here;
have you some stance as crusader or is it a mental problem that
you cannot stop that pathological habit? (rhetorical)
>>
>> Now everyone is forced to use some big, slow compiler to catch these issues.
There's no practical issues with 'break' in 'switch' (beyond
being a somewhat clumsy syntax, IMO). Other languages might not
need it, if they don't support fall-through in the first place,
yet other languages may have some more terse but cryptic syntax
(cf. for example to Kornshell's ';;' and ';&' where the former
is the "break" and the latter is used for the fall-through
semantics). Different languages, different designs.
I'm using the compilers I've got with the systems I'm working on.
Typically these are standard tools, powerful, and well supported.
I've had rarely performance issues that couldn't be addressed by
standard actions. (If *you* have problems it's on you to address
them.) Your repeated attempts to convince people that they would
have a problem where they just don't have one is tedious and with
your constant repetitions rude.
>
> Yes, yet another opportunity for you to waste everyone's time whining
> about something that everybody here is already aware of and nobody
> here can possibly do anything about.
BTW; it was not uncommon back these days that languages supported
(if at all) just a counted/indexed 'switch' command, where you
could not branch on arbitrary integral values but only on an "1..N"
and "otherwise" sequence. So C's 'switch' could be considered a
progress. Later we've got even more powerful 'switch' cases, as in
GNU's variant of Awk where you can compare strings and also regexps.
Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-04 12:18 +0100 |
| Message-ID | <119tclm$3rfid$1@dont-email.me> |
| In reply to | #402665 |
On 04/10/2026 00:31, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 03/10/2026 17:02, David Brown wrote: > [...] >>> gcc -Werror=implict-fallthrough > > Typo alert. > >> I assume this is for non-empty blocks? Otherwise this will be an error: >> >> case 'A': case 'B': case 'C': >> // deal with ABC > > Yes (as you could have found out before posting by trying it). > >> Here I don't believe writing 26 lots of [[fallthrough]] when there are >> 26 cases to deal with is the way to go. > > Yes, they thought of that. > >> But then in this example: >> >> case 'D': >> <stuff> >> case 'E': >> >> If <stuff> is currently empty because there's no code it, or it's been >> commented out, or it's a macro that expands to nothing, then this >> would also be a false positive. > > Doctor, it hurts when I do this. That doesn't make sense: 'this' presumably is not providing the 'break' before the next case/default. But if you don't do that (always remember to add break), then what is the point of the above option? Presumably it is precisely because sometimes you do forget! Or it ends up not having break for any of a million reasons. > I'd add the "break" as soon as I add the "case". I find it useful to > think of the "break" as part of the syntax of the switch statement > (though of course I know it isn't). So tell the gcc people their implicit-fallthrough option is a waste of time because nobody ever forgets to add that 'break' and it never gets inadvertently left out or bypassed because of code evolving around it. My own suggestion - WHICH WORKS WITH EVERY C COMPILER AND WITHOUT NEEDING TO GIVE IT EXTRA OPTIONS - was to write 'break; case' or 'break; default' unless you want fall-through. Not pretty, but this is C; people are used to that. And suitable macros (Case, Default) can mitigate it. > [...] > >> Another hack! At least, a workaround for poor design in the >> language. If only the creators had made a little more effort. >> >> Now everyone is forced to use some big, slow compiler to catch these issues. > > Yes, yet another opportunity for you to waste everyone's time whining > about something that everybody here is already aware of and nobody > here can possibly do anything about. Yet it would be nice if people admitted it was a fuck-up rather than trying to spin it as a handy feature. And also to admit that these workarounds are all hacks.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-04 16:20 +0200 |
| Message-ID | <119tnc3$3vcal$2@dont-email.me> |
| In reply to | #402665 |
On 04/10/2026 01:31, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 03/10/2026 17:02, David Brown wrote: > [...] >>> gcc -Werror=implict-fallthrough > > Typo alert. It was clearly an intentional mistake to encourage people to look up the details in the gcc manual :-)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-05 21:34 +0000 |
| Message-ID | <20261005143326.330@kylheku.com> |
| In reply to | #402672 |
On 2026-10-04, David Brown <david.brown@hesbynett.no> wrote: > On 04/10/2026 01:31, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 03/10/2026 17:02, David Brown wrote: >> [...] >>>> gcc -Werror=implict-fallthrough >> >> Typo alert. > > It was clearly an intentional mistake to encourage people to look up the > details in the gcc manual :-) Or just use -Werror=unknewn-worning -- 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 16:04 -0700 |
| Message-ID | <11a3uqp$2cj40$2@dont-email.me> |
| In reply to | #402716 |
On 10/5/2026 2:34 PM, Kaz Kylheku wrote: > On 2026-10-04, David Brown <david.brown@hesbynett.no> wrote: >> On 04/10/2026 01:31, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 03/10/2026 17:02, David Brown wrote: >>> [...] >>>>> gcc -Werror=implict-fallthrough >>> >>> Typo alert. >> >> It was clearly an intentional mistake to encourage people to look up the >> details in the gcc manual :-) > > Or just use -Werror=unknewn-worning > ;^)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-04 16:18 +0200 |
| Message-ID | <119tn71$3vcal$1@dont-email.me> |
| In reply to | #402655 |
On 03/10/2026 18:36, bart 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 > Of course. It also does not trigger if block ends in a return, or a call to a noreturn function, or UB (such as unreachable() ). > Here I don't believe writing 26 lots of [[fallthrough]] when there are > 26 cases to deal with is the way to go. > > But then in this example: > > case 'D': > <stuff> > case 'E': > > If <stuff> is currently empty because there's no code it, or it's been > commented out, or it's a macro that expands to nothing, then this would > also be a false positive. Warnings help prevent accidentally incorrect code - they can't stop you writing creatively bad code. > >> >> Now forgetting a "break" is a compile-time error. If you want a fall- >> through, use [[fallthrough]] or a "// fallthrough" comment. This is >> easier, more flexible and clearer than a special layout. And it >> doesn't involve trying to scan column alignments in a long function. >> >> 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. > > Now everyone is forced to use some big, slow compiler to catch these > issues. Yes, in the same sense that those Romans were terrible designers when they invented nails and forced everyone to buy expensive and noise pneumatic nail guns. It takes a special kind of masochist to actively choose not to use useful free tools to make their life easier, once they know about their existence. If you can't use gcc for some reason, then get another tool that will do these checks for you (I expect most compilers will have similar warnings).
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-04 16:09 +0100 |
| Message-ID | <119tq76$nnb$1@dont-email.me> |
| In reply to | #402671 |
On 04/10/2026 15:18, David Brown wrote: > On 03/10/2026 18:36, bart wrote: >> Now everyone is forced to use some big, slow compiler to catch these >> issues. > > Yes, in the same sense that those Romans were terrible designers when > they invented nails and forced everyone to buy expensive and noise > pneumatic nail guns. The link between a nail and a properly structured switch statement remains elusive, sorry. > It takes a special kind of masochist to actively choose not to use > useful free tools to make their life easier, once they know about their > existence. A free tool that requires you to write: gcc prog.c -o prog -Wextra-implicit-fallthrough (putting aside the 100 other options needed to fix everything else) instead of just: cc prog # prog.c is acceptable And which is 1-2 magnitudes slower to build too. Neither should the onus be on me (and thus on each of a million developers) to add an extra, /custom/ layer of complexity to make it work in a more sensible manner. Even then, 'switch' remains one of the most bizarre features of any non-eso language, and compiler options can only do so much. Python acquired 'match' after some 25 years of doing without any form of switch. C has had 50 years to make up for its 'switch' by adding a saner alternative.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-04 16:59 +0000 |
| Message-ID | <IBvwS.115$iAH2.35@fx14.iad> |
| In reply to | #402673 |
bart <bc@freeuk.com> writes: >On 04/10/2026 15:18, David Brown wrote: >> On 03/10/2026 18:36, bart wrote: > >>> Now everyone is forced to use some big, slow compiler to catch these >>> issues. >> >> Yes, in the same sense that those Romans were terrible designers when >> they invented nails and forced everyone to buy expensive and noise >> pneumatic nail guns. > >The link between a nail and a properly structured switch statement >remains elusive, sorry. > >> It takes a special kind of masochist to actively choose not to use >> useful free tools to make their life easier, once they know about their >> existence. > >A free tool that requires you to write: > > gcc prog.c -o prog -Wextra-implicit-fallthrough > >(putting aside the 100 other options needed to fix everything else) >instead of just: > > cc prog # prog.c is acceptable As has been pointed out to you many, many, many times most programmers simply type $ make
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-04 18:30 +0100 |
| Message-ID | <119u2gd$49fl$1@dont-email.me> |
| In reply to | #402675 |
On 04/10/2026 17:59, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 04/10/2026 15:18, David Brown wrote: >>> On 03/10/2026 18:36, bart wrote: >> >>>> Now everyone is forced to use some big, slow compiler to catch these >>>> issues. >>> >>> Yes, in the same sense that those Romans were terrible designers when >>> they invented nails and forced everyone to buy expensive and noise >>> pneumatic nail guns. >> >> The link between a nail and a properly structured switch statement >> remains elusive, sorry. >> >>> It takes a special kind of masochist to actively choose not to use >>> useful free tools to make their life easier, once they know about their >>> existence. >> >> A free tool that requires you to write: >> >> gcc prog.c -o prog -Wextra-implicit-fallthrough >> >> (putting aside the 100 other options needed to fix everything else) >> instead of just: >> >> cc prog # prog.c is acceptable > > As has been pointed out to you many, many, many times > most programmers simply type > > $ make > Which contains ... ?
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-10-04 19:49 +0100 |
| Message-ID | <119u74g$68hm$1@dont-email.me> |
| In reply to | #402676 |
On 04/10/2026 18:30, bart wrote: > On 04/10/2026 17:59, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 04/10/2026 15:18, David Brown wrote: >>>> On 03/10/2026 18:36, bart wrote: >>> >>>>> Now everyone is forced to use some big, slow compiler to catch these >>>>> issues. >>>> >>>> Yes, in the same sense that those Romans were terrible designers when >>>> they invented nails and forced everyone to buy expensive and noise >>>> pneumatic nail guns. >>> >>> The link between a nail and a properly structured switch statement >>> remains elusive, sorry. >>> >>>> It takes a special kind of masochist to actively choose not to use >>>> useful free tools to make their life easier, once they know about their >>>> existence. >>> >>> A free tool that requires you to write: >>> >>> gcc prog.c -o prog -Wextra-implicit-fallthrough >>> >>> (putting aside the 100 other options needed to fix everything else) >>> instead of just: >>> >>> cc prog # prog.c is acceptable >> >> As has been pointed out to you many, many, many times >> most programmers simply type >> >> $ make >> > > Which contains ... ? > The 'Makefile' would contain: CFLAGS = -Wextra-implicit-fallthrough (and all the other things that you don't like). I'd note that 'make' is less typing than 'cc prog'.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-04 20:35 +0100 |
| Message-ID | <119u9pe$7b2r$1@dont-email.me> |
| In reply to | #402680 |
On 04/10/2026 19:49, Richard Harnden wrote: > On 04/10/2026 18:30, bart wrote: >> On 04/10/2026 17:59, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >>>> On 04/10/2026 15:18, David Brown wrote: >>>>> On 03/10/2026 18:36, bart wrote: >>>> >>>>>> Now everyone is forced to use some big, slow compiler to catch these >>>>>> issues. >>>>> >>>>> Yes, in the same sense that those Romans were terrible designers when >>>>> they invented nails and forced everyone to buy expensive and noise >>>>> pneumatic nail guns. >>>> >>>> The link between a nail and a properly structured switch statement >>>> remains elusive, sorry. >>>> >>>>> It takes a special kind of masochist to actively choose not to use >>>>> useful free tools to make their life easier, once they know about >>>>> their >>>>> existence. >>>> >>>> A free tool that requires you to write: >>>> >>>> gcc prog.c -o prog -Wextra-implicit-fallthrough >>>> >>>> (putting aside the 100 other options needed to fix everything else) >>>> instead of just: >>>> >>>> cc prog # prog.c is acceptable >>> >>> As has been pointed out to you many, many, many times >>> most programmers simply type >>> >>> $ make >>> >> >> Which contains ... ? >> > > The 'Makefile' would contain: CFLAGS = -Wextra-implicit-fallthrough (and > all the other things that you don't like). > I'd note that 'make' is less typing than 'cc prog'. * This is not the compiler * If I use 'make' to each arbitrary .c program, it will not apply that option ... * ... nor any of the 100 others needed to partially fix the language * It will not run the compiler I want, which anyway doesn't have those options * As I said, this requires each developer to fix the shortcomings of both language and compiler in their own way With a large project, a makefile gets complicated. Hiding that complexity in a makefile that gets invoked in one command is not simplifying - it is brushing it under the carpet. The tools I write work like this: xx file xx is the compiler, xx is the lead module. This works for C too for one-file programs. They are genuinely simple.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-04 22:27 +0200 |
| Message-ID | <119ucrc$8cgl$1@dont-email.me> |
| In reply to | #402681 |
On 04/10/2026 21:35, bart wrote: > On 04/10/2026 19:49, Richard Harnden wrote: >> On 04/10/2026 18:30, bart wrote: >>> On 04/10/2026 17:59, Scott Lurndal wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 04/10/2026 15:18, David Brown wrote: >>>>>> On 03/10/2026 18:36, bart wrote: >>>>> >>>>>>> Now everyone is forced to use some big, slow compiler to catch these >>>>>>> issues. >>>>>> >>>>>> Yes, in the same sense that those Romans were terrible designers when >>>>>> they invented nails and forced everyone to buy expensive and noise >>>>>> pneumatic nail guns. >>>>> >>>>> The link between a nail and a properly structured switch statement >>>>> remains elusive, sorry. >>>>> >>>>>> It takes a special kind of masochist to actively choose not to use >>>>>> useful free tools to make their life easier, once they know about >>>>>> their >>>>>> existence. >>>>> >>>>> A free tool that requires you to write: >>>>> >>>>> gcc prog.c -o prog -Wextra-implicit-fallthrough >>>>> >>>>> (putting aside the 100 other options needed to fix everything else) >>>>> instead of just: >>>>> >>>>> cc prog # prog.c is acceptable >>>> >>>> As has been pointed out to you many, many, many times >>>> most programmers simply type >>>> >>>> $ make >>>> >>> >>> Which contains ... ? >>> >> >> The 'Makefile' would contain: CFLAGS = -Wextra-implicit-fallthrough >> (and all the other things that you don't like). > >> I'd note that 'make' is less typing than 'cc prog'. > > * This is not the compiler > > * If I use 'make' to each arbitrary .c program, it will not apply that > option ... > > * ... nor any of the 100 others needed to partially fix the language > > * It will not run the compiler I want, which anyway doesn't have those > options > > * As I said, this requires each developer to fix the shortcomings of > both language and compiler in their own way > > With a large project, a makefile gets complicated. Hiding that > complexity in a makefile that gets invoked in one command is not > simplifying - it is brushing it under the carpet. No, it is handling the complexity in a reliable and appropriate manner. Working with large complex programs is complicated /unless/ you use a tool like make. > > The tools I write work like this: > > xx file > > xx is the compiler, xx is the lead module. This works for C too for one- > file programs. > > They are genuinely simple. Writing a script or batch file is genuinely simple too. You have simply invested too much of your reputation in your hatred of decent tools - you either have to keep on mindlessly moaning about them, or admit you've been wrong for the past several decades. You are like that certain type of American who claims Imperial units of measurements are better than metric because they got Americans to the moon. Just think how much more they could achieved with metric units instead. You were a successful professional programmer. You would have done even better if you picked the best tools for the job, rather than doubling down on your prejudice at every chance.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web