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 202 — 20 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement 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 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement 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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-04 22:47 +0100 |
| Message-ID | <119uhi9$a7pd$1@dont-email.me> |
| In reply to | #402682 |
On 04/10/2026 21:27, David Brown wrote:
> 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.
No, they're applying layers of extra gobbledygook on top of what ought
to straightforward tasks.
Suppose you had to make a product, but inside it has ten times as much
circuitry as needed. /You/ would claim it is simple because you still
turn it on by flicking one switch.
But, having tangible elements, it is unsatisfactory because it will cost
more, have more failure points, take longer to manufacturer, might
operate more slowly, consume more power, be harder to maintain, be
bigger, heavier and so on.
You seem to think you can get away with that with software. Sure, it
will work, but there are still extra costs.
If I can give a book analogy: you are tasked with producing a book
(novel, manual, whatever), but it ends up as 5000 pages, when it
shouldn't be more than 500.
What do to? The software approach seems to be to print using a font 1/3
the size, so that it fits into 500 pages! So the mess of complexity, bad
writing and poor structure hasn't been addressed at all. And people will
need to spend ten times as longer reading it.
> 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.
This case in point is a misfeature of C that has never been fixed
despite plenty of opportunity.
The only suggestion people have is to provide an option inside /some/
tools that might detect /some/ misuse. That means you can't just do:
tcc prog.c
which might otherwise be perfectly adequate. What I would have preferred
for C is a new statement such as:
match (x) {
case a, b, c {}
case d, f {}
else {}
}
(Trying to make it fit C brace style.)
This allows any types for which == is defined; allows runtime
expressions for a, b, c etc, and each {} skips to the end when it
reaches the }.
> 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.
Actually many imperial units /are/ handier for every day use.
Feet and inches are just the right size for many human-scaled uses,
while the odd factors of 12 inches to the foot, 3 feet to the yard, make
it harder to accidentally mix them up, which happens easily when every
factor is 10.
> 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.
Yes, I'm prejudiced about big software, big tools, big corporations and
endless layers of complexity.
I still do what I do in order to make a stand against that. I think it's
more important now than ever. No one is going to use my products, but it
doesn't matter.
It shows what is still possible.
I thought all this complexity would sort itself out when everything
slowed to a standstill. But no, people just redoubled their efforts in
just throwing more hardware at it, using AI to deal with some of the
complexity, which then itself needs even more resources.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-04 21:59 +0000 |
| Message-ID | <T_zwS.28527$O_Vb.26606@fx07.iad> |
| In reply to | #402680 |
Richard Harnden <richard.nospam@gmail.invalid> writes: >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). More generally, it contains whatever the programmer needs to create the application. Which in the real world isn't contained in a single source file or limited to a single source language.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-04 23:38 +0000 |
| Message-ID | <119uo2c$3kc0t$1@paganini.bofh.team> |
| In reply to | #402655 |
bart <bc@freeuk.com> wrote:
> On 03/10/2026 17:02, David Brown wrote:
>> On 03/10/2026 10:43, Lawrence D’Oliveiro wrote:
>>> How not to forget to end each case-sequence in a switch statement with
>>> a break-statement: put the break at the same indentation level as the
>>> case-clause as well as the switch-expression. That way, you can scan
>>> your eye down a single line for each switch-statement to be sure that
>>> no breaks are missing. A reasonably-complex example, with a nested
>>> switch for added interest:
>>>
>>
>> gcc -Werror=implict-fallthrough
>
>
> I assume this is for non-empty blocks? Otherwise this will be an error:
>
> case 'A': case 'B': case 'C':
> // deal with ABC
>
> 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.
The check is easy to implement. Of course, if your compiler needs
to run on PDP-11, then you need to make compromises so that the
compiler fits in available address space. But IIUC 'lint' run of PDP-11
and I think it detected such problems. If you target something
bigger, like a VAX you should have no trouble adding such a warning
to simple compiler. The real problem is that you may get code
from somebody else that depends on falltrough, but does not mark
it in the source. But that is life: if you pay for code you can
demad that it is written in a way you like. If you get it for
free quality and style depend on the author. We have a saying
"do not look at teeth of a horse that you got for free".
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-05 01:24 +0100 |
| Message-ID | <119uqnv$d6j2$1@dont-email.me> |
| In reply to | #402685 |
On 05/10/2026 00:38, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 03/10/2026 17:02, David Brown wrote: >>> On 03/10/2026 10:43, Lawrence D’Oliveiro wrote: >>>> How not to forget to end each case-sequence in a switch statement with >>>> a break-statement: put the break at the same indentation level as the >>>> case-clause as well as the switch-expression. That way, you can scan >>>> your eye down a single line for each switch-statement to be sure that >>>> no breaks are missing. A reasonably-complex example, with a nested >>>> switch for added interest: >>>> >>> >>> gcc -Werror=implict-fallthrough >> >> >> I assume this is for non-empty blocks? Otherwise this will be an error: >> >> case 'A': case 'B': case 'C': >> // deal with ABC >> >> 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. > > The check is easy to implement. Of course, if your compiler needs > to run on PDP-11, then you need to make compromises so that the > compiler fits in available address space. But IIUC 'lint' run of PDP-11 > and I think it detected such problems. If you target something > bigger, like a VAX you should have no trouble adding such a warning > to simple compiler. The real problem is that you may get code > from somebody else that depends on falltrough, but does not mark > it in the source. But that is life: if you pay for code you can > demad that it is written in a way you like. If you get it for > free quality and style depend on the author. We have a saying > "do not look at teeth of a horse that you got for free". A lot of what big compilers do is what used to be called 'linting'. I don't consider that to be their job, which should be to verify my program and turn it into runnable code, and not give opinions. However I don't believe that what we're talking about here really is linting either, since it isn't /its/ job to make up for shortcomings of a language. I gave a suggestion elsewhere for a new 'match' statement. Clearly that's never going to happen. So if I was in the position of needing to write actual C code myself with the code maintainable in C if needed (so transpiling is out), then I would write another syntax wrapper.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-05 21:48 +0000 |
| Message-ID | <20261005143559.157@kylheku.com> |
| In reply to | #402689 |
On 2026-10-05, bart <bc@freeuk.com> wrote: > A lot of what big compilers do is what used to be called 'linting'. I don't suspect you can get rid of that in any language. The reason is that as experience with the given language grows, it is found that programmers make certain mistakes, where making formal syntactic and semantic rules against those mistakes, and sticking them into the language, would be a poor idea. At some point, you are trying to design a pencil that cannot be used to draw an optical illusion. > I don't consider that to be their job, which should be to verify my > program and turn it into runnable code, and not give opinions. That's a waste of potential; why would you refuse a machine that can apply hundreds of deterministic pattern matching rules against possible trouble situations in hundreds of thousands of lines of code, in seconds. > However I don't believe that what we're talking about here really is > linting either, since it isn't /its/ job to make up for shortcomings of > a language. If you think you have a language that has no shortcomings, and are still writing a linting tool, of course you must believe that the tool does something other than address shortcomings in the language. One obvious viewpoint is to reframe the tool as addressing the shortcomings of the /users/ of the perfect language. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-06 00:11 +0100 |
| Message-ID | <11a1arj$1e8ks$1@dont-email.me> |
| In reply to | #402717 |
On 05/10/2026 22:48, Kaz Kylheku wrote:
> On 2026-10-05, bart <bc@freeuk.com> wrote:
>> A lot of what big compilers do is what used to be called 'linting'.
>
> I don't suspect you can get rid of that in any language.
>
> The reason is that as experience with the given language grows, it is
> found that programmers make certain mistakes, where making formal
> syntactic and semantic rules against those mistakes, and sticking
> them into the language, would be a poor idea.
>
> At some point, you are trying to design a pencil that cannot be
> used to draw an optical illusion.
>
>> I don't consider that to be their job, which should be to verify my
>> program and turn it into runnable code, and not give opinions.
>
> That's a waste of potential; why would you refuse a machine that
> can apply hundreds of deterministic pattern matching rules against
> possible trouble situations in hundreds of thousands of lines of code,
> in seconds.
I simply don't care about it. I don't have seconds to waste either.
Here are some common C-compiling scenarios:
* You want to build a finished, working, debugged program from source.
This does need the compiler spending time double-guessing the author's
intentions, and in any case the person building it is not going to
mess with the source
* You are building a program which is machine-transpiled C code. It
should be valid C with no errors. (If there are, that is the
responsibility of the transpiler author.) But again you don't care
about style, or the fact that there are lots of unused labels for
example (common in such code)
* You've made a one-line change and just quickly want to run it again.
You don't want a style analysis on the same few thousand lines that
has already been recently done.
Linting is something you might do every so often - not for routine builds.
However, with C compilers it is common for warnings to be generated
rather than hard errors.
This is blurring the line between compiling and linting:
* Is the transgression serious? Is so then report an error and fail to
compile
* If not then leave it to a linter. (These days that just means running
it through a big compiler.)
With C, that leaves the question of what to do about common errors due
to shortcomings:
if (a = 0)
Here it is likely that this was supposed to be 'a == 0' (otherwise this
will always be false).
But, since it is valid code, I would still say leave to an explicit
linker. (Here, gcc won't report it unless instructed, but it doesn't
make the compiler much faster if those options are turned off! I could
be wrong though; maybe they make it even slower when turned on.)
>> However I don't believe that what we're talking about here really is
>> linting either, since it isn't /its/ job to make up for shortcomings of
>> a language.
>
> If you think you have a language that has no shortcomings, and
> are still writing a linting tool, of course you must believe that
> the tool does something other than address shortcomings
> in the language.
My own languages will have plenty of their own problems, but not the
kinds of howlers that you get in C.
Linting (via the advanced options of gcc, clang etc) is what is
advocated here but I don't think much of it as it doesn't fix the
underlying problem, which is a poorly designed language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 09:49 +0200 |
| Message-ID | <11a295r$1lqal$3@dont-email.me> |
| In reply to | #402721 |
On 06/10/2026 01:11, bart wrote: > On 05/10/2026 22:48, Kaz Kylheku wrote: >> On 2026-10-05, bart <bc@freeuk.com> wrote: >>> A lot of what big compilers do is what used to be called 'linting'. >> >> I don't suspect you can get rid of that in any language. >> >> The reason is that as experience with the given language grows, it is >> found that programmers make certain mistakes, where making formal >> syntactic and semantic rules against those mistakes, and sticking >> them into the language, would be a poor idea. >> >> At some point, you are trying to design a pencil that cannot be >> used to draw an optical illusion. >> >>> I don't consider that to be their job, which should be to verify my >>> program and turn it into runnable code, and not give opinions. >> >> That's a waste of potential; why would you refuse a machine that >> can apply hundreds of deterministic pattern matching rules against >> possible trouble situations in hundreds of thousands of lines of code, >> in seconds. > > I simply don't care about it. I don't have seconds to waste either. > > Here are some common C-compiling scenarios: > > * You want to build a finished, working, debugged program from source. > This does need the compiler spending time double-guessing the author's > intentions, and in any case the person building it is not going to > mess with the source Warnings are still useful, because you might be compiling in circumstances the code author did not foresee. The code might have worked on the author's system, with the authors compiler version and target processor, and other surrounding code, but have issues on your system - if a warning can help spot that, great! You also don't seem to understand the costs and resources involved - despite having written your little compiler, there's a great deal about more advanced toolchains that you seem to miss. Compiler warnings are, for practical purposes, free at compile-time. The analysis that must be done to generate the warnings is already done for parsing, code generation and in particular, for optimisation. (There are other types of code analysis that take significantly more time and effort, and are not normally part of end-user builds - clang-tidy, gcc -fanalyzer, PVS Studio, Sonar, etc. But that's a different kind of tool.) > > * You are building a program which is machine-transpiled C code. It > should be valid C with no errors. (If there are, that is the > responsibility of the transpiler author.) But again you don't care > about style, or the fact that there are lots of unused labels for > example (common in such code) That's quite a rare situation (for more specialised and niche uses, or experimental programming languages). But the same thing applies here as above. > > * You've made a one-line change and just quickly want to run it again. > You don't want a style analysis on the same few thousand lines that > has already been recently done. When you have made a change in your code, you very much /do/ want warnings enabled in the build. If no warnings are generated, no time is wasted - if your change leads to warnings, then that very quickly saves you a lot of programmer time and effort by showing you the issues early. Of course, that assumes that you have a sane development practice where you normally have warning-free builds (by writing good code, and by picking appropriate warnings to suit your style and coding needs). > > Linting is something you might do every so often - not for routine builds. Basic "lint" programs for C have not been in use for decades - they hark back to the days when a C compiler that could also generate good warnings was too big to fit in the host computer's memory. A C tool could either have tables of assembly opcodes, or tables of warning messages, but did not have room for both at the same time. Basic linting is now always done by compilers - or by IDEs and programmers editors before you even get as far as compiling. What /is/ done with separate programs is more advanced analysis. These can produce reports with statistics, analyse the interplay between multiple translation units, check against style guides, or run specialised project-specific analysis. Some such tools are fast enough for every build, some run overnight, some run automatically when you check in code to your repository, others you run every now and again. > > However, with C compilers it is common for warnings to be generated > rather than hard errors. Yes. Some things /are/ warnings, not hard errors. They indicate questionable code, rather than definitely incorrect code. My usual practice is to have warnings as warnings early in a project, when I might have a lot of bits of code from elsewhere. As the project starts to take shape and I am getting complete builds, including linking, and minimal warnings, I switch to "-Werror" so that warning messages are treated as hard errors. Other people may have different practices - but the attitude of "it's just a warning - if it were a serious problem, it would have been an error" is a recipe for tears. > > This is blurring the line between compiling and linting: > If you like. > * Is the transgression serious? Is so then report an error and fail to > compile Who decides what is serious or not? Some people in this group would say that shadowing an existing identifier is a serious transgression, and should not be allowed in the code. Others say it is entirely fine. The C language standards are clear on exactly how it works, and that it is legal C - so a C compiler should not complain about it by default. But for those that think it is bad, gcc gives you the option and lets you choose if you see it as an error, a warning, or you will ignore it. It lets you fine-tune some aspects of which type of shadowing you want to catch or allow. It lets you have a general "no shadowing" policy but mark cases in code where you allow exceptions. The /programmer/ makes the choices here. As usual, you live and think within your little bubble where /you/ are the language designer, the toolchain writer, and the sole user - you get to decide everything, and you can put your rules and preferences anywhere that is most convenient. The real software development world is not like that. > > * If not then leave it to a linter. (These days that just means running > it through a big compiler.) > > With C, that leaves the question of what to do about common errors due > to shortcomings: > > if (a = 0) > > Here it is likely that this was supposed to be 'a == 0' (otherwise this > will always be false). > > But, since it is valid code, I would still say leave to an explicit > linker. (Here, gcc won't report it unless instructed, but it doesn't > make the compiler much faster if those options are turned off! I could > be wrong though; maybe they make it even slower when turned on.) > Key here is that this is /valid/ code, and merely /likely/ to be false. Compilers should, by default, accept it at face value - and they should make it easy to enable warnings that spot such likely bad code. This should not be something that you find later on, when you get round to running a linter. >>> However I don't believe that what we're talking about here really is >>> linting either, since it isn't /its/ job to make up for shortcomings of >>> a language. >> >> If you think you have a language that has no shortcomings, and >> are still writing a linting tool, of course you must believe that >> the tool does something other than address shortcomings >> in the language. > > My own languages will have plenty of their own problems, but not the > kinds of howlers that you get in C. > > Linting (via the advanced options of gcc, clang etc) is what is > advocated here but I don't think much of it as it doesn't fix the > underlying problem, which is a poorly designed language. > "There are two sorts of programming languages - the ones people complain about, and the ones no one uses."
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-06 11:12 +0200 |
| Message-ID | <11a2e2m$ef4o$2@dont-email.me> |
| In reply to | #402733 |
On 2026-10-06 09:49, David Brown wrote: > On 06/10/2026 01:11, bart wrote: >> >> I simply don't care about it. I don't have seconds to waste either. (Says someone wasting _hours_ of not only his but everyone's time.) LOL. (Some statements are really inherently funny! - If the story behind wouldn't be so sad.) > >> >> However, with C compilers it is common for warnings to be generated >> rather than hard errors. > > Yes. Some things /are/ warnings, not hard errors. They indicate > questionable code, rather than definitely incorrect code. We should be aware that this is very much depending on the specific programming language used. A language like "C" that had e.g. mixed 'int' and 'bool' will allow much more [unsafe] coding patterns than a similar language with these types separated and support of strong typing. That flexibility comes not for free. > >> * Is the transgression serious? Is so then report an error and fail to >> compile > > Who decides what is serious or not? Indeed. > [...] > > As usual, you live and think within your little bubble where /you/ are > the language designer, the toolchain writer, and the sole user - you get > to decide everything, and you can put your rules and preferences > anywhere that is most convenient. That's factually a comfortable and enviable situation. :-) > The real software development world is not like that. Yes. (That's part of the/his problem.) >> >> With C, that leaves the question of what to do about common errors due >> to shortcomings: >> >> if (a = 0) >> >> Here it is likely that this was supposed to be 'a == 0' (otherwise >> this will always be false). >> >> But, since it is valid code, I would still say leave to an explicit >> linker. (Here, gcc won't report it unless instructed, but it doesn't >> make the compiler much faster if those options are turned off! I could >> be wrong though; maybe they make it even slower when turned on.) >> > > Key here is that this is /valid/ code, and merely /likely/ to be false. [in "C"] Indeed. > Compilers should, by default, accept it at face value - and they should > make it easy to enable warnings that spot such likely bad code. This > should not be something that you find later on, when you get round to > running a linter. The [language specific] problem mentioned is especially a problem for newbies (who lack awareness) or folks who regularly use different types of languages (and make typos/muscle memory "brainos"). Upon reflection or instruction especially these two groups should best enable warnings (and of course read them). >> >> My own languages will have plenty of their own problems, but not the >> kinds of howlers that you get in C. >> >> [...] >> > > "There are two sorts of programming languages - the ones people complain > about, and the ones no one uses." :-) What I find interesting is the admission of "plenty of own problems" [in his own languages]; given that, especially with the qualification "plenty", I now wonder yet more about the enduring crusade against "C" (even if the sort of problems with "C" are of "different kind"). Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 12:41 +0200 |
| Message-ID | <11a2j83$1qu9n$1@dont-email.me> |
| In reply to | #402739 |
On 06/10/2026 11:12, Janis Papanagnou wrote: > On 2026-10-06 09:49, David Brown wrote: >> On 06/10/2026 01:11, bart wrote: >>> >>> I simply don't care about it. I don't have seconds to waste either. > > (Says someone wasting _hours_ of not only his but everyone's time.) > > LOL. (Some statements are really inherently funny! - If the story > behind wouldn't be so sad.) > >> >>> >>> However, with C compilers it is common for warnings to be generated >>> rather than hard errors. >> >> Yes. Some things /are/ warnings, not hard errors. They indicate >> questionable code, rather than definitely incorrect code. > > We should be aware that this is very much depending on the specific > programming language used. A language like "C" that had e.g. mixed > 'int' and 'bool' will allow much more [unsafe] coding patterns than > a similar language with these types separated and support of strong > typing. That flexibility comes not for free. > >> >>> * Is the transgression serious? Is so then report an error and fail to >>> compile >> >> Who decides what is serious or not? > > Indeed. > >> [...] >> >> As usual, you live and think within your little bubble where /you/ are >> the language designer, the toolchain writer, and the sole user - you >> get to decide everything, and you can put your rules and preferences >> anywhere that is most convenient. > > That's factually a comfortable and enviable situation. :-) > >> The real software development world is not like that. > > Yes. (That's part of the/his problem.) > >>> >>> With C, that leaves the question of what to do about common errors >>> due to shortcomings: >>> >>> if (a = 0) >>> >>> Here it is likely that this was supposed to be 'a == 0' (otherwise >>> this will always be false). >>> >>> But, since it is valid code, I would still say leave to an explicit >>> linker. (Here, gcc won't report it unless instructed, but it doesn't >>> make the compiler much faster if those options are turned off! I >>> could be wrong though; maybe they make it even slower when turned on.) >>> >> >> Key here is that this is /valid/ code, and merely /likely/ to be false. > > [in "C"] Indeed. > >> Compilers should, by default, accept it at face value - and they >> should make it easy to enable warnings that spot such likely bad >> code. This should not be something that you find later on, when you >> get round to running a linter. > > The [language specific] problem mentioned is especially a problem for > newbies (who lack awareness) or folks who regularly use different types > of languages (and make typos/muscle memory "brainos"). Upon reflection > or instruction especially these two groups should best enable warnings > (and of course read them). > Anyone who sometimes makes mistakes should enable warnings. And that means /everyone/ should enable copious warnings. Some kinds of warnings are more likely to be triggered by people new to the language, certainly. But that does not mean more experienced people should not enable those same warnings - it just means they are less likely to be triggered. I'd guess that in my projects, there are typically 50 or more warnings enabled (-Wall -Wextra pull in a lot, with some of these then individually disabled). The solid majority are never triggered. But they are good to have in, because sometimes I make a typo, or have some other error that I would not have written intentionally. The warning flags are also, in a limited way, part of the documentation of the project and its coding style - there in the makefile, as part of the source code, is the rule that the code shall not have variables that are set but not used (-Wunused-but-set-variable). That's a rule for my coding - such unused variables are confusing to readers, who should be wondering why the code has them. Many warnings are for style rather than content - but good, consistent style reduces the risk of some kinds of errors. (Of course different people or projects will have different choices of these flags.) There is nothing to be gained by experienced developers skipping warnings because "only a newbie would make that mistake". It's like saying only learner drivers need seatbelts. >>> >>> My own languages will have plenty of their own problems, but not the >>> kinds of howlers that you get in C. >>> >>> [...] >>> >> >> "There are two sorts of programming languages - the ones people >> complain about, and the ones no one uses." > > :-) To be clear - that's a quotation from Bjarne Stroustup of C++ fame. > > What I find interesting is the admission of "plenty of own problems" > [in his own languages]; given that, especially with the qualification > "plenty", I now wonder yet more about the enduring crusade against "C" > (even if the sort of problems with "C" are of "different kind"). > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-10-06 12:33 +0100 |
| Message-ID | <11a2maf$1soc7$1@dont-email.me> |
| In reply to | #402741 |
On 06/10/2026 11:41, David Brown wrote: > On 06/10/2026 11:12, Janis Papanagnou wrote: >> On 2026-10-06 09:49, David Brown wrote: >>> On 06/10/2026 01:11, bart wrote: >>>> >>>> I simply don't care about it. I don't have seconds to waste either. >> >> (Says someone wasting _hours_ of not only his but everyone's time.) >> >> LOL. (Some statements are really inherently funny! - If the story >> behind wouldn't be so sad.) >> >>> >>>> >>>> However, with C compilers it is common for warnings to be generated >>>> rather than hard errors. >>> >>> Yes. Some things /are/ warnings, not hard errors. They indicate >>> questionable code, rather than definitely incorrect code. >> >> We should be aware that this is very much depending on the specific >> programming language used. A language like "C" that had e.g. mixed >> 'int' and 'bool' will allow much more [unsafe] coding patterns than >> a similar language with these types separated and support of strong >> typing. That flexibility comes not for free. >> >>> >>>> * Is the transgression serious? Is so then report an error and fail to >>>> compile >>> >>> Who decides what is serious or not? >> >> Indeed. >> >>> [...] >>> >>> As usual, you live and think within your little bubble where /you/ >>> are the language designer, the toolchain writer, and the sole user - >>> you get to decide everything, and you can put your rules and >>> preferences anywhere that is most convenient. >> >> That's factually a comfortable and enviable situation. :-) >> >>> The real software development world is not like that. >> >> Yes. (That's part of the/his problem.) >> >>>> >>>> With C, that leaves the question of what to do about common errors >>>> due to shortcomings: >>>> >>>> if (a = 0) >>>> >>>> Here it is likely that this was supposed to be 'a == 0' (otherwise >>>> this will always be false). >>>> >>>> But, since it is valid code, I would still say leave to an explicit >>>> linker. (Here, gcc won't report it unless instructed, but it doesn't >>>> make the compiler much faster if those options are turned off! I >>>> could be wrong though; maybe they make it even slower when turned on.) >>>> >>> >>> Key here is that this is /valid/ code, and merely /likely/ to be false. >> >> [in "C"] Indeed. >> >>> Compilers should, by default, accept it at face value - and they >>> should make it easy to enable warnings that spot such likely bad >>> code. This should not be something that you find later on, when you >>> get round to running a linter. >> >> The [language specific] problem mentioned is especially a problem for >> newbies (who lack awareness) or folks who regularly use different types >> of languages (and make typos/muscle memory "brainos"). Upon reflection >> or instruction especially these two groups should best enable warnings >> (and of course read them). >> > > Anyone who sometimes makes mistakes should enable warnings. And that > means /everyone/ should enable copious warnings. > > Some kinds of warnings are more likely to be triggered by people new to > the language, certainly. But that does not mean more experienced people > should not enable those same warnings - it just means they are less > likely to be triggered. I'd guess that in my projects, there are > typically 50 or more warnings enabled (-Wall -Wextra pull in a lot, with > some of these then individually disabled). The solid majority are never > triggered. But they are good to have in, because sometimes I make a > typo, or have some other error that I would not have written intentionally. > > The warning flags are also, in a limited way, part of the documentation > of the project and its coding style - there in the makefile, as part of > the source code, is the rule that the code shall not have variables that > are set but not used (-Wunused-but-set-variable). That's a rule for my > coding - such unused variables are confusing to readers, who should be > wondering why the code has them. Many warnings are for style rather > than content - but good, consistent style reduces the risk of some kinds > of errors. (Of course different people or projects will have different > choices of these flags.) > > There is nothing to be gained by experienced developers skipping > warnings because "only a newbie would make that mistake". It's like > saying only learner drivers need seatbelts. I find warnings save me far more time than having the compile take <1ms. But, Bart seems obsessed with compile times. Also, I need to drink my tea at some point. > >>>> >>>> My own languages will have plenty of their own problems, but not the >>>> kinds of howlers that you get in C. >>>> >>>> [...] >>>> >>> >>> "There are two sorts of programming languages - the ones people >>> complain about, and the ones no one uses." >> >> :-) > > To be clear - that's a quotation from Bjarne Stroustup of C++ fame. > >> >> What I find interesting is the admission of "plenty of own problems" >> [in his own languages]; given that, especially with the qualification >> "plenty", I now wonder yet more about the enduring crusade against "C" >> (even if the sort of problems with "C" are of "different kind"). >> >> Janis >> >
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-06 15:16 +0100 |
| Message-ID | <11a2vrn$20jj3$1@dont-email.me> |
| In reply to | #402745 |
On 06/10/2026 12:33, Richard Harnden wrote:
> On 06/10/2026 11:41, David Brown wrote:
>> There is nothing to be gained by experienced developers skipping
>> warnings because "only a newbie would make that mistake". It's like
>> saying only learner drivers need seatbelts.
>
> I find warnings save me far more time than having the compile take <1ms.
> But, Bart seems obsessed with compile times.
Why does nobody care that some utility takes ten times as long as it should?
To /me/, it seems that everybody is obsessed with getting the BEST
POSSIBLE PERFORMANCE from their applications, so that huge resources are
poured into highly optimising compilers.
EXCEPT ... when the application in question is a compiler. Then nobody
here seems to cares how slow and inefficient it is! Oh, just add a few
more cores and more RAM, rather than address the problem.
This is a test file called 'cc.c'; 1.85MB, 85Kloc. It is
machine-generated C code. Generating that file took 0.09 seconds.
Here is how long it takes to compile to EXE:
gcc -O0 5.6 seconds
clang -O0 4.1 seconds
bcc 0.17 seconds
mm 0.08 seconds (from original source to EXE)
So gcc/clang takes 25-30 times as long as my bcc product - WHY? WTF is
it doing for this extra 3.9 or 5.4 seconds?
And this is unoptimised code so that gcc/clang is as bad as mine!
(Actually, for this program, gcc/clang's code was 60-70% slower than mine.)
Here's a test using a regular C input:
Build=time Test prog
gcc -O0 lua.c 3.35 s 9.7 s
clang -O0 lua.c 3.5 s 12.0 s
bcc lua.c 0.13 s 6.5 s
(tcc lua.c 0.12 s 9.7 s)
Now, gcc/clang take 25-28 times as long to build, while the code is
50-80% slower.
How can such figures possibly be defended?
>Bart seems obsessed with compile times.
Actually, more with how slow compilers are rather than how fast.
The speed of converting source code of a simple HLL is naturally fast.
You don't need to try very hard - just keep on the ball.
So what's gone wrong with those other products, and why don't they
provide a fast path?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-06 14:37 +0000 |
| Message-ID | <EI7xS.906$aNSb.21@fx20.iad> |
| In reply to | #402748 |
bart <bc@freeuk.com> writes: >On 06/10/2026 12:33, Richard Harnden wrote: >> On 06/10/2026 11:41, David Brown wrote: > >>> There is nothing to be gained by experienced developers skipping >>> warnings because "only a newbie would make that mistake". It's like >>> saying only learner drivers need seatbelts. >> >> I find warnings save me far more time than having the compile take <1ms. > > > >> But, Bart seems obsessed with compile times. > >Why does nobody care that some utility takes ten times as long as it should? Perhaps because the difference between 2ms and 10ms isn't perceptable?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-06 17:27 +0100 |
| Message-ID | <11a37gv$23ruj$1@dont-email.me> |
| In reply to | #402751 |
On 06/10/2026 15:37, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 06/10/2026 12:33, Richard Harnden wrote: >>> On 06/10/2026 11:41, David Brown wrote: >> >>>> There is nothing to be gained by experienced developers skipping >>>> warnings because "only a newbie would make that mistake". It's like >>>> saying only learner drivers need seatbelts. >>> >>> I find warnings save me far more time than having the compile take <1ms. >> >> >> >>> But, Bart seems obsessed with compile times. >> >> Why does nobody care that some utility takes ten times as long as it should? > > Perhaps because the difference between 2ms and 10ms isn't perceptable? What program can gcc compile in 10ms, Hello World? Under WSL, hello.c takes 150ms, and under Windows, over 250ms. Gcc's throughput on my machine is of the order of 10K lines per second, for -O0. So for 10ms, ignoring overheads, it might be able to compile 100 lines of code in 10ms. So I don't know what rubbish you're spouting, but you always give these nonsense figures, meanwhile you haven't been able to figure out how to speed up your own build which take /minutes/ even after using multiple cores.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-06 23:14 +0000 |
| Message-ID | <11a3vcj$88e7$1@paganini.bofh.team> |
| In reply to | #402757 |
bart <bc@freeuk.com> wrote:
> On 06/10/2026 15:37, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 06/10/2026 12:33, Richard Harnden wrote:
>>>> On 06/10/2026 11:41, David Brown wrote:
>>>
>>>>> There is nothing to be gained by experienced developers skipping
>>>>> warnings because "only a newbie would make that mistake". It's like
>>>>> saying only learner drivers need seatbelts.
>>>>
>>>> I find warnings save me far more time than having the compile take <1ms.
>>>
>>>
>>>
>>>> But, Bart seems obsessed with compile times.
>>>
>>> Why does nobody care that some utility takes ten times as long as it should?
>>
>> Perhaps because the difference between 2ms and 10ms isn't perceptable?
> What program can gcc compile in 10ms, Hello World?
On my machine the following non-canonical version of Hello World:
#include <unistd.h>
int
main(void) {
write(1, "Hello\n", 6);
return 0;
}
takes about 20-22 ms. More realistically, compilation of a lead
C program (66 lines) and linking of several .o files (many
produced by a non-C compiler) + libc needs 23 ms producing
66 kB executable (of which 20 kB is code and the rest is mainly
debug info). The same, but linking statically to libc needs 56 ms
and produces 550 kB executable (of which 413 kB is code).
Note: the last two are for Risc-V. That is compiler runs on my PC,
but executables only run on Risc-V machine. And actually
transferring the executable takes more time than C compilation.
> Under WSL, hello.c takes 150ms, and under Windows, over 250ms.
150 ms is still not too long. And large part of it is likely to
be gcc startup time, so you can make program larger whithout large
increase of compile time.
> Gcc's throughput on my machine is of the order of 10K lines per second,
> for -O0. So for 10ms, ignoring overheads, it might be able to compile
> 100 lines of code in 10ms.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 01:25 +0100 |
| Message-ID | <11a43hl$2e5k2$1@dont-email.me> |
| In reply to | #402767 |
On 07/10/2026 00:14, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> What program can gcc compile in 10ms, Hello World?
>
> On my machine the following non-canonical version of Hello World:
>
> #include <unistd.h>
> int
> main(void) {
> write(1, "Hello\n", 6);
> return 0;
> }
>
> takes about 20-22 ms. More realistically, compilation of a lead
> C program (66 lines) and linking of several .o files (many
> produced by a non-C compiler) + libc needs 23 ms producing
> 66 kB executable (of which 20 kB is code and the rest is mainly
> debug info). The same, but linking statically to libc needs 56 ms
> and produces 550 kB executable (of which 413 kB is code).
> Note: the last two are for Risc-V. That is compiler runs on my PC,
> but executables only run on Risc-V machine. And actually
> transferring the executable takes more time than C compilation.
So, on your machine, what's the throughput of gcc in lines per second?
I mean something more accurate than the 300lps of your 6-line example
which will be mostly due to overheads.
My compilers for Windows tend to work at up 0.5Mlps, and between 1-2
magnitudes faster than gcc.
> 150 ms is still not too long.
I use Windows where it is 250ms (a bit lower now), and yet my own
product works fine on it; this is my C compiler building sqlite3:
c:\cx>tim bcc sql
Compiling sql.c to sql.exe
Time: 0.228
And this is gcc 14 building hello.c:
c:\cx>tim gcc hello.c
Time: 0.203
And gcc 10:
c:\cx>tim \tdm10\bin\gcc hello.c
Time: 0.244
And clang:
c:\cx>tim clang hello.c
Time: 0.263
Amazing isn't it that I can build a working SQL program in about the
time it takes gcc/clang to build Hello, World! bcc is not even optimised.
> And large part of it is likely to
> be gcc startup time, so you can make program larger whithout large
> increase of compile time.
Yes, it is big and slow and they haven't provided a fast path (like a
secretly bundled version of tcc) when you need an instant, streamlined
result.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-07 04:19 +0000 |
| Message-ID | <11a4h8v$eeb8$1@paganini.bofh.team> |
| In reply to | #402774 |
bart <bc@freeuk.com> wrote:
> On 07/10/2026 00:14, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>
>>> What program can gcc compile in 10ms, Hello World?
>>
>> On my machine the following non-canonical version of Hello World:
>>
>> #include <unistd.h>
>> int
>> main(void) {
>> write(1, "Hello\n", 6);
>> return 0;
>> }
>>
>> takes about 20-22 ms. More realistically, compilation of a lead
>> C program (66 lines) and linking of several .o files (many
>> produced by a non-C compiler) + libc needs 23 ms producing
>> 66 kB executable (of which 20 kB is code and the rest is mainly
>> debug info). The same, but linking statically to libc needs 56 ms
>> and produces 550 kB executable (of which 413 kB is code).
>> Note: the last two are for Risc-V. That is compiler runs on my PC,
>> but executables only run on Risc-V machine. And actually
>> transferring the executable takes more time than C compilation.
>
> So, on your machine, what's the throughput of gcc in lines per second?
>
> I mean something more accurate than the 300lps of your 6-line example
> which will be mostly due to overheads.
Above you also have 66 line file. gcc compile time depends very
much on source file. One case is 647 lines (17 kB) file, strightforward
code without attempt to cram too much into each line. Plain 'gcc -Wall'
(so no optimization) needs 42 ms. This code is actually doing
possibly large work, so more realistic is 'gcc -O -Wall' which
needs 67 ms. 'gcc -O2 -Wall' takes 114 ms and 'gcc -O3 -Wall' takes
119 ms (but are unlikely to produce significant speedup). Another
case is 847 lines file (24 kB) including 669 line (44 kB) header with
macros and 22 line header declaring functions. This is heavily macroized
code which macroexpandd to about 900 kB. This code is performance
critical and benefits from vectorization, so normally it would be
compiled using 'gcc -O3 -c', which takes 10.2s. 'gcc -O2 -c' needs
8.2s, 'gcc -O -c' take 4.8s, 'gcc -c' takes '1.45s'.
First file gives you a bit more than 15000 lines per second without
optimization and about 9600 lines per second at '-O'. Second
gives you about 1000 lines per second without optimization and
about 148 at '-O3'. But lines coming from macros are compiled
multiple times and without using macros the file would be much
bigger. Considering size in characters after expansion non-macro
version probably would need 20000 lines.
> My compilers for Windows tend to work at up 0.5Mlps, and between 1-2
> magnitudes faster than gcc.
>
>
>> 150 ms is still not too long.
>
> I use Windows where it is 250ms (a bit lower now), and yet my own
> product works fine on it; this is my C compiler building sqlite3:
>
> c:\cx>tim bcc sql
> Compiling sql.c to sql.exe
> Time: 0.228
>
> And this is gcc 14 building hello.c:
>
> c:\cx>tim gcc hello.c
> Time: 0.203
>
> And gcc 10:
>
> c:\cx>tim \tdm10\bin\gcc hello.c
> Time: 0.244
>
> And clang:
>
> c:\cx>tim clang hello.c
> Time: 0.263
>
> Amazing isn't it that I can build a working SQL program in about the
> time it takes gcc/clang to build Hello, World! bcc is not even optimised.
Such compile speed is nice. Concerning "amazing", relative to
machine speed such compile speeds were available in the past. But
most of old language tools vanished and surviving ones got relatively
slower. Apparently, people care much more about speed and size of
resulting code than about compiler speed. Consider silly example,
but small enough to give it here in full (targeting Risc-V):
long f6(void) {
return 6;
}
'tcc -c' gives the following code (after disassembly):
0000000000000000 <f6>:
0: ff010113 add sp,sp,-16
4: 00113423 sd ra,8(sp)
8: 00813023 sd s0,0(sp)
c: 01010413 add s0,sp,16
10: 00000013 nop
14: 0060051b addw a0,zero,6
18: 00813083 ld ra,8(sp)
1c: 00013403 ld s0,0(sp)
20: 01010113 add sp,sp,16
24: 00008067 ret
that is 10 instructions, 40 bytes. 'gcc -c' (so no optimization)
gives:
0000000000000000 <f6>:
0: 1141 add sp,sp,-16
2: e422 sd s0,8(sp)
4: 0800 add s0,sp,16
6: 4799 li a5,6
8: 853e mv a0,a5
a: 6422 ld s0,8(sp)
c: 0141 add sp,sp,16
e: 8082 ret
so 8 instructions, 16 bytes. 'gcc -O -c' gives:
0000000000000000 <f6>:
0: 4519 li a0,6
2: 8082 ret
so 2 instructions, 4 bytes. One things is that apparently tcc does not
support Risc-V compressed instructions, which leads to considerably
bigger code. Another thing is that tcc inserts a 'nop' for no good
reason. And even without optimization gcc realizes that nothing
clobbers link register so avoids storing and restoring it. gcc
produces constant in "wrong" register, so has to move it, but in the
balance looks slightly better than tcc.
'gcc -O' clearly gives much better code, on low end machines it is
likely to be 5 times faster.
>> And large part of it is likely to
>> be gcc startup time, so you can make program larger whithout large
>> increase of compile time.
>
> Yes, it is big and slow and they haven't provided a fast path (like a
> secretly bundled version of tcc) when you need an instant, streamlined
> result.
>
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-07 06:28 +0000 |
| Message-ID | <11a4oph$2jpr4$2@dont-email.me> |
| In reply to | #402777 |
On Wed, 7 Oct 2026 04:19:45 -0000 (UTC), Waldek Hebisch wrote: > Concerning "amazing", relative to machine speed such compile speeds > were available in the past. But most of old language tools vanished > and surviving ones got relatively slower. The Linux kernel is currently up to about 38 million lines of code, last I heard. How long do you think it would take to compile all that? On a reasonably grunty machine, of course, but *without* resorting to a RAM disk? Would you believe, a little over two minutes? Down to 15 seconds for a build with some reasonable configuration choices? <https://www.tomshardware.com/software/linux/linux-enthusiasts-see-10-second-kernel-compilation-times-on-the-horizon-ai-assisted-patches-cut-build-times-by-nearly-a-third-without-a-ramdisk>
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 11:39 +0100 |
| Message-ID | <11a57ho$2pfdl$1@dont-email.me> |
| In reply to | #402781 |
On 07/10/2026 07:28, Lawrence D’Oliveiro wrote: > On Wed, 7 Oct 2026 04:19:45 -0000 (UTC), Waldek Hebisch wrote: > >> Concerning "amazing", relative to machine speed such compile speeds >> were available in the past. But most of old language tools vanished >> and surviving ones got relatively slower. > > The Linux kernel is currently up to about 38 million lines of code, > last I heard. How long do you think it would take to compile all that? > On a reasonably grunty machine, of course, but *without* resorting to > a RAM disk? On x64 that would equate to roughly a 400MB binary. That is quite a hefty 'kernel'! Or maybe only some of that code will be compiled for any particular target. I heard of a figure around 5% which would make it 2Mloc. I don't know if it still has to trawl through the other 95% to extract it, or it is organised more sensibly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 12:57 +0200 |
| Message-ID | <11a58ie$2osq7$1@dont-email.me> |
| In reply to | #402790 |
On 07/10/2026 12:39, bart wrote: > On 07/10/2026 07:28, Lawrence D’Oliveiro wrote: >> On Wed, 7 Oct 2026 04:19:45 -0000 (UTC), Waldek Hebisch wrote: >> >>> Concerning "amazing", relative to machine speed such compile speeds >>> were available in the past. But most of old language tools vanished >>> and surviving ones got relatively slower. >> >> The Linux kernel is currently up to about 38 million lines of code, >> last I heard. How long do you think it would take to compile all that? >> On a reasonably grunty machine, of course, but *without* resorting to >> a RAM disk? > > On x64 that would equate to roughly a 400MB binary. That is quite a > hefty 'kernel'! > > Or maybe only some of that code will be compiled for any particular > target. I heard of a figure around 5% which would make it 2Mloc. > The kernel on my system is about 15 MB. Sizes vary by version and build details, of course, but that's roughly the size. Some of the code in the kernel is target specific and therefore not used on most targets. But a very large proportion is typically compiled to modules rather than linked directly in the kernel, and many of the modules are not even built in most cases. I have no idea of the exact proportions. > I don't know if it still has to trawl through the other 95% to extract > it, or it is organised more sensibly. > It is organised sensibly.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 11:32 +0100 |
| Message-ID | <11a574n$2pano$1@dont-email.me> |
| In reply to | #402777 |
On 07/10/2026 05:19, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 07/10/2026 00:14, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>
>>>> What program can gcc compile in 10ms, Hello World?
>>>
>>> On my machine the following non-canonical version of Hello World:
>>>
>>> #include <unistd.h>
>>> int
>>> main(void) {
>>> write(1, "Hello\n", 6);
>>> return 0;
>>> }
>>>
>>> takes about 20-22 ms. More realistically, compilation of a lead
>>> C program (66 lines) and linking of several .o files (many
>>> produced by a non-C compiler) + libc needs 23 ms producing
>>> 66 kB executable (of which 20 kB is code and the rest is mainly
>>> debug info). The same, but linking statically to libc needs 56 ms
>>> and produces 550 kB executable (of which 413 kB is code).
>>> Note: the last two are for Risc-V. That is compiler runs on my PC,
>>> but executables only run on Risc-V machine. And actually
>>> transferring the executable takes more time than C compilation.
>>
>> So, on your machine, what's the throughput of gcc in lines per second?
>>
>> I mean something more accurate than the 300lps of your 6-line example
>> which will be mostly due to overheads.
>
> Above you also have 66 line file. gcc compile time depends very
> much on source file. One case is 647 lines (17 kB) file, strightforward
> code without attempt to cram too much into each line. Plain 'gcc -Wall'
> (so no optimization) needs 42 ms. This code is actually doing
> possibly large work,
What does that mean, work done at runtime? That shouldn't affect it. The
compiler will only see a bunch of tokens related to the size of the source.
so more realistic is 'gcc -O -Wall' which
> needs 67 ms. 'gcc -O2 -Wall' takes 114 ms and 'gcc -O3 -Wall' takes
> 119 ms (but are unlikely to produce significant speedup). Another
> case is 847 lines file (24 kB) including 669 line (44 kB) header with
> macros and 22 line header declaring functions. This is heavily macroized
> code which macroexpandd to about 900 kB.
Recent discussions about headers suggested even huge headers were a
non-issue, according to some here.
I have an example of a 32KB file that expands to 4MB after
preprocessing. Here is compile-speed:
Time EXE size
gcc -O0 16 secs 3.0 MB
gcc -O2 42 secs 1.5 MB
tcc 0.37 secs 3.6 MB
I'm not arguing against never using gcc or never using optimisations.
I'm saying that for my development patterns (compile 100s of times a
day), it is just too slow and unresponsive to use routinely.
It can be used from time to time for its static analysis/linting part,
where it can give opinions about your work. While optimisation may only
be needed for production code, or again every so often to test there
will be no problems.
But you might need optimising more often if the speed-up is significant,
and you rely on it (or it takes annoyingly long - longer than the extra
compile-time - to run your tests!).
>> c:\cx>tim bcc sql
>> Compiling sql.c to sql.exe
>> Time: 0.228
>> Amazing isn't it that I can build a working SQL program in about the
>> time it takes gcc/clang to build Hello, World! bcc is not even optimised.
>
> Such compile speed is nice. Concerning "amazing", relative to
> machine speed such compile speeds were available in the past. But
> most of old language tools vanished and surviving ones got relatively
> slower. Apparently, people care much more about speed and size of
> resulting code than about compiler speed.
This one of my points: they never seems to care about the speed of the
compiler!
> Consider silly example,
> but small enough to give it here in full (targeting Risc-V):
>
> long f6(void) {
> return 6;
> }
>
> 'tcc -c' gives the following code (after disassembly):
>
> 0000000000000000 <f6>:
> 0: ff010113 add sp,sp,-16
> 4: 00113423 sd ra,8(sp)
> 8: 00813023 sd s0,0(sp)
> c: 01010413 add s0,sp,16
> 10: 00000013 nop
> 14: 0060051b addw a0,zero,6
> 18: 00813083 ld ra,8(sp)
> 1c: 00013403 ld s0,0(sp)
> 20: 01010113 add sp,sp,16
> 24: 00008067 ret
>
> that is 10 instructions, 40 bytes. 'gcc -c' (so no optimization)
> gives:
>
> 0000000000000000 <f6>:
> 0: 1141 add sp,sp,-16
> 2: e422 sd s0,8(sp)
> 4: 0800 add s0,sp,16
> 6: 4799 li a5,6
> 8: 853e mv a0,a5
> a: 6422 ld s0,8(sp)
> c: 0141 add sp,sp,16
> e: 8082 ret
>
> so 8 instructions, 16 bytes. 'gcc -O -c' gives:
What does '-O' do? On my gcc it gives same results as -O0.
> 0000000000000000 <f6>:
> 0: 4519 li a0,6
> 2: 8082 ret
>
> so 2 instructions, 4 bytes.
My bcc product gives better code than tcc while nearly as fast
compiling. For your example, bcc generates this for x64:
f6:
mov eax, 6
ret
These are EXE sizes for Lua, for x64/WinABI
gcc -O0 465 KB
gcc -O2 414 KB
gcc -O3 466 KB
gcc -Os 328 KB
tcc 384 KB
bcc 237 KB
> One things is that apparently tcc does not
> support Risc-V compressed instructions, which leads to considerably
> bigger code. Another thing is that tcc inserts a 'nop' for no good
> reason. And even without optimization gcc realizes that nothing
> clobbers link register so avoids storing and restoring it. gcc
> produces constant in "wrong" register, so has to move it, but in the
> balance looks slightly better than tcc.
My point above is that you can do minor 'optimisations' (generating
sensible code, plus peep-hole stuff) with very little cost.
(My bcc product has an extra step, which allocates some locals to
registers. Plus a peep-hole optimiser stage which doesn't make it any
faster, but makes the code a little smaller.
This has zero-cost, so it is enabled by default. It is zero-cost because
the extra time to do it (only 10% anyway) if offset by having less code
to deal with in the later stages.
If I disable it, then lua.exe ends up at 289KB - still smaller than gcc.)
> 'gcc -O' clearly gives much better code, on low end machines it is
> likely to be 5 times faster.
If that means -O2 or -O3, then on my programs, it is more typically 2x
as fast, for C code. But more like 1.5 x as fast for the C code
transpiled from my language using my old transpiler, for language projects.
Current transpiled C is low level and may affect how well it can
optimise larger programs. But if applied to 'bcc sql', then timing
reduces to just below 0.2 seconds; about 15% faster.
>>> And large part of it is likely to
>>> be gcc startup time, so you can make program larger whithout large
>>> increase of compile time.
>>
>> Yes, it is big and slow and they haven't provided a fast path (like a
>> secretly bundled version of tcc) when you need an instant, streamlined
>> result.
>>
>>
>
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web