Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-13 23:19 +0100 |
| Articles | 20 on this page of 319 — 21 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-06 04:11 -0700 |
| Message-ID | <11a2l1i$1rim5$1@kst.eternal-september.org> |
| In reply to | #402730 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.
It's unlikely that I'd write something like that. If I did,
I'd use braces:
if (condition) {
LABEL: statement;
}
I'm sometimes willing to omit optional braces, but almost exclusively
in cases where the entire construct is on one line:
if (condition) statement;
Aside from that, writing an if statement and providing a way to bypass
the test feels odd (to me). Presumably there's a `goto LABEL;`
elsewere in the same function. I'd look for a clearer way to structure
the code.
--
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 21:40 +0200 |
| Message-ID | <11a3iqj$ef4o$4@dont-email.me> |
| In reply to | #402743 |
On 2026-10-06 13:11, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> 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.
>
> It's unlikely that I'd write something like that. If I did,
> I'd use braces:
>
> if (condition) {
> LABEL: statement;
> }
That's actually something I'd be suspicious about; i.e. jumping into a
brace-enclosed region. This uncertainty stems from my ignorance on the
C-standard concerning that case, for sure. In other languages it's not
generally allowed to jump into such blocks. Without the braces, OTOH,
the scope rules are more obvious. That's why I think it makes sense to
allow such a labelled single statement and not require to set spurious
braces as a special case (that normally isn't required).
The application cases I said I could imagine are like, say,
if (c1) { ... ; if (c12) goto LABEL; }
...
if (c2) { ... ; goto LABEL; }
...
if (c3)
LABEL: finalize();
>
> I'm sometimes willing to omit optional braces, but almost exclusively
> in cases where the entire construct is on one line:
>
> if (condition) statement;
I do the same but mostly only in cascaded 'if's. It depends on context.
>
> Aside from that, writing an if statement and providing a way to bypass
> the test feels odd (to me). Presumably there's a `goto LABEL;`
> elsewere in the same function. I'd look for a clearer way to structure
> the code.
Yeah, same here; as said, I'm regularly not using a goto/label but the
above quoted code pattern seems not unreasonable to me.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-16 13:12 -0700 |
| Message-ID | <86qzhppfp0.fsf@linuxsc.com> |
| In reply to | #402743 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> 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.
>
> It's unlikely that I'd write something like that. If I did,
> I'd use braces:
>
> if (condition) {
> LABEL: statement;
> }
>
> I'm sometimes willing to omit optional braces, but almost exclusively
> in cases where the entire construct is on one line:
>
> if (condition) statement;
Some years ago I had occasion to write some code that in outline
looked something like this (pseudo code in <>'s):
<typename>
some_action( <arguments> ){
<some setup>
goto START_LOOP;
for( ; <test>; <update> ){
if( <early-exit-test> ) return <something>;
if( <circumstance> ) START_LOOP: {
<re-initialization actions>
}
}
<rest of function>
}
I deliberately put the label START_LOOP before the braces because I
wanted to make it obvious that the target was the whole branch of
the if(). Putting the label inside the braces could give the
mistaken impression that it was just a coincidence that what happens
when the loop starts is the entire body of the if(). Putting the
label before the braces makes it obvious that what the if() is doing
and where the loop is being entered are exactly the same point.
> Aside from that, writing an if statement and providing a way to bypass
> the test feels odd (to me). Presumably there's a `goto LABEL;`
> elsewere in the same function. I'd look for a clearer way to structure
> the code.
Indeed, and not only did I look, but I already had looked, and ended
up at the above version only after trying multiple alternatives. I
judged this variation to be the easiest to understand, because all
the alternatives either were more convoluted or had to duplicate
some code, not only the code in the if() body but also the <update>
clause in the for() statement.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-10-06 00:59 -0700 |
| Message-ID | <11a29pe$1o0eo$1@dont-email.me> |
| In reply to | #402726 |
On Mon 10/5/2026 6:05 PM, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> In C23, a
> labeled-statement can only occur in an odd construct like this:
>
> if (condition)
> LABEL: statement;
>
...and as another example of the same thing, while this
switch (0)
{
case 0: int a = printf("Hello World\n");
}
is now valid in C23, this
switch (0)
case 0: int a = printf("Hello World\n");
remains invalid.
--
Best regards,
Andrey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-06 08:16 +0000 |
| Message-ID | <11a2ape$1o5je$1@dont-email.me> |
| In reply to | #402735 |
On Tue, 6 Oct 2026 00:59:40 -0700, Andrey Tarasevich wrote:
> ... this
>
> switch (0)
> case 0: int a = printf("Hello World\n");
>
> remains invalid.
I showed how to do that in my example.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-06 04:21 -0700 |
| Message-ID | <11a2lka$1rim5$2@kst.eternal-september.org> |
| In reply to | #402738 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Tue, 6 Oct 2026 00:59:40 -0700, Andrey Tarasevich wrote:
>> ... this
>>
>> switch (0)
>> case 0: int a = printf("Hello World\n");
>>
>> remains invalid.
>
> I showed how to do that in my example.
If by "that" you mean having a case label followed by a declaration, I
don't believe you did. You've posted twice in this thread, including
your post that started it. In your original post, all the case
labels were on ordinary (possibly compound) statements.
In any case, (a) the solution is obvious (add braces), and (b) I
don't believe anyone was looking for a way to do that in the first
place, just commenting on what is and isn't valid.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-16 04:46 -0700 |
| Message-ID | <86v771q35w.fsf@linuxsc.com> |
| In reply to | #402726 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [.. some syntanx changes were made as part of 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.
Glad to hear it. Good choice.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-06 14:43 +0000 |
| Message-ID | <0O7xS.911$aNSb.604@fx20.iad> |
| 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. Indeed. And in this particular case, gcc/clang have an useful extension. case 'A' ... 'C': Has there been any attempts to add that to the C standard?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 17:36 +0200 |
| Message-ID | <11a34if$218om$3@dont-email.me> |
| In reply to | #402753 |
On 06/10/2026 16:43, Scott Lurndal wrote: > Indeed. And in this particular case, gcc/clang have an useful extension. > > case 'A' ... 'C': > > Has there been any attempts to add that to the C standard? I believe they are included in the next C standard (currently labelled C2y). <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3370.htm>
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-10-06 20:36 -0700 |
| Message-ID | <11a4enp$2h5ld$1@dont-email.me> |
| In reply to | #402655 |
On Sat 10/3/2026 9:36 AM, 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
This is not, but in other cases there are still some differences between
implementations.
For example, Clang approaches this matter rather formally. This:
switch (0)
{
case 0:;
case 1:;
case 2:;
}
is already sufficient to trigger fallthrough warnings in Clang under
`-Wimplicit-fallthrough`, even tough all "blocks" in the above are empty
for all practical means and purposes.
GCC will remain silent for the above code. This will keep it silent as well:
switch (0)
{
case 0:;
case 1:;
case 2: printf("World");
}
This produces no warnings either:
switch (0)
{
case 0: printf("Hello ");
case 1:;
case 2:;
}
And finally this:
switch (0)
{
case 0: printf("Hello ");
case 1:;
case 2: printf("World");
}
will trigger a warning under `-Wimplicit-fallthrough`. So, GCC appears
to look for a fallthrough from a non-empty to a non-empty before it warns.
--
Best regards,
Andrey
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-04 00:20 +0800 |
| Message-ID | <cX9wS.255$Ob1f.151@fx05.ams4> |
| In reply to | #402647 |
On 10/3/2026 4:43 PM, 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:
Dear Lawrence,
I don't know about you, but I tend to use my eyes. I grew up with
coding on basic tools, and have never felt a /need/ for a fancy text
editor, so I have not created some code verifier nor Emacs skeleton
for this yet.
So what I do is to code the switch statement something like
switch ( foo ) {
case BAR: {
/* ... */
} break ;
case BAZ: {
/* ... */
} break ;
}
and put the /break/ keyword outside the curly braces for easy visual in-
spection, no matter if the text editor has syntax highlight turned on or
not. The above is somewhat reminiscent of reality, as Emacs CC-mode is
rather idiotic at indenting this kind of code, and I have not bothered
to tame it myself.
What do you think? Doesn't this make it rather easy to see whether each
{ } ends with a break?
--
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 | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-10-04 09:05 -0700 |
| Message-ID | <119ttfk$241j$1@dont-email.me> |
| In reply to | #402647 |
On Sat 10/3/2026 1:43 AM, 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.
I usually employ a much better method, which should really be included
into every coding standard: just interlace your switch statement with a
dummy if-else ladder. This will effectively provide an implicit
automatic "break" at the end of each 'case' section
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
for (unsigned n = 100; n > 0; --n)
{
switch (rand() % 4)
{
if (0) {
case 0:
printf("Case zero");
} else if (0) {
case 1:
printf("Case one");
} else if (0) {
case 2:
printf("Case two");
} else if (0) {
case 3:
printf("Case three");
}
printf("\n");
}
}
}
It might look a bit cluttered and convoluted at first, but with everyday
intensive use it quickly becomes a second nature. Makes a great
conversation topic around the watering hole, BTW. Your colleagues will
appreciate the inherent safety of the approach.
--
Best regards,
Andrey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-04 23:44 +0000 |
| Message-ID | <119uocv$cact$2@dont-email.me> |
| In reply to | #402674 |
On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote: > I usually employ a much better method, which should really be > included into every coding standard: just interlace your switch > statement with a dummy if-else ladder. The more code you have to write, the more opportunities there are to get things wrong. And maintenance takes more work, too. > It might look a bit cluttered and convoluted at first, but with > everyday intensive use it quickly becomes a second nature. *Writing* it may become “second nature”, but *reading* it never will.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-05 01:46 +0100 |
| Message-ID | <119us0e$dhqo$1@dont-email.me> |
| In reply to | #402686 |
On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
>
>> I usually employ a much better method, which should really be
>> included into every coding standard: just interlace your switch
>> statement with a dummy if-else ladder.
>
> The more code you have to write, the more opportunities there are to
> get things wrong. And maintenance takes more work, too.
>
I don't know if AT was being serious. This was the proposal:
for (unsigned n = 100; n > 0; --n)
{
switch (rand() % 4)
{
if (0) {
case 0:
printf("Case zero");
} else if (0) {
case 1:
printf("Case one");
} else if (0) {
case 2:
printf("Case two");
} else if (0) {
case 3:
printf("Case three");
}
printf("\n");
}
}
}
It looks more of a mess than just writing the breaks. And there is
something funny about it: that final 'printf' is inside the switch's
compound statement, and here it is executed after any of the 4 cases.
Without the if-ladder, it would have to go outside the compound
statement. So it changes the behaviour subtly.
Here is the same functionality as above, using my everyday language:
to 100 do
switch rand() rem 4
when 0 then print "Case zero"
when 1 then print "Case one"
when 2 then print "Case two"
when 3 then print "Case three"
end
println
end
There is little clutter and little ambiguity. This is why syntax is
important including doing 'switch' properly.
For a fairer comparison, here is more idiomatic C:
for (unsigned n = 100; n > 0; --n)
{
switch (rand() % 4) {
case 0:
printf("Case zero");
break;
case 1:
printf("Case one");
break;
case 2:
printf("Case two");
break;
case 3:
printf("Case three");
break;
}
printf("\n");
}
Needing those breaks makes it harder to inline the cases and printfs.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <noone@noone.net> |
|---|---|
| Date | 2026-10-04 20:48 -0700 |
| Message-ID | <119v6m3$gtpu$1@dont-email.me> |
| In reply to | #402690 |
On Sun 10/4/2026 5:46 PM, bart wrote: > On 05/10/2026 00:44, Lawrence D’Oliveiro wrote: >> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote: >> >>> I usually employ a much better method, which should really be >>> included into every coding standard: just interlace your switch >>> statement with a dummy if-else ladder. >> >> The more code you have to write, the more opportunities there are to >> get things wrong. And maintenance takes more work, too. >> > > I don't know if AT was being serious. I wasn't, of course. > It looks more of a mess than just writing the breaks. And there is > something funny about it: that final 'printf' is inside the switch's > compound statement, and here it is executed after any of the 4 cases. Hm... It wasn't intentional. But it's pretty cool nevertheless. I intended the final `printf` to be a part of `for`s compound statement, but not a part of `switch`s. But by making this little mistake I purely accidentally "created" another interesting control structure: something like a final clause for every `case` branch, which is executed after each one of them. See, the beauty of this approach? Even an accidental glitch leads to something profoundly ingenious. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-05 06:24 +0200 |
| Message-ID | <119v8pp$ef4o$1@dont-email.me> |
| In reply to | #402696 |
On 2026-10-05 05:48, Andrey Tarasevich wrote: > [...] > > I intended the final `printf` to be a part of `for`s compound statement, > but not a part of `switch`s. But by making this little mistake I purely > accidentally "created" another interesting control structure: something > like a final clause for every `case` branch, which is executed after > each one of them. Actually a consequence of the low-level nature of how the switch with its labels is defined. Such things have been seen since Duff's Device. (Or maybe even earlier?) > > See, the beauty of this approach? Even an accidental glitch leads to > something profoundly ingenious. Sort of. :-) It's at least fancy what "C" all allows to convolute code. But the code does that fancy stuff only because there's no 'break' or [here equivalently] the 'if's final [missing] 'else'. A bit much effort for something that can in a clearer form be implemented without all the "if (0)". ;-) It was obvious that your code wasn't meant to be serious. It's less obvious (to me) whether you really find that "profoundly ingenious". Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-05 11:09 +0100 |
| Message-ID | <119vsvs$r1na$1@dont-email.me> |
| In reply to | #402690 |
On 05/10/2026 01:46, bart wrote:
> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
> Here is the same functionality as above, using my everyday language:
>
> to 100 do
> switch rand() rem 4
> when 0 then print "Case zero"
> when 1 then print "Case one"
> when 2 then print "Case two"
> when 3 then print "Case three"
> end
> println
> end
>
> There is little clutter and little ambiguity. This is why syntax is
> important including doing 'switch' properly.
Since this syntax is expression-based, it can also be rearranged like this:
to 100 do
println "Case", (rand() rem 4 | "one", "two", "three" | "zero")
end
But then, C can also manage a one-liner for the body:
int n = 100; while (n--)
printf("Case %s\n", (char*[4]){"zero", "one", "two",
"three"}[rand() % 4]);
Not bad, but it uses ~39 tokens (not counting the two inside the format
string), while mine has 22 tokens (with mine even token counting is
easier!).
There is a big difference though: C effectively evaluates all elements
of that list. It won't actually do that here, but in this form:
(char*[4]){f0(), f1(), f2(), f3()}[rand() % 4]
then all functions are called each time.
In my version, it's not a list, but N-way selection, a form of switch,
and only one element is evaluated. Since the whole returns a value, an
'else' branch is needed (the bit with "zero"). Note this is 1-based.
(If the index was to be out of bounds, say 'rand() % 8' was used, then C
would have UB. In my version, that is detected, and the 'else' branch
returned.)
>> The more code you have to write, the more opportunities there are to
>> get things wrong. And maintenance takes more work, too.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-06 05:22 +0800 |
| Message-ID | <UyUwS.5302$wun8.2503@fx13.ams4> |
| In reply to | #402690 |
On 10/5/2026 8:46 AM, bart wrote:
> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
>> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
>>
>>> I usually employ a much better method, which should really be
>>> included into every coding standard: just interlace your switch
>>> statement with a dummy if-else ladder.
>>
>> The more code you have to write, the more opportunities there are to
>> get things wrong. And maintenance takes more work, too.
>>
>
> I don't know if AT was being serious. This was the proposal:
>
> for (unsigned n = 100; n > 0; --n)
> {
> switch (rand() % 4)
> {
> if (0) {
> case 0:
> printf("Case zero");
> } else if (0) {
> case 1:
> printf("Case one");
> } else if (0) {
> case 2:
> printf("Case two");
> } else if (0) {
> case 3:
> printf("Case three");
> }
> printf("\n");
> }
> }
> }
>
>
> It looks more of a mess than just writing the breaks. And there is
> something funny about it: that final 'printf' is inside the switch's
> compound statement, and here it is executed after any of the 4 cases.
>
> Without the if-ladder, it would have to go outside the compound
> statement. So it changes the behaviour subtly.
>
> Here is the same functionality as above, using my everyday language:
>
> to 100 do
> switch rand() rem 4
> when 0 then print "Case zero"
> when 1 then print "Case one"
> when 2 then print "Case two"
> when 3 then print "Case three"
> end
> println
> end
>
> There is little clutter and little ambiguity. This is why syntax is
> important including doing 'switch' properly.
>
>
> For a fairer comparison, here is more idiomatic C:
>
> for (unsigned n = 100; n > 0; --n)
> {
> switch (rand() % 4) {
> case 0:
> printf("Case zero");
> break;
> case 1:
> printf("Case one");
> break;
> case 2:
> printf("Case two");
> break;
> case 3:
> printf("Case three");
> break;
> }
> printf("\n");
> }
>
> Needing those breaks makes it harder to inline the cases and printfs.
Oh, it's not hard at all. What you do to put everything in a single
line, is to wrap the whole thing an a function, then you can just return
the value of the printf(), and no error code is lost.
for ( signed n = 100 ; n > 0 ; n-- ) switch ( n ) {
/* Gets rid of the superfluous curlies before the switch. */
case 0: return printf( "case zero" ) ;
case 1: return printf( "case one" ) ;
case 2: return printf( "case two" ) ;
case 3: return printf( "case three" ) ;
}
And then you refactor the final printf() into the call to the new fun-
ction.
This is much shorter, and clearer. I hope you weren't talking about the
/inline/ keyword. It also has the side effect of not needing the
/break/ keyword at all.
Best wishes, and happy short switch () statements!
--
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 | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-10-06 05:26 +0800 |
| Message-ID | <7CUwS.5303$wun8.832@fx13.ams4> |
| In reply to | #402713 |
On 10/6/2026 5:22 AM, Johann 'Myrkraverk' Oskarsson wrote:
> On 10/5/2026 8:46 AM, bart wrote:
>> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
>>> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
>>>
>>>> I usually employ a much better method, which should really be
>>>> included into every coding standard: just interlace your switch
>>>> statement with a dummy if-else ladder.
>>>
>>> The more code you have to write, the more opportunities there are to
>>> get things wrong. And maintenance takes more work, too.
>>>
>>
>> I don't know if AT was being serious. This was the proposal:
>>
>> for (unsigned n = 100; n > 0; --n)
>> {
>> switch (rand() % 4)
>> {
>> if (0) {
>> case 0:
>> printf("Case zero");
>> } else if (0) {
>> case 1:
>> printf("Case one");
>> } else if (0) {
>> case 2:
>> printf("Case two");
>> } else if (0) {
>> case 3:
>> printf("Case three");
>> }
>> printf("\n");
>> }
>> }
>> }
>>
>>
>> It looks more of a mess than just writing the breaks. And there is
>> something funny about it: that final 'printf' is inside the switch's
>> compound statement, and here it is executed after any of the 4 cases.
>>
>> Without the if-ladder, it would have to go outside the compound
>> statement. So it changes the behaviour subtly.
>>
>> Here is the same functionality as above, using my everyday language:
>>
>> to 100 do
>> switch rand() rem 4
>> when 0 then print "Case zero"
>> when 1 then print "Case one"
>> when 2 then print "Case two"
>> when 3 then print "Case three"
>> end
>> println
>> end
>>
>> There is little clutter and little ambiguity. This is why syntax is
>> important including doing 'switch' properly.
>>
>>
>> For a fairer comparison, here is more idiomatic C:
>>
>> for (unsigned n = 100; n > 0; --n)
>> {
>> switch (rand() % 4) {
>> case 0:
>> printf("Case zero");
>> break;
>> case 1:
>> printf("Case one");
>> break;
>> case 2:
>> printf("Case two");
>> break;
>> case 3:
>> printf("Case three");
>> break;
>> }
>> printf("\n");
>> }
>>
>> Needing those breaks makes it harder to inline the cases and printfs.
>
> Oh, it's not hard at all. What you do to put everything in a single
> line, is to wrap the whole thing an a function, then you can just return
> the value of the printf(), and no error code is lost.
>
> for ( signed n = 100 ; n > 0 ; n-- ) switch ( n ) {
> /* Gets rid of the superfluous curlies before the switch. */
> case 0: return printf( "case zero" ) ;
> case 1: return printf( "case one" ) ;
> case 2: return printf( "case two" ) ;
> case 3: return printf( "case three" ) ;
> }
>
> And then you refactor the final printf() into the call to the new fun-
> ction.
>
> This is much shorter, and clearer. I hope you weren't talking about the
> /inline/ keyword. It also has the side effect of not needing the
> /break/ keyword at all.
>
>
> Best wishes, and happy short switch () statements!
Dear me! I forgot to put the rand() in the switch, so here goes.
for ( signed n = 100 ; n > 0 ; n-- ) switch ( rand( n ) % 4 ) {
Much better, and we are now approaching the line length limit of Usenet.
This makes much better use of the vertical space, and saves pages for
the inevitable printout.
Best wishes, and happy C coding!
--
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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-10 00:25 +0000 |
| Message-ID | <11ac0mi$19kfd$1@dont-email.me> |
| In reply to | #402647 |
For comparison, here is an example of Python’s match-statement. Like
all the good (i.e. non-C-based) designs, the designers saw no point in
having fall-through.
This is a very simple example, involving straight matching of values
against instances of an enum. There are also more complex
pattern-matching options available.
for b in sb :
self.chars_seen.append(b)
match self.parse_state :
case PARSE_STATE.EXPECT_LEN :
if ord("0") <= b <= ord("9") :
digit = b - ord("0")
if digit == 0 and len(self.chars_seen) == 2 and self.len == 0 :
raise NetstringSyntaxError \
(
"length must not have leading zero: %s"
%
bytes(self.chars_seen).decode()
)
#end if
if (
self.len > MAX_NETSTRING_LEN // 10
or
self.len == MAX_NETSTRING_LEN // 10
and
digit > MAX_NETSTRING_LEN % 10
) :
raise NetstringSyntaxError \
("length too large: %s" % bytes(self.chars_seen).decode())
#end if
self.len = self.len * 10 + digit
elif b == ord(":") :
if len(self.chars_seen) < 2 :
raise NetstringSyntaxError \
("missing length prefix: %s" % repr(bytes(self.chars_seen)))
#end if
if self.len != 0 :
self.parse_state = PARSE_STATE.EXPECT_CHARS
else :
self.parse_state = PARSE_STATE.EXPECT_END
#end if
self.content = []
else :
raise NetstringSyntaxError \
(
"expecting digits of length or colon: %s"
%
repr(bytes(self.chars_seen))
)
#end if
#end case
case PARSE_STATE.EXPECT_CHARS :
self.content.append(b)
self.len -= 1
if self.len == 0 :
self.parse_state = PARSE_STATE.EXPECT_END
#end if
#end case
case PARSE_STATE.EXPECT_END :
if b == ord(",") :
self.parse_state = PARSE_STATE.PARSE_DONE
else :
raise NetstringSyntaxError \
("expecting comma after netstring: %s" % repr(bytes(self.chars_seen)))
#end if
#end case
case PARSE_STATE.PARSE_DONE :
raise NetstringSyntaxError \
("junk after complete netstring: %s" % repr(bytes(self.chars_seen)))
#end case
#end match
#end for
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web