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 181 — 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 David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
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-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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-07 15:10 +0000 |
| Message-ID | <11a5nca$gg7c$1@paganini.bofh.team> |
| In reply to | #402789 |
bart <bc@freeuk.com> wrote:
> 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.
Yes.
> The
> compiler will only see a bunch of tokens related to the size of the source.
You want useful result, that is why '-O'.
> 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.
Normal headers, yes. To give you an idea what is involved let me show
small part of header and the file. From 'arrpack.h':
#define PROC1N(N1, N2, TYPE, OP, ARGS...) /* 1 array normal */ \
int N1 ## A ## N2(ARGS TYPE *arr, int *spec) \
{ \
int err, off, d, nd; \
int *wk, *wp, *sps, *sp; \
TYPE *arrend; \
\
if (err = arrspec(spec, 1, 1, &off, &d, &nd, &sps, &wk)) \
return err; \
arr += off; \
\
while (1) { \
/* dimension 1 expanded */ \
for (arrend = arr+nd; arr < arrend; arr += d) \
{ OP } \
for (sp=sps, wp=wk; ; ) { /* loop over dims 2...N */ \
if (sp == wk) return 0; \
arr += *sp++; \
if (++(*wp) == *sp++) \
*wp++ = 0; \
else \
break; \
} \
} \
}
...
#define PROC1(N1, N2, TYPE, OP, ARGS...) \
PROC1N(N1, N2, TYPE, OP, ARGS) \
PROC1M(N1, N2, TYPE, OP, ARGS) \
PROC1I(N1, N2, TYPE, OP, ARGS)
From 'arrpack.c':
#include <math.h>
#include "arrpack.h"
/*
-- Single array -------------------------------------------------------
*/
#define N2 zero
#define OP *arr = 0;
PROC1(b, N2, unsigned char, OP, )
PROC1(i, N2, int, OP, )
PROC1(s, N2, float, OP, )
PROC1(d, N2, double, OP, )
PROC1(c, N2, __complex__ float, OP, )
PROC1(z, N2, __complex__ double, OP, )
#undef OP
#undef N2
As you can see this creates 18 not so small functions.
> 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.
OK
>> 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.
I meant '-O'. In gcc '-O' means simpler and faster optimizations,
which almost always lead to faster code. '-O2' means havier
optimizations, and '-O3' even more heavy. Also, optimizations
at '-O2' or '-O3' level may backfire: transformation that is
intended to increase speed may actually decrease it.
On high-end machines CPU frequently is quite powerful, but execution
speed is limited by memory access. In such case executing say twice
as many instructions as needed costs only a little. But on low end
machines executing useless instructions cases significant slowdown.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 19:41 +0100 |
| Message-ID | <11a63og$34v73$1@dont-email.me> |
| In reply to | #402802 |
On 07/10/2026 16:10, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> What does that mean, work done at runtime? That shouldn't affect it.
>
> Yes.
>
>> The
>> compiler will only see a bunch of tokens related to the size of the source.
>
> You want useful result, that is why '-O'.
Apparently, -O means the same as -O1.
>> Recent discussions about headers suggested even huge headers were a
>> non-issue, according to some here.
>
> Normal headers, yes. To give you an idea what is involved let me show
> small part of header and the file. From 'arrpack.h':
>
> #define PROC1N(N1, N2, TYPE, OP, ARGS...) /* 1 array normal */ \
> int N1 ## A ## N2(ARGS TYPE *arr, int *spec) \
> { \
...> }
> ...
> #define PROC1(N1, N2, TYPE, OP, ARGS...) \
> PROC1N(N1, N2, TYPE, OP, ARGS) \
> PROC1M(N1, N2, TYPE, OP, ARGS) \
> PROC1I(N1, N2, TYPE, OP, ARGS)
...> PROC1(b, N2, unsigned char, OP, )
> PROC1(i, N2, int, OP, )
> PROC1(s, N2, float, OP, )
> PROC1(d, N2, double, OP, )
> PROC1(c, N2, __complex__ float, OP, )
> PROC1(z, N2, __complex__ double, OP, )
> #undef OP
> #undef N2
>
> As you can see this creates 18 not so small functions.
...
This generates about 5KB of code when expanded. You say the full version
is nearly 1MB? So what is the problem: generating that 1MB, or having to
process it?
It's roughly 30Kloc so if it is processing all that code, then it would
be the same problem as dealing with those big headers. Less in fact
since presumably it is only processed once if it contain function defs.
>> gcc -O0 465 KB
>> gcc -O1 348 KB>> gcc -O2 414 KB
>> gcc -O3 466 KB
>> gcc -Os 328 KB
>> 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.
>
> I meant '-O'. In gcc '-O' means simpler and faster optimizations,
> which almost always lead to faster code. '-O2' means havier
> optimizations, and '-O3' even more heavy. Also, optimizations
> at '-O2' or '-O3' level may backfire: transformation that is
> intended to increase speed may actually decrease it.
OK, I've added -O1 to my table.
I rarely use it, because if I'm using gcc for its optimisations, then I
might as well get the best. In this case, Lua working on a Fibonacci
test gives these results:
gcc -O0 9.4 seconds
gcc -O1 3.1 seconds
gcc -O2 2.9 seconds
bcc 6.6 seconds
('bcc' is poor here partly because of how this project is written: full
of deeply nested macros and function calls. This seems to be typical of
interpreters written in C.
My own interpreter, written in plain code and running the same
benchmark, takes 1.2 seconds.)
> On high-end machines CPU frequently is quite powerful, but execution
> speed is limited by memory access. In such case executing say twice
> as many instructions as needed costs only a little. But on low end
> machines executing useless instructions cases significant slowdown.
>
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-08 04:49 +0000 |
| Message-ID | <11a77cs$odht$1@paganini.bofh.team> |
| In reply to | #402803 |
bart <bc@freeuk.com> wrote:
> On 07/10/2026 16:10, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>
>>> What does that mean, work done at runtime? That shouldn't affect it.
>>
>> Yes.
>>
>>> The
>>> compiler will only see a bunch of tokens related to the size of the source.
>>
>> You want useful result, that is why '-O'.
>
> Apparently, -O means the same as -O1.
>
>>> Recent discussions about headers suggested even huge headers were a
>>> non-issue, according to some here.
>>
>> Normal headers, yes. To give you an idea what is involved let me show
>> small part of header and the file. From 'arrpack.h':
>>
>> #define PROC1N(N1, N2, TYPE, OP, ARGS...) /* 1 array normal */ \
>> int N1 ## A ## N2(ARGS TYPE *arr, int *spec) \
>> { \
> ...> }
>> ...
>> #define PROC1(N1, N2, TYPE, OP, ARGS...) \
>> PROC1N(N1, N2, TYPE, OP, ARGS) \
>> PROC1M(N1, N2, TYPE, OP, ARGS) \
>> PROC1I(N1, N2, TYPE, OP, ARGS)
> ...> PROC1(b, N2, unsigned char, OP, )
>> PROC1(i, N2, int, OP, )
>> PROC1(s, N2, float, OP, )
>> PROC1(d, N2, double, OP, )
>> PROC1(c, N2, __complex__ float, OP, )
>> PROC1(z, N2, __complex__ double, OP, )
>> #undef OP
>> #undef N2
>>
>> As you can see this creates 18 not so small functions.
> ...
>
> This generates about 5KB of code when expanded. You say the full version
> is nearly 1MB? So what is the problem: generating that 1MB, or having to
> process it?
Macro expansion is pretty fast. It is production of machine code that
takes time.
> It's roughly 30Kloc so if it is processing all that code, then it would
> be the same problem as dealing with those big headers. Less in fact
> since presumably it is only processed once if it contain function defs.
Sorry, you do not get it. Normal headers consist of declarations.
gcc is reasonable fast at parsing and handling declarations. But
above you have actual executable code and translating it to
machine code takes time.
>>> gcc -O0 465 KB
>>> gcc -O1 348 KB>> gcc -O2 414 KB
>>> gcc -O3 466 KB
>>> gcc -Os 328 KB
>
>>> 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.
>>
>> I meant '-O'. In gcc '-O' means simpler and faster optimizations,
>> which almost always lead to faster code. '-O2' means havier
>> optimizations, and '-O3' even more heavy. Also, optimizations
>> at '-O2' or '-O3' level may backfire: transformation that is
>> intended to increase speed may actually decrease it.
>
> OK, I've added -O1 to my table.
>
> I rarely use it, because if I'm using gcc for its optimisations, then I
> might as well get the best.
Sometimes '-O' is the best. Not frequently, but it happens.
> In this case, Lua working on a Fibonacci
> test gives these results:
>
> gcc -O0 9.4 seconds
> gcc -O1 3.1 seconds
> gcc -O2 2.9 seconds
> bcc 6.6 seconds
>
> ('bcc' is poor here partly because of how this project is written: full
> of deeply nested macros and function calls. This seems to be typical of
> interpreters written in C.
The question frequently is "who is doing optimization?". Original
C design was to have programmer do most optimization and use
relatively dumb compiler. But is is easier to write the code
assuming aggressive compiler optimization. Basically, you write
rather general code, which always works, but is specific cases
when translated anively performs useless operations. In the past
programmer would specialize such code by hand, leaving only what is
needed in each case. But now compiler optimizations can do most
of this work.
> My own interpreter, written in plain code and running the same
> benchmark, takes 1.2 seconds.)
Lua interpreter is recognized as rather slow. But you frequently
compare apples with oranges. People use interpreted languages
either for safety, that is runtime checks or for fancy language features
or both. Correct program will run fine and get significant speedup
when you remove safety checks, but during developement program is
rarely correct and safety checks are essential. Some language
features slow down all programs in given language, even ones that
do not use the feature. But usually programmes do not want to
deal with multiple languages and stick to one that has all
features that they need. So really, comparing interpreters for
different languages have limited use.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-08 12:24 +0100 |
| Message-ID | <11a7uhp$3p2ve$1@dont-email.me> |
| In reply to | #402824 |
On 08/10/2026 05:49, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> This generates about 5KB of code when expanded. You say the full version
>> is nearly 1MB? So what is the problem: generating that 1MB, or having to
>> process it?
>
> Macro expansion is pretty fast. It is production of machine code that
> takes time.
>
>> It's roughly 30Kloc so if it is processing all that code, then it would
>> be the same problem as dealing with those big headers. Less in fact
>> since presumably it is only processed once if it contain function defs.
>
> Sorry, you do not get it. Normal headers consist of declarations.
> gcc is reasonable fast at parsing and handling declarations. But
> above you have actual executable code and translating it to
> machine code takes time.
If I understand your point, it is that LPS throughput for C can be
problematic because source code can be a mix of executable code,
unexpanded macro invocations and declarations?
When producing benchmark figures, you try to avoid extreme cases of
excessive macro use and disproportionately large headers even containing
only declarations.
Such figures can still be useful when building fairly sane code-bases
with normal-sized headers and moderate use of macros.
Your example that expands to nearly 1MB, generates long expansions with
few line-breaks, so line-count is tricky anyway.
Now here I assumed the 42ms -O0 figure was for this program. But at an
average density of 20 or so characters/line, that would equate to around
a million lines per second throughput!
So I had to go back a few posts to read it more carefully. This program
takes 1.45s at -O0, so roughly 30Klps at that code density.
This is not bad for gcc.
>> ('bcc' is poor here partly because of how this project is written: full
>> of deeply nested macros and function calls. This seems to be typical of
>> interpreters written in C.
>
> The question frequently is "who is doing optimization?". Original
> C design was to have programmer do most optimization and use
> relatively dumb compiler. But is is easier to write the code
> assuming aggressive compiler optimization. Basically, you write
> rather general code, which always works, but is specific cases
> when translated anively performs useless operations. In the past
> programmer would specialize such code by hand, leaving only what is
> needed in each case. But now compiler optimizations can do most
> of this work.
My problem is that gcc/clang are slow even at -O0! So the question is
why, and could something have been done about that.
People here may say that even -O0 is doing static analysis etc. But
suppose you don't want that. My guess is the infrastructure needed to
enable optimisations gets in the way even for -O0.
>> My own interpreter, written in plain code and running the same
>> benchmark, takes 1.2 seconds.)
>
> Lua interpreter is recognized as rather slow.
Not any more. Lua 5.5 is quite nifty, and can match or beat my
interpreter on some tests, although not for Fibonacci!
> But you frequently
> compare apples with oranges.
I compare my pure interpreter for a dynamically typed language with some
one else's interpreter for their dynamically typed language, on a
program running the same algorithm.
Mine usually has the edge, even though it does everything wrong. Lua has
a small number of built-in types only; it uses a compact, tagged 64-bit
value for all objects; it uses an efficient register based VM.
I have a lot more types plus user-defined ones. I use a complex 128-bit
descriptor. I use a stack-based VM. Plus I use an interpreter that is
unoptimised code!
So, why am I still fast? Maybe this is a clue; in lua.c there is this
line (may be part of a switch, but you can't tell):
vmcase(OP_ADDK) {
op_arithK(L, l_addi, luai_numadd);
vmbreak;
}
That op_arithK() is actually a macro invocation that expands to this:
{TValue*v1=(&((base+(((void)0),((((int)((((i)>>((((0+7)+8)+1)))&(
(~((~(Instruction)0)<<(8)))<<(0))))))))))->val);TValue*v2=(k+(((void)
0),((((int)((((i)>>(((((0+7)+8)+1)+8)))&((~((~(Instruction)0)<<(8)))<<
(0)))))))));((void)0);{StkId ra=(base+(((int)((((i)>>((0+7)))&((~((~
(Instruction)0)<<(8)))<<(0)))))));if(((((v1))->tt_)==(((3)|((0)<<4))))
&&((((v2))->tt_)==(((3)|((0)<<4))))){lua_Integer i1=(((void)0),(((v1)
->value_).i));lua_Integer i2=(((void)0),(((v2)->value_).i));pc++;{
TValue*io=((&(ra)->val));((io)->value_).i=(((lua_Integer)(((
lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));((io)->tt_=(((3)|((0)<<4)))
);};}else{lua_Number n1;lua_Number n2;if((((((v1))->tt_)==(((3)|((1)
<<4))))?((n1)=(((void)0),(((v1)->value_).n)),1):(((((v1))->tt_)==(((3)
|((0)<<4))))?((n1)=((lua_Number)(((((void)0),(((v1)->value_).i))))),1)
:0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?((n2)=(((void)0),(((v2)->
value_).n)),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=((lua_Number)
(((((void)0),(((v2)->value_).i))))),1):0))){pc++;{TValue*io=((&(ra)->
val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|((1)<<4))));};
}};};};
(I'm familiar with this as I had to debug my compiler on it.)
Here, my guess is it's relying on the compiler to clean up the mess.
While my equivalent is plain code.
(Note that in Lua 5.5, 'ADD' I believe is only defined for INT and FLOAT
types; it used to be just FLOAT. I have 'ADD' defined for 5 types.)
> People use interpreted languages
> either for safety, that is runtime checks or for fancy language features
> or both.
People use such languages because they are easier to use, they can be
more productive, and there is no annoying build-step.
(No static analysis either, and no warnings; how is that possible?)
Some may use them for prototyping or development before porting to a
compiled language.
> So really, comparing interpreters for
> different languages have limited use.
If you say so. But it sounds to me like making excuses for a slow product.
Endless efforts have been made over the last two decades in making
scripting languages run fast. Apart from approaches using type inference
or tracing-JIT, this also applies to pure interpreters.
Part of that involves benchmarking.
So can certainly compare language implementations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 09:07 +0200 |
| Message-ID | <11a4r3i$2k7oa$1@dont-email.me> |
| In reply to | #402774 |
On 07/10/2026 02:25, bart 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.
>
> My compilers for Windows tend to work at up 0.5Mlps, and between 1-2
> magnitudes faster than gcc.
>
I can't answer for other people, but when I write code, usually there is
a fair amount of difference between different lines. The time taken for
a compilation depends on the code!
You can do all the speed measurements you like using files made from
thousands of copies of the same pointless function. It means /nothing/.
"Lines per second" is a good way to rate machines for painting dashed
lines down the middle of a road - not a way to judge a compiler.
Your tools are useless to everyone except you. No one cares if they are
a million times faster at being useless, people need tools that do
something useful to them.
So for the love of $DEITY, give it a break! You write plenty of
interesting posts - your addiction to milliseconds is not part of that.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-07 11:49 +0100 |
| Message-ID | <11a583p$2pmng$1@dont-email.me> |
| In reply to | #402784 |
On 07/10/2026 08:07, David Brown wrote:
> On 07/10/2026 02:25, bart 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.
>>
>> My compilers for Windows tend to work at up 0.5Mlps, and between 1-2
>> magnitudes faster than gcc.
>>
> I can't answer for other people, but when I write code, usually there is
> a fair amount of difference between different lines. The time taken for
> a compilation depends on the code!
>
> You can do all the speed measurements you like using files made from
> thousands of copies of the same pointless function. It means /nothing/.
I've given examples for real code.
But yes synthesised benchmarks can be used to spot bottlenecks. Maybe
other compiler developers can give it a go!
> "Lines per second" is a good way to rate machines for painting dashed
> lines down the middle of a road - not a way to judge a compiler.
>
> Your tools are useless to everyone except you. No one cares if they are
> a million times faster at being useless, people need tools that do
> something useful to them.
> So for the love of $DEITY, give it a break! You write plenty of
> interesting posts - your addiction to milliseconds is not part of that.
It is annoying though that no one wants to acknowledge that gcc IS slow.
I've given examples where you just want a compiler to do a mechanical
translation from source code to binary, just like you might translate
assembly to binary.
You DON'T CARE about detailed analysis. You might not even care about
the code quality for any number of reasons.
gcc does not give you an option where it is suddenly 10 or 20 times
faster (and it uses a fraction of the memory). We need -O-1 or -O-2.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 13:11 +0200 |
| Message-ID | <11a59d8$2osq7$2@dont-email.me> |
| In reply to | #402791 |
On 07/10/2026 12:49, bart wrote: > On 07/10/2026 08:07, David Brown wrote: >> So for the love of $DEITY, give it a break! You write plenty of >> interesting posts - your addiction to milliseconds is not part of that. > It is annoying though that no one wants to acknowledge that gcc IS slow. > People /do/ understand that gcc takes time, and people /would/ prefer if it did the same job, faster. What seems to totally pass you by is that there is a difference between "slow" and "too slow". No one is happy if there builds take 10 minutes. Equally, no one cares if their builds take 1 second or 0.1 seconds. If I have to compile 20 files, and each takes 1 second to compile, it would be annoying to do them one at a time - but if they all compile in parallel, it takes just 1 second of my time. No one - but you - is bothered as long as real-life compile times are fast enough that they don't get in the way of development. Your tools are useless to me - they could just as easily be "cat file.c > /dev/null". Your other favourite toy compilers, like tcc, are equally useless. Since they are useless, they are not applicable in a speed comparison. When I compare compile times with /real/ tools - things that do good optimisations and good static checking, with support for modern language standards and the extensions I want, and target the devices I need - I have no reason to call gcc "slow". clang, or Green Hills, or Metrowerks, or Keil might be a bit faster in some cases, maybe a bit slower in other cases, but I have not seen significant differences. So I will not call gcc "slow" until I see another tool that does approximately as good a job for my needs, and does so several times faster than gcc. And I will not call gcc "too slow" unless I find its speed a problem or inconvenience. Of course I will always be happier if gcc gets faster, but that is not the same as thinking it is slow. I am glad that the GCC developers put their limited time and resources into other things than the speed of compilation of C code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 16:17 +0200 |
| Message-ID | <11a2vtg$1vq6t$1@dont-email.me> |
| In reply to | #402745 |
On 06/10/2026 13:33, Richard Harnden wrote: > On 06/10/2026 11:41, David Brown wrote: >> On 06/10/2026 11:12, Janis Papanagnou 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. With my current program, most builds are done within a couple of seconds, but it takes the program around 30 seconds to get running on the microcontroller (it has to establish connection on an usual type of network). Full testing takes a /lot/ longer. Compiler warnings certainly don't catch all my bugs, but when they do, they save a great deal of time - far more than a faster compile would. > > Also, I need to drink my tea at some point. > What kind of software developer drinks tea? Surely you mean black coffee or Jolt Cola ? :-)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-06 15:32 +0100 |
| Message-ID | <11a30pg$20vrv$1@dont-email.me> |
| In reply to | #402749 |
On 06/10/2026 15:17, David Brown wrote: > On 06/10/2026 13:33, Richard Harnden wrote: >> On 06/10/2026 11:41, David Brown wrote: >>> On 06/10/2026 11:12, Janis Papanagnou 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. > > With my current program, most builds are done within a couple of > seconds, but it takes the program around 30 seconds to get running on > the microcontroller (it has to establish connection on an usual type of > network). Full testing takes a /lot/ longer. Compiler warnings > certainly don't catch all my bugs, but when they do, they save a great > deal of time - far more than a faster compile would. If you add up how much red traffic lights slow down your overall journey time, then it probably is not significant. Yet everybody hates them and nobody likes having to stop. With languages, people like using scripting languages because there's no annoying build step. But here you can also make the argument that getting to a certain test point can take some time. That doesn't mean being tolerant of unnecessarily slow steps: if your text editor took 5 seconds to start, that would be annoying, yes? Because you know it shouldn't take that long.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 17:25 +0200 |
| Message-ID | <11a33tt$218om$2@dont-email.me> |
| In reply to | #402750 |
On 06/10/2026 16:32, bart wrote: > On 06/10/2026 15:17, David Brown wrote: >> On 06/10/2026 13:33, Richard Harnden wrote: >>> On 06/10/2026 11:41, David Brown wrote: >>>> On 06/10/2026 11:12, Janis Papanagnou 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. >> >> With my current program, most builds are done within a couple of >> seconds, but it takes the program around 30 seconds to get running on >> the microcontroller (it has to establish connection on an usual type >> of network). Full testing takes a /lot/ longer. Compiler warnings >> certainly don't catch all my bugs, but when they do, they save a great >> deal of time - far more than a faster compile would. > > If you add up how much red traffic lights slow down your overall journey > time, then it probably is not significant. > > Yet everybody hates them and nobody likes having to stop. You are one person. You are not "everybody". There is only one person who posts regularly in comp.lang.c that apparently hates C, hates all real C compiler, hates any compile times longer than a fraction of a second, and hates anything that other people do to be more productive in their programming. It's hard to fathom. > > With languages, people like using scripting languages because there's no > annoying build step. But here you can also make the argument that > getting to a certain test point can take some time. > > That doesn't mean being tolerant of unnecessarily slow steps: if your > text editor took 5 seconds to start, that would be annoying, yes? > Because you know it shouldn't take that long. > I couldn't give a damn if my main text editor took 5 seconds to start. Most of my work is within an IDE that takes at least twice that long to start. I last started that IDE almost exactly two months ago - why should I bother about 5 or 10 seconds? If it had a 5 second delay for every line I typed, that would be a different matter entirely. Time delays matter when they matter - and that depends on what you are doing, and how you use the tools, not on some meaningless and arbitrary idea about how long things "should" take.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-06 14:39 +0000 |
| Message-ID | <jK7xS.907$aNSb.817@fx20.iad> |
| In reply to | #402749 |
David Brown <david.brown@hesbynett.no> writes: >On 06/10/2026 13:33, Richard Harnden wrote: >> On 06/10/2026 11:41, David Brown wrote: >>> On 06/10/2026 11:12, Janis Papanagnou 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. > >With my current program, most builds are done within a couple of >seconds, but it takes the program around 30 seconds to get running on >the microcontroller (it has to establish connection on an usual type of >network). Full testing takes a /lot/ longer. Compiler warnings >certainly don't catch all my bugs, but when they do, they save a great >deal of time - far more than a faster compile would. > >> >> Also, I need to drink my tea at some point. >> > >What kind of software developer drinks tea? Surely you mean black >coffee or Jolt Cola ? :-) Yuck. Give me a good mug of Earl Grey any day. (That said, in my younger years it was Cherry Coke - something that wasn't the healthiest choice).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-06 19:48 +0200 |
| Message-ID | <11a3c9j$ef4n$3@dont-email.me> |
| In reply to | #402752 |
On 2026-10-06 16:39, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 06/10/2026 13:33, Richard Harnden wrote: >>> >>> Also, I need to drink my tea at some point. I wouldn't say No to a cup of freshly brewed Darjeeling. But during programming it typically just gets cold. :-/ >> What kind of software developer drinks tea? Surely you mean black >> coffee or Jolt Cola ? :-) What's that latter thing? - <look up> - Oh. - Nah! - There's just one "Real Coke". ;-) Black coffee is a good substitute if you have nothing better. - But there's nothing like a Greek Mocha! > Yuck. Give me a good mug of Earl Grey any day. (That said, > in my younger years it was Cherry Coke - something that wasn't > the healthiest choice). Darn, what kind of place is this? :-} Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-10-06 18:12 +0000 |
| Message-ID | <9SaxS.150695$_oJb.17106@fx46.iad> |
| In reply to | #402759 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-10-06 16:39, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 06/10/2026 13:33, Richard Harnden wrote: >>>> >>>> Also, I need to drink my tea at some point. > >I wouldn't say No to a cup of freshly brewed Darjeeling. >But during programming it typically just gets cold. :-/ > >>> What kind of software developer drinks tea? Surely you mean black >>> coffee or Jolt Cola ? :-) > >What's that latter thing? - <look up> - Oh. - Nah! - >There's just one "Real Coke". ;-) > >Black coffee is a good substitute if you have nothing >better. - But there's nothing like a Greek Mocha! > >> Yuck. Give me a good mug of Earl Grey any day. (That said, >> in my younger years it was Cherry Coke - something that wasn't >> the healthiest choice). > >Darn, what kind of place is this? :-} My professional career started with a move to the San Gabriel valley in the early 80s. There were plenty of substances widely available to keep one alert and active for considerable periods of time.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-06 21:50 +0200 |
| Subject | [OT] substances (was Re: Taming The Switch-Statement) |
| Message-ID | <11a3jdh$ef4o$5@dont-email.me> |
| In reply to | #402760 |
On 2026-10-06 20:12, Scott Lurndal wrote: > > My professional career started with a move to the > San Gabriel valley in the early 80s. There were plenty > of substances widely available to keep one alert and active > for considerable periods of time. A former colleague reported that some Sherpa in the Andes offered them Coca leafs to better manage the constitution and reduced-air-condition issues in the high mountains. For programming a well rested corporal and mental state is preferable to any substances, IMO. My Greek Mocha is of course just a cultural thing... ;-} Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-06 17:06 -0700 |
| Message-ID | <11a42dc$2dppj$1@dont-email.me> |
| In reply to | #402760 |
On 10/6/2026 11:12 AM, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-10-06 16:39, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 06/10/2026 13:33, Richard Harnden wrote: >>>>> >>>>> Also, I need to drink my tea at some point. >> >> I wouldn't say No to a cup of freshly brewed Darjeeling. >> But during programming it typically just gets cold. :-/ >> >>>> What kind of software developer drinks tea? Surely you mean black >>>> coffee or Jolt Cola ? :-) >> >> What's that latter thing? - <look up> - Oh. - Nah! - >> There's just one "Real Coke". ;-) >> >> Black coffee is a good substitute if you have nothing >> better. - But there's nothing like a Greek Mocha! >> >>> Yuck. Give me a good mug of Earl Grey any day. (That said, >>> in my younger years it was Cherry Coke - something that wasn't >>> the healthiest choice). >> >> Darn, what kind of place is this? :-} > > My professional career started with a move to the > San Gabriel valley in the early 80s. There were plenty > of substances widely available to keep one alert and active > for considerable periods of time. Just make sure the brain coolants do not destroy the brain over time?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-06 19:25 +0200 |
| Message-ID | <11a3ati$ef4o$3@dont-email.me> |
| In reply to | #402741 |
On 2026-10-06 12:41, David Brown wrote: > On 06/10/2026 11:12, Janis Papanagnou wrote: >> >> 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. Well, to me, that doesn't sound right. - Of course, "everyone makes mistakes", that's inherently a human "proficiency"! But the amount and degree of mistakes very much depends on experience (and, as mentioned, also depending on the used language). If "everyone" (independently of these factors) would see more warnings than sensible for his background it would not only distract him but likely he'd missed the warnings that would be actually useful for the given individual. - Reminds me the masses of [OK] buttons on WinDOS systems (or Android software, e.g.) you have to confirm before doing some trivial actions; and if a detail of the precondition changes you confirmed something you didn't intend. (But I seem to recall you had in some previous post also acknowledged the individuality of the warning settings. - I may be misremembering.) > > 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. It might be that we have different situations in mind. - Just take the two of the recently discussed examples, fall-through and shadowing, for example; if I'm using fall-through deliberately I certainly don't want to see a distracting warning, or someone who thinks that shadowing is an oversight in language design (as opposed to a deliberate sensible design as consequence of block-structures and scope) I certainly don't want to see that. But I think that's easy to solve. In private, individual contexts folks can (and should) activate what serves best. (Maybe with full-warnings if a person is a completely inexperienced programmer with a language.) In professional contexts it's a bit different. You'd certainly annoy professionals if they see many unfitting and just distracting warnings. Build-settings (including warnings) are usually defined and provided, and processes and QA methods and instances add another stage of safety. > 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. Fair enough. > > 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.) That's all fine. > > 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. No, that comparison isn't appropriate. (See above.) Programmers gain that they (only!) see what is actually a problem in the context of their staff (or individual), their language, and other project related factors that affect the software production. IME, too many warnings is as bad as a suppress all warnings setting. >>> >>> "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. Oh, it appeared familiar to me (but I've probably forgot the source); it's still a very nice quote. (And very fitting given some discussions here.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 10:28 +0200 |
| Message-ID | <11a4vqr$2m3b2$1@dont-email.me> |
| In reply to | #402758 |
On 06/10/2026 19:25, Janis Papanagnou wrote:
> On 2026-10-06 12:41, David Brown wrote:
>> On 06/10/2026 11:12, Janis Papanagnou wrote:
>>>
>>> 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.
>
> Well, to me, that doesn't sound right. - Of course, "everyone makes
> mistakes", that's inherently a human "proficiency"! But the amount and
> degree of mistakes very much depends on experience (and, as mentioned,
> also depending on the used language). If "everyone" (independently of
> these factors) would see more warnings than sensible for his background
> it would not only distract him but likely he'd missed the warnings that
> would be actually useful for the given individual. - Reminds me the
> masses of [OK] buttons on WinDOS systems (or Android software, e.g.)
> you have to confirm before doing some trivial actions; and if a detail
> of the precondition changes you confirmed something you didn't intend.
> (But I seem to recall you had in some previous post also acknowledged
> the individuality of the warning settings. - I may be misremembering.)
>
Yes, I made a point about tuning warnings to the needs of the project
and your personal style. As a simple example, if I am targeting a
microcontroller with hardware support for single-precision floating
point, but not double-precision, I will have "-Wdouble-promotion"
enabled. On a target with hardware doubles, I would not use that.
If you are getting lots of warnings, you are doing something wrong.
Either you have a warning enabled that clashes with the style of the
code, and you will likely want to disable the warning, or you have lots
of potential issues in your code and should take a long, hard look at
the code.
But just because you are an experienced C programmer, and "-Wformat"
rarely triggers with your code, does not mean it is a good idea to then
disable the warning! Leave it on. If your code doesn't have printf
format errors, it costs nothing - and if you one day make a mistake, you
get the warning.
The standard for most development, IME, is that completed programs
should build without warnings being generated. But that is not because
the warnings are swept under the carpet by disabling them because the
developer considers himself / herself an expert!
>>
>> 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.
>
> It might be that we have different situations in mind. - Just take the
> two of the recently discussed examples, fall-through and shadowing, for
> example; if I'm using fall-through deliberately I certainly don't want
> to see a distracting warning, or someone who thinks that shadowing is
> an oversight in language design (as opposed to a deliberate sensible
> design as consequence of block-structures and scope) I certainly don't
> want to see that.
Let me answer these two example cases, for demonstrative purposes.
switch (a) {
case 1 :
do_something();
case 2 :
do_something_more();
break;
case 3:
do_something_else;
}
switch (b) {
case 1 :
do_something();
// fallthrough
case 2 :
do_something_more();
break;
case 3:
do_something_else;
}
Which of these would you say is the better code - switch (a) or switch
(b) - which both do exactly the same thing?
That's a rhetorical question - obviously the version the version that
makes it clear to readers that the fall-through is intentional is
better. (For C23, "[[fallthrough]];" is an alternative to the comment.)
So use -Wimplicit-fallthrough, write your code clearly so that
intentional fall-throughs are obvious, and let your compiler help when
you get things wrong.
The next one is shadowing. That's an example of a warning that is more
a matter of personal style. Use "-Wshadow" (or "-Wshadow=global") if
you want to avoid any kind of shadowing. Use "-Wshadow=local" if you
don't mind shadowing "global" identifiers, but want to avoid local
variables shadowing each other. Don't enable "-Wshadow" if you
regularly shadow identifiers.
If you want a warning on normally, but have particular reason to need an
exception, use pragma push/pop :
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wshadow"
int i; // Intentionally shadow another i
#pragma GCC diagnostic pop
This is ugly, but it stands out as clearly doing something unusual. I
use it occasionally.
Or maybe you have a habit of "constifying" your loop variables. You
like to write :
for (int i = 0; i < 10; i++) {
const int _i = i;
const int i = _i;
...
}
so that inside your loop, the variable is "const" - that would catch any
mistakes you make that accidentally changed the loop variable inside the
loop. Clearly you don't want to write those #pragmas for every loop!
You can use macros:
#define Shadow(...) \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wshadow\"") \
__VA_ARGS__ \
_Pragma("GCC diagnostic pop")
#define Constify(x) \
Shadow(auto const _x = x;) \
Shadow(auto const x = _x;)
Now you have :
for (int i = 0; i < 10; i++) {
Constify(i);
...
}
I am not saying that I am recommending this particular practice - I am
merely showing how many warnings can be on in general while you also
have the flexibility to bypass them at times.
>
> But I think that's easy to solve. In private, individual contexts folks
> can (and should) activate what serves best. (Maybe with full-warnings
> if a person is a completely inexperienced programmer with a language.)
>
There are, I think, almost no circumstances in which you would want
/all/ warnings supported by good compilers. "-Wall" in gcc does not
mean all warnings - at least, not for a very long time. I view it more
like "all compilations should use -Wall". It is intended that the
warnings in "-Wall" suit a wide range of uses, with few false positives
in real code. Some of the "-Wextra" warnings are more divisive, though
I personally would like to see "-Wuninitialized" and
"-Wimplicit-fallthrough" in "-Wall". I'd also like to see "-Wall"
enabled by default, but that's not going to happen :-(
The point is, there is no downside to enabling a warning that never
triggers because you don't code that way. And for many warnings that
might be triggered despite the code being correct, there is no downside
in writing code in a clearer manner that avoids triggering the warning
(like adding comments for implicit fall-throughs).
But you are not going to want /all/ warnings. You are not going to want
"-Wc90-c99-compat" when you are writing modern C code! "-Wall", and
possibly also "-Wextra", give you a good starting point - fine tune
after that, enabling other options and perhaps disabling some of the
"-Wall" or "-Wextra" ones.
> In professional contexts it's a bit different. You'd certainly annoy
> professionals if they see many unfitting and just distracting warnings.
> Build-settings (including warnings) are usually defined and provided,
> and processes and QA methods and instances add another stage of safety.
>
If your builds produce warnings during normal builds, either you have
written something wrong (or at least questionable) in your code and the
warnings are doing their job, or you have a mismatch between coding
styles and habits, and choice of warning flags. Warning-free builds
does not mean the code is correct - but they are an extremely cheap and
easy-to-use way to catch many kinds of mistakes early on. A
professional development process that does not make use of an extensive
array of warnings (-Wall at a bare minimum) is failing its developers, IMHO.
>> 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.
>
> Fair enough.
>
>>
>> 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.)
>
> That's all fine.
>
>>
>> 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.
>
> No, that comparison isn't appropriate. (See above.)
>
> Programmers gain that they (only!) see what is actually a problem in
> the context of their staff (or individual), their language, and other
> project related factors that affect the software production.
>
> IME, too many warnings is as bad as a suppress all warnings setting.
>
If you can't run your builds with "-Werrors", you are doing things
wrong. Your code is not ready to check-in until is is warning-free.
But you don't achieve that by hiding the issues - you do it primarily by
solving the issues, writing better or clearer code. If a warning
conflicts with common practice in your style of code, then you disable
that particular warning - you don't disable others.
>>>>
>>>> "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.
>
> Oh, it appeared familiar to me (but I've probably forgot the source);
> it's still a very nice quote. (And very fitting given some discussions
> here.)
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-07 15:16 +0200 |
| Message-ID | <11a5gn2$2fkbe$2@dont-email.me> |
| In reply to | #402786 |
On 2026-10-07 10:28, David Brown wrote:
> On 06/10/2026 19:25, Janis Papanagnou wrote:
>> [...]
> [...]
>
> If you are getting lots of warnings, you are doing something wrong.
I don't think this is generally true. (I mentioned already that it
depends on a couple factors.)
(I snip your subsequent explanations because what you intended to
point out in that respect had been clear already.)
> [...]
>
> The standard for most development, IME, is that completed programs
> should build without warnings being generated.
Yes. That had always been our line in our commercial development.
(The build-settings were centralized, though, and far from all
warnings had been activated; the annoyances and problems with of
many unnecessary "hints" were seriously considered. Another poster
here named the negative effect (that I already explained) before as
“confirmation fatigue”. I think we shouldn't underestimate that.)
And individual programmers have not directly created the delivered
programs, though; there were quite some more stages in the process.
A zero-warnings policy is also a landmark in my private context.
But that doesn't mean that I'd activate a full-warnings setting
and go to study all what the diagnostics think might be a problem.
(It may, what I suspected, be a personal thing, based on factors
already mentioned.)
> But that is not because
> the warnings are swept under the carpet by disabling them because the
> developer considers himself / herself an expert!
Personal self-valuation was neither the topic nor helpful in real
situations (professional or private). - We should dismiss that idea.
>
>>>
>>> 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.
>>
>> It might be that we have different situations in mind. - Just take the
>> two of the recently discussed examples, fall-through and shadowing, for
>> example; if I'm using fall-through deliberately I certainly don't want
>> to see a distracting warning, or someone who thinks that shadowing is
>> an oversight in language design (as opposed to a deliberate sensible
>> design as consequence of block-structures and scope) I certainly don't
>> want to see that.
>
> Let me answer these two example cases, for demonstrative purposes.
>
> switch (a) {
> case 1 :
> do_something();
> case 2 :
> do_something_more();
> break;
> case 3:
> do_something_else;
> }
>
> switch (b) {
> case 1 :
> do_something();
> // fallthrough
> case 2 :
> do_something_more();
> break;
> case 3:
> do_something_else;
> }
>
(I assume you unintentionally forgot the '()' in "case 3".)
>
> Which of these would you say is the better code - switch (a) or switch
> (b) - which both do exactly the same thing?
In the early 1990's, when I co-authored our C/C++ coding standards,
a "fall-through" comment was mandated!
(And, BTW, we also mandated a 'default' branch, if only to write a
diagnostic message to a logfile.)
>
> That's a rhetorical question - obviously the version the version that
> makes it clear to readers that the fall-through is intentional is
> better. (For C23, "[[fallthrough]];" is an alternative to the comment.)
(We didn't have that C23 feature back then.)
>
> So use -Wimplicit-fallthrough, write your code clearly so that
> intentional fall-throughs are obvious, and let your compiler help when
> you get things wrong.
Does that warning-setting parse existing fall-through comments and
will stay silent if existing? - If not then the point about annoying
warnings that hide real issues still stands. - Okay, I just tried it
with a contemporary gcc; and I see that this modern compiler indeed
parses an existing comment and accepts some strings (not a sloppy
"fal thru", but at least some more accurately written comments). -
That's indeed a useful addition! - (And if we'd have had support for
that in our compilers back then, then we'd certainly have had such a
warning flag in our standard build-scripts since it would serve the
finding of unintentional errors before the reviews-process-stage.)
>
> The next one is shadowing. That's an example of a warning that is more
> a matter of personal style. Use "-Wshadow" (or "-Wshadow=global") if
> you want to avoid any kind of shadowing. Use "-Wshadow=local" if you
> don't mind shadowing "global" identifiers, but want to avoid local
> variables shadowing each other. Don't enable "-Wshadow" if you
> regularly shadow identifiers.
No, shadowing is not something that should be forbidden by rule (or
principally avoided).
I don't know what you mean by "local variables shadowing each other".
(Two declarations of the same variable is just an error, isn't it?)
>
> If you want a warning on normally, but have particular reason to need an
> exception, use pragma push/pop :
Pragmas, as I know them, were generally compiler/platform specific.
Has that changed?
(Since we developed for multiple platforms it wasn't the programmer's
"task" to place platform-specific pragmas in his code; it wouldn't
have worked elsewhere. - I seem to recall that the build-management
supported all the platform specifics.)
> [...]
>
> This is ugly, but it stands out as clearly doing something unusual. I
> use it occasionally.
>
> Or maybe you have a habit of "constifying" your loop variables. You
> like to write :
>
> for (int i = 0; i < 10; i++) {
> const int _i = i;
> const int i = _i;
> ...
> }
I don't see what the intention of such code would be. - It just looks
either wrong or at least unnecessary convoluted to me. (It appears to
me like the "constructed problems" that we regularly see from bart.)
I don't think it's sensible to argue about such, but if you think so,
maybe you can create a better example to show your point.
>
> so that inside your loop, the variable is "const" - that would catch any
> mistakes you make that accidentally changed the loop variable inside the
> loop. Clearly you don't want to write those #pragmas for every loop!
> You can use macros:
>
> [...]
>
> Now you have :
>
> for (int i = 0; i < 10; i++) {
> Constify(i);
> ...
> }
Ah! - Is it that they wanted an Algol 68 like loop-variable semantics
in "C" and introduced such [clumsy] "Constify" for that? (Amazing! :-)
(A lot of "fancy" stuff they seem to have added during past decades.)
>
> I am not saying that I am recommending this particular practice - I am
> merely showing how many warnings can be on in general while you also
> have the flexibility to bypass them at times.
Thereby solving the issues that were invented in the first place. ;-)
But okay. - I see where you're coming from. And I see that what would
have been considered just unwise in former days could now in some way
be addressed. (It wouldn't serve me, but I acknowledge that it might
be a way that could help others; provided they make use if it.)
>> [...]
>
> There are, I think, almost no circumstances in which you would want /
> all/ warnings supported by good compilers. "-Wall" in gcc does not mean
> all warnings - at least, not for a very long time. I view it more like
> "all compilations should use -Wall". It is intended that the warnings
> in "-Wall" suit a wide range of uses, with few false positives in real
> code.
This very much sounds like what the compiler vendors back then had as
default warnings. (And what lead us to a no-default-warnings-visible
basic policy as landmark for delivering source versions.)
> Some of the "-Wextra" warnings are more divisive, though I
> personally would like to see "-Wuninitialized" and "-Wimplicit-
> fallthrough" in "-Wall". I'd also like to see "-Wall" enabled by
> default, but that's not going to happen :-(
Support of warnings has changed over the decades and I'm certainly
not competent to talk about the current state. I was merely advocating
against the "activate all warnings" philosophy; but I'm not sure any
more that this is what you actually had intended to say.
>
> The point is, there is no downside to enabling a warning that never
> triggers because you don't code that way.
Yes, undoubtedly. - If you don't see it that's fine. :-)
The critical point discussed were the warnings that are displayed but
are just annoying. - And I still think this depends, as said, on the
individual, the language, and some other factors.
> And for many warnings that
> might be triggered despite the code being correct, there is no downside
> in writing code in a clearer manner that avoids triggering the warning
> (like adding comments for implicit fall-throughs).
Well, that sadly cannot be generalized. (The shadowing theme, e.g., is
not a question of "clear code". YMMV.)
> [...]
>
>> In professional contexts it's a bit different. You'd certainly annoy
>> professionals if they see many unfitting and just distracting warnings.
>> Build-settings (including warnings) are usually defined and provided,
>> and processes and QA methods and instances add another stage of safety.
>>
>
> If your builds produce warnings during normal builds, either you have
> written something wrong (or at least questionable) in your code [...]
Erm, no. - I think that should (at least meanwhile) have got clear.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-07 16:40 +0200 |
| Message-ID | <11a5ll7$2uea5$1@dont-email.me> |
| In reply to | #402798 |
On 07/10/2026 15:16, Janis Papanagnou wrote:
> On 2026-10-07 10:28, David Brown wrote:
>> On 06/10/2026 19:25, Janis Papanagnou wrote:
>>> [...]
>> [...]
>>
>> If you are getting lots of warnings, you are doing something wrong.
>
> I don't think this is generally true. (I mentioned already that it
> depends on a couple factors.)
I can't reconcile "getting lots of warnings" with "builds must be
warning-free". If your builds are warning-free (once you have fixed
whatever issues you had in the code, or possibly modified your choice of
warning options), you are not getting lots of warnings. You are not
getting /any/ warnings, except when you make a new mistake in your code
or write something new that is very unusual.
Since the warning options you have are not then giving any false
positives, or hindering you from writing the code you want, I cannot see
why you then would want to disable them. It gains you nothing.
And there is no "confirmation fatigue" when there are no warning
messages to get lost in.
You make it sound like I am recommending getting lots of warning
messages from your compiler rather than lots of warning options!
(I think there has been some level of miscommunication in this
discussion, which I hope is at least partially cleared up by the end of
this post.)
>
> (I snip your subsequent explanations because what you intended to
> point out in that respect had been clear already.)
>
>> [...]
>>
>> The standard for most development, IME, is that completed programs
>> should build without warnings being generated.
>
> Yes. That had always been our line in our commercial development.
> (The build-settings were centralized, though, and far from all
> warnings had been activated; the annoyances and problems with of
> many unnecessary "hints" were seriously considered. Another poster
> here named the negative effect (that I already explained) before as
> “confirmation fatigue”. I think we shouldn't underestimate that.)
> And individual programmers have not directly created the delivered
> programs, though; there were quite some more stages in the process.
>
> A zero-warnings policy is also a landmark in my private context.
> But that doesn't mean that I'd activate a full-warnings setting
> and go to study all what the diagnostics think might be a problem.
> (It may, what I suspected, be a personal thing, based on factors
> already mentioned.)
No one has suggested that you use a "full-warnings" setting - quite the
opposite. I have recommending having /lots/ of warnings, but most
certainly not /all/ - tune the choices to your needs (and the coding
standards required by the project, if applicable).
>
>> But that is not because the warnings are swept under the carpet by
>> disabling them because the developer considers himself / herself an
>> expert!
>
> Personal self-valuation was neither the topic nor helpful in real
> situations (professional or private). - We should dismiss that idea.
You said that "newbies" should be enabling more warnings than "more
experienced people". I don't know (and I don't think it matters)
whether that distinction is from self-evaluation or anything else.
>
>>
>>>>
>>>> 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.
>>>
>>> It might be that we have different situations in mind. - Just take the
>>> two of the recently discussed examples, fall-through and shadowing, for
>>> example; if I'm using fall-through deliberately I certainly don't want
>>> to see a distracting warning, or someone who thinks that shadowing is
>>> an oversight in language design (as opposed to a deliberate sensible
>>> design as consequence of block-structures and scope) I certainly don't
>>> want to see that.
>>
>> Let me answer these two example cases, for demonstrative purposes.
>>
>> switch (a) {
>> case 1 :
>> do_something();
>> case 2 :
>> do_something_more();
>> break;
>> case 3:
>> do_something_else;
>> }
>>
>> switch (b) {
>> case 1 :
>> do_something();
>> // fallthrough
>> case 2 :
>> do_something_more();
>> break;
>> case 3:
>> do_something_else;
>> }
>>
>
> (I assume you unintentionally forgot the '()' in "case 3".)
Yes - and gcc warned me about that when I tried the code. I have made
such typos in real code, and if the compiler had not immediately told
me, I am sure it would have led to a lot of confusion about why my code
did not work as expected.
>
>>
>> Which of these would you say is the better code - switch (a) or switch
>> (b) - which both do exactly the same thing?
>
> In the early 1990's, when I co-authored our C/C++ coding standards,
> a "fall-through" comment was mandated!
>
> (And, BTW, we also mandated a 'default' branch, if only to write a
> diagnostic message to a logfile.)
I don't think a default branch should be mandated - but different people
have different opinions there. Since both these rules can be checked
automatically by gcc (-Wimplicit-fallthrough, -Wswitch-default), it
would be almost absurd not to have these warning options enabled.
(I have been referring to gcc options throughout this thread, since that
is the compiler I use most myself. Other compilers are likely to have
somewhat similar options, though of course details can vary.)
>
>>
>> That's a rhetorical question - obviously the version the version that
>> makes it clear to readers that the fall-through is intentional is
>> better. (For C23, "[[fallthrough]];" is an alternative to the comment.)
>
> (We didn't have that C23 feature back then.)
"__attribute__((fallthrough))" has been around for quite some time - but
perhaps not since the early 1990's !
>
>>
>> So use -Wimplicit-fallthrough, write your code clearly so that
>> intentional fall-throughs are obvious, and let your compiler help when
>> you get things wrong.
>
> Does that warning-setting parse existing fall-through comments and
> will stay silent if existing?
Yes.
> - If not then the point about annoying
> warnings that hide real issues still stands. - Okay, I just tried it
> with a contemporary gcc; and I see that this modern compiler indeed
> parses an existing comment and accepts some strings (not a sloppy
> "fal thru", but at least some more accurately written comments). -
It handles a wide range of likely patterns in comments (the manual page
gives the details for those that like reading regular expressions).
> That's indeed a useful addition! - (And if we'd have had support for
> that in our compilers back then, then we'd certainly have had such a
> warning flag in our standard build-scripts since it would serve the
> finding of unintentional errors before the reviews-process-stage.)
>
To be fair here, I have been giving information about modern gcc. The
compiler gains new warnings with every version. The
"-Wimplicit-fallthrough" option is from gcc 7 in 2017, while
"-Wswitch-default" is from gcc 3.3 in 2003.
I don't change compiler versions for existing projects without very good
reason, but when starting projects I usually choose the newest version
with an appropriate level of support for the target, and I update my
list of warnings (and other flags) in my makefiles to suit.
>>
>> The next one is shadowing. That's an example of a warning that is
>> more a matter of personal style. Use "-Wshadow" (or "-
>> Wshadow=global") if you want to avoid any kind of shadowing. Use "-
>> Wshadow=local" if you don't mind shadowing "global" identifiers, but
>> want to avoid local variables shadowing each other. Don't enable "-
>> Wshadow" if you regularly shadow identifiers.
>
> No, shadowing is not something that should be forbidden by rule (or
> principally avoided).
>
> I don't know what you mean by "local variables shadowing each other".
> (Two declarations of the same variable is just an error, isn't it?)
int a;
void foo(void) {
int a; // Shadows global a
for (int a = 0; a < 10; a++) { // Shadows local a
Shadowing globals is more likely to happen by accident. Most people
don't want a complaint about shadowing for their local variables "y0"
and "y1" to suddenly appear when they have #include <math.h> and choose
std=gcc17 instead of std=c17. (These are Bessel functions provided by
several maths libraries as extensions.)
But it is not uncommon to disallow local variables from shadowing each
other. One opinion here is as good as any other - it's a style choice.
>
>>
>> If you want a warning on normally, but have particular reason to need
>> an exception, use pragma push/pop :
>
> Pragmas, as I know them, were generally compiler/platform specific.
> Has that changed?
No. Warnings are also compiler-specific. (Warnings and pragmas are
mostly target-independent, however.) Some projects are naturally
compiler-specific, others aim to be as compiler agnostic as possible,
and some use conditional compilation to adapt. You know all of this - I
am sharing examples from gcc, and you and anyone else can adapt to suit
the tools you use.
>
> (Since we developed for multiple platforms it wasn't the programmer's
> "task" to place platform-specific pragmas in his code; it wouldn't
> have worked elsewhere. - I seem to recall that the build-management
> supported all the platform specifics.)
>
>> [...]
>>
>> This is ugly, but it stands out as clearly doing something unusual. I
>> use it occasionally.
>>
>> Or maybe you have a habit of "constifying" your loop variables. You
>> like to write :
>>
>> for (int i = 0; i < 10; i++) {
>> const int _i = i;
>> const int i = _i;
>> ...
>> }
>
> I don't see what the intention of such code would be. - It just looks
> either wrong or at least unnecessary convoluted to me. (It appears to
> me like the "constructed problems" that we regularly see from bart.)
> I don't think it's sensible to argue about such, but if you think so,
> maybe you can create a better example to show your point.
>
I don't intend this as a recommended practice in code. But people write
weirder stuff - you occasionally come across someone using a macro like
"FOR_LOOP(i, 10)" because they prefer it to normal "for" loops. And I
believe it is common to see modification of a loop variable inside the
loop is a very bad idea - if the loop variable were "const" inside the
loop, any accidental modification would be caught as an error. I don't
imagine many people would bother to use an extra const variable to get
that effect.
>>
>> so that inside your loop, the variable is "const" - that would catch
>> any mistakes you make that accidentally changed the loop variable
>> inside the loop. Clearly you don't want to write those #pragmas for
>> every loop! You can use macros:
>>
>> [...]
>>
>> Now you have :
>>
>> for (int i = 0; i < 10; i++) {
>> Constify(i);
>> ...
>> }
>
> Ah! - Is it that they wanted an Algol 68 like loop-variable semantics
> in "C" and introduced such [clumsy] "Constify" for that? (Amazing! :-)
>
> (A lot of "fancy" stuff they seem to have added during past decades.)
>
Do you mean the type inference with "auto" ? It's new to C23, but been
in C++ since C++11, and in gcc as "__auto_type" for a very long time.
>>
>> I am not saying that I am recommending this particular practice - I am
>> merely showing how many warnings can be on in general while you also
>> have the flexibility to bypass them at times.
>
> Thereby solving the issues that were invented in the first place. ;-)
Maybe there is a particular pattern you use regularly where you have
local variables that shadow each other, and we could use that? Since I
can't think off-hand of a case where local variable shadowing would help
the clarity of real code, it's difficult to think of a realistic example!
When I look in my own code for cases where I have used diagnostic push
and pops, the most common cases is for the "-Wpadded" warning when a
structure has had added padding for alignment. Padding happens
naturally in C code, and is usually not a problem - the warning would
trigger on a lot of existing code and third-party code. But sometimes
you want to be sure there is no padding, such as when a struct
represents a network packet or other external structure. So here I
would turn on the warning around the network struct definitions, then
restore the original state of the warning flag.
>
> But okay. - I see where you're coming from. And I see that what would
> have been considered just unwise in former days could now in some way
> be addressed. (It wouldn't serve me, but I acknowledge that it might
> be a way that could help others; provided they make use if it.)
>
>>> [...]
>>
>> There are, I think, almost no circumstances in which you would want /
>> all/ warnings supported by good compilers. "-Wall" in gcc does not
>> mean all warnings - at least, not for a very long time. I view it
>> more like "all compilations should use -Wall". It is intended that
>> the warnings in "-Wall" suit a wide range of uses, with few false
>> positives in real code.
>
> This very much sounds like what the compiler vendors back then had as
> default warnings. (And what lead us to a no-default-warnings-visible
> basic policy as landmark for delivering source versions.)
Different compilers have had different policies for default sets of
warnings. gcc is quite lax by default (though it has improved with
time). I've seen compilers that are downright idiotic in their default
choice of warnings - IMHO, of course.
>
>> Some of the "-Wextra" warnings are more divisive, though I personally
>> would like to see "-Wuninitialized" and "-Wimplicit- fallthrough" in
>> "-Wall". I'd also like to see "-Wall" enabled by default, but that's
>> not going to happen :-(
>
> Support of warnings has changed over the decades and I'm certainly
> not competent to talk about the current state. I was merely advocating
> against the "activate all warnings" philosophy; but I'm not sure any
> more that this is what you actually had intended to say.
>
There seems to be some miscommunication here - I have never suggested a
"activate all warnings" philosophy. I have suggested activating
warnings for lots of things, as long as they don't clash with the coding
style of the project or programmer - and I advocate against the idea
that "experts" should disable warnings that would mostly only be
triggered by "newbies".
>>
>> The point is, there is no downside to enabling a warning that never
>> triggers because you don't code that way.
>
> Yes, undoubtedly. - If you don't see it that's fine. :-)
>
> The critical point discussed were the warnings that are displayed but
> are just annoying. - And I still think this depends, as said, on the
> individual, the language, and some other factors.
Of course.
In my projects, I will often have lots of code provided by third parties
(manufacturer's SDKs, RTOS's, network stacks, etc.). Sometimes the
quality of that code is questionable at best, and often it is written in
a noticeably different style from my own. So I use different flags for
that code compared to mine (sometimes going as far as to use "-fwrapv
-fno-strict-aliasing" on the third-party code), with more warning flags
on my own code.
>
>> And for many warnings that might be triggered despite the code being
>> correct, there is no downside in writing code in a clearer manner that
>> avoids triggering the warning (like adding comments for implicit fall-
>> throughs).
>
> Well, that sadly cannot be generalized. (The shadowing theme, e.g., is
> not a question of "clear code". YMMV.)
>
Let me re-phrase a little. If writing the code in a clearer manner
means a particular warning is not triggered, then it is better to write
the code clearly and have the warning enabled, than to write unclear
code and disable the warning. Thus it is better to avoid implicit
fall-through warnings by adding a comment in the code instead of
disabling the -Wimplicit-fallthrough warning.
Other things are more a style choice where people will have differing
opinions on what is "clear" in the code - and there will be less
consensus about whether or not a warning option should be used. That's
fine too.
>> [...]
>>
>>> In professional contexts it's a bit different. You'd certainly annoy
>>> professionals if they see many unfitting and just distracting warnings.
>>> Build-settings (including warnings) are usually defined and provided,
>>> and processes and QA methods and instances add another stage of safety.
>>>
>>
>> If your builds produce warnings during normal builds, either you have
>> written something wrong (or at least questionable) in your code [...]
>
> Erm, no. - I think that should (at least meanwhile) have got clear.
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-08 07:24 -0700 |
| Message-ID | <86o6d4jmnu.fsf@linuxsc.com> |
| In reply to | #402798 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-10-07 10:28, David Brown wrote: > >> On 06/10/2026 19:25, Janis Papanagnou wrote: >> >>> [...] >> >> [...] >> >> If you are getting lots of warnings, you are doing something wrong. > > I don't think this is generally true. It is true. And the fix is usually to omit or disable more -W options. ;)
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web