Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401667 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-09-06 15:45 +0200 |
| Last post | 2026-10-05 04:32 +0200 |
| Articles | 20 on this page of 496 — 24 participants |
Back to article view | Back to comp.lang.c
Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-06 16:52 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-06 21:41 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 09:37 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 11:35 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 13:15 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 13:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:24 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 15:33 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 16:34 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 00:50 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 00:35 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 17:43 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-07 16:52 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 15:24 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 20:16 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:31 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:37 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 21:37 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:38 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-18 17:42 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 03:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:40 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 20:08 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 12:32 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:30 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 18:37 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 20:12 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 22:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:15 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:37 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:39 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 14:41 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:31 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:10 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 09:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:59 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:35 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:08 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:14 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:16 +0200
Re: Official list of top C annoyances Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-14 19:14 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 08:29 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 02:45 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:07 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:14 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:31 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:41 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 15:58 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:05 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:13 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 16:29 -0700
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:23 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:19 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:02 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:11 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:25 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:53 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:42 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 19:16 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:48 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:38 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:04 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:12 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 23:59 +0800
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:30 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:50 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:13 -0700
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:16 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:43 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 07:16 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-08 00:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 12:47 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-09 01:59 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 19:12 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-09 21:01 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:18 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:32 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:30 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 08:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 13:09 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:11 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 14:33 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:51 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:03 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 15:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:59 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 16:57 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:18 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 01:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:54 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:06 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:15 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:56 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:25 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:17 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:21 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 12:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:13 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-11 13:41 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:08 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:13 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:02 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:48 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:06 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 23:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 15:52 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 17:11 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-12 08:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 08:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 09:09 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:40 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 11:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:00 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 14:24 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:44 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 17:20 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 17:08 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 10:53 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:23 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 18:58 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 22:16 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 15:40 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:27 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 10:30 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 11:26 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:11 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-13 05:29 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-13 14:00 -0700
Re: Official list of top C annoyances Ike Naar <ike@sdf.org> - 2026-09-13 10:53 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 13:46 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 15:21 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 15:31 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 18:01 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 21:14 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:23 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:27 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-13 17:06 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 15:01 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 18:11 +0200
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-14 20:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:54 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-14 23:56 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 09:07 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 09:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 10:22 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 11:51 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 12:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 09:10 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:37 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:03 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:01 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 01:57 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:54 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 21:03 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 00:33 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-13 10:50 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:39 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:23 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 07:45 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:37 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-13 18:55 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 01:44 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-14 07:41 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:01 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:09 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 02:42 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 23:41 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 01:48 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 07:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 11:28 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 14:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 21:56 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 21:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 00:36 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 02:21 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 09:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 13:47 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 17:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 00:36 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 16:59 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 01:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 19:43 -0700
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 09:24 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 11:29 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 02:04 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 18:19 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:17 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:44 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:16 +0200
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-18 12:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:53 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:47 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:22 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:58 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 21:06 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:07 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:34 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:15 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 15:16 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 15:25 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:05 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 16:46 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:22 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:19 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:47 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:54 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:44 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:48 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 00:04 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 01:34 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 17:50 -0700
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:45 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:28 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 18:34 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 18:08 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:26 -0700
Re: Official list of top C annoyances gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-18 20:39 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:10 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 13:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:30 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:38 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:00 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 10:17 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 11:29 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:52 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:06 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 15:58 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:41 +0300
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 01:53 +0800
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-22 11:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-22 11:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:00 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 14:22 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 16:38 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:28 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:29 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 22:01 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 20:28 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 05:42 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 08:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 10:23 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:24 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 16:31 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:29 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:14 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:42 -0700
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:39 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:24 +0100
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 00:19 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 02:06 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 20:20 -0700
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 03:26 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:56 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 11:08 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-19 13:25 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 10:45 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-19 15:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:17 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:45 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:11 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 14:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 17:24 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:07 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:26 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 22:57 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 20:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 12:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:42 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:22 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:54 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 23:24 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-21 15:06 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-21 16:36 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-21 17:45 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:54 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:02 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:02 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:58 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:19 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 23:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 16:17 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:49 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:18 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:41 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 21:05 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 14:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:15 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 16:33 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:26 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:26 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:25 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:36 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 14:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 14:32 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:17 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:24 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 09:06 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 02:08 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:01 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 03:05 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 17:33 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:19 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:21 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 13:16 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:26 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 15:58 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:30 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:30 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 21:16 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 02:56 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:32 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-29 19:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 02:15 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:22 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 09:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 11:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:15 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:27 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-23 01:01 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-23 23:38 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 02:00 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 02:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-23 20:23 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 23:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 01:23 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-25 03:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:38 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:49 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:44 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 14:03 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 00:05 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:56 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 14:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-30 11:18 +0100
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:37 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-30 17:17 +0300
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 14:39 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:39 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:23 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-10-02 09:17 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-25 12:17 +0300
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:31 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:34 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-24 08:50 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-24 11:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:29 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:59 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-29 04:06 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 04:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 23:49 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-30 12:19 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:13 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:38 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:40 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 12:05 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:23 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:52 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 01:00 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:17 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:29 +0200
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:46 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 09:15 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:38 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:36 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 10:11 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:48 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:18 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 12:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:21 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:47 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:20 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 09:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-07 23:59 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 16:04 -0600
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-07 04:06 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-07 20:05 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 12:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 13:09 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 14:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:49 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:18 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 09:45 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 20:41 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:39 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 15:55 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:02 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 17:39 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:47 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 18:19 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 19:24 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 19:26 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 03:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:13 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:38 -0600
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 22:16 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:02 +0200
Re: Official list of top C annoyances Jan van den Broek <balglaas@dds.nl> - 2026-09-09 12:50 +0000
And then we reached C# (was Re: Official list of top C annoyances) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 08:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 14:54 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 14:22 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-10-05 04:32 +0200
Page 2 of 25 — ← Prev page 1 [2] 3 4 … 25 Next page →
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-09-09 21:37 +0800 |
| Message-ID | <QidoS.172433$kqHe.140073@fx07.ams4> |
| In reply to | #401789 |
On 09/09/2026 8:37 PM, fir wrote: > fir pisze: >> Johann 'Myrkraverk' Oskarsson pisze: >>> On 09/09/2026 4:18 PM, fir wrote: >>>> Johann 'Myrkraverk' Oskarsson pisze: >>>>> On 08/09/2026 7:52 AM, Keith Thompson wrote: >>>>>> Lane W <cactus_DAC@yahoo.com> writes: >>>>>> [128 lines deleted] >>>>>> >>>>>>> One of the things I avoid in C# is a nasty makefile, and generally >>>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>>> compiler included in the suite I use to generate my programs. >>>>>> >>>>>> OK, I think we've established that you like C# better than C >>>>>> (or C++). >>>>>> >>>>>> This is comp.lang.c. Complaints about C are topical here, even >>>>>> though some of the ones that introduced this thread are silly. >>>>>> But if you want to discuss C#, please do so elsewhere. >>>>>> >>>>> >>>>> Oh, don't mind Keith. He likes to butt in on other people's >>>>> discussions >>>>> and behave like he's some owner of comp.lang.c. He's not. There >>>>> isn't >>>>> even a comp.lang.csharp group to direct people towards. I guess Keith >>>>> will just have to start a discussion in news.groups.proposals about >>>>> it. >>>>> >>>>> I've added microsoft.public.dotnet.csharp.general to this discussion, >>>>> but I have no idea if Eternal September subscribes to it, which I be- >>>>> lieve is what most techies use to access usenet. And the last on- >>>>> topic >>>>> post in microsoft.public.dotnet.csharp.general seems to have been six- >>>>> teen years ago. >>>>> >>>>> That's a long time for nobody to get comp.lang.csharp running. >>>>> >>>>> So please feel free to complain in comp.lang.c -- and let the # be si- >>>>> lent -- until someone gets irritated enough to make a proposal that >>>>> sticks! >>>>> >>>>> >>>>> Best wishes, and happy coding in C#! >>>> >>>> this is probably not god taking on this ...the offtopics imo >>>> depending on amount (yet quality)..if group has some focus it should >>>> be focus on >>>> c realted things with some offtopics possible not focus on c not >>>> realted >>>> offtopics with slight amount of c related... >>>> >>>> so i find some sense in what keith t says though i personally cant >>>> agree >>>> with his inner idea this group is only for discussing >>>> >>>> 1) c standards >>>> >>>> not >>>> 2) c ideas >>>> or >>>> 3) c programming >>> Yeah, I don't worry about Keith and trolls like him, and discuss what I >>> want in comp.lang.c. Including meta discussions like this one, about >>> what should and shouldn't be discussed in comp.lang.c. >>> >>> Plus, it's fairly clear none of the usual trolls code anything in C, as >>> I demonstrated when I gave you some book recommendations. >>> >>> >>> Best wishes, and happy C coding! >> >> keith probably used to call me a troll (oz i not stick to his own >> rigid rules) >> so i could eventuall call him back a troll but as i once said if i >> noticed >> it is better to value regular users of this group becouse if not hem >> the group culd not exist and i would have no place to talk at all >> >> so i dont call him a troll, becouse he is okay user overally i just >> disagree in some things >> > besides he is partally right - he has a bit rigid definitions who troll > is - but this is kinda complex matter becouse depending on definitions i > may be a troll according to one, he may be atroll according to another > and so on..and which definitions are good and for what reason is a > complex thing - not sure if this is resolvable... > > generally i find whats good to improve some focus and knowledge here as > godo and whats the oposite makin brainless spam is bad etc Indeed. And for that reason, I still hope you'll read /Patterns in C/ one of these days. Or if I -- or someone else -- comes across a better reference, to share it with you. There is a lot of C knowledge out there, and the language standard isn't the end game of being a C wizard. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-18 09:38 +0200 |
| Message-ID | <118ippi$12csv$1@dont-email.me> |
| In reply to | #401796 |
Johann 'Myrkraverk' Oskarsson pisze: > On 09/09/2026 8:37 PM, fir wrote: >> fir pisze: >>> Johann 'Myrkraverk' Oskarsson pisze: >>>> On 09/09/2026 4:18 PM, fir wrote: >>>>> Johann 'Myrkraverk' Oskarsson pisze: >>>>>> On 08/09/2026 7:52 AM, Keith Thompson wrote: >>>>>>> Lane W <cactus_DAC@yahoo.com> writes: >>>>>>> [128 lines deleted] >>>>>>> >>>>>>>> One of the things I avoid in C# is a nasty makefile, and generally >>>>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>>>> compiler included in the suite I use to generate my programs. >>>>>>> >>>>>>> OK, I think we've established that you like C# better than C >>>>>>> (or C++). >>>>>>> >>>>>>> This is comp.lang.c. Complaints about C are topical here, even >>>>>>> though some of the ones that introduced this thread are silly. >>>>>>> But if you want to discuss C#, please do so elsewhere. >>>>>>> >>>>>> >>>>>> Oh, don't mind Keith. He likes to butt in on other people's >>>>>> discussions >>>>>> and behave like he's some owner of comp.lang.c. He's not. There >>>>>> isn't >>>>>> even a comp.lang.csharp group to direct people towards. I guess >>>>>> Keith >>>>>> will just have to start a discussion in news.groups.proposals >>>>>> about it. >>>>>> >>>>>> I've added microsoft.public.dotnet.csharp.general to this discussion, >>>>>> but I have no idea if Eternal September subscribes to it, which I be- >>>>>> lieve is what most techies use to access usenet. And the last on- >>>>>> topic >>>>>> post in microsoft.public.dotnet.csharp.general seems to have been >>>>>> six- >>>>>> teen years ago. >>>>>> >>>>>> That's a long time for nobody to get comp.lang.csharp running. >>>>>> >>>>>> So please feel free to complain in comp.lang.c -- and let the # be >>>>>> si- >>>>>> lent -- until someone gets irritated enough to make a proposal that >>>>>> sticks! >>>>>> >>>>>> >>>>>> Best wishes, and happy coding in C#! >>>>> >>>>> this is probably not god taking on this ...the offtopics imo >>>>> depending on amount (yet quality)..if group has some focus it >>>>> should be focus on >>>>> c realted things with some offtopics possible not focus on c not >>>>> realted >>>>> offtopics with slight amount of c related... >>>>> >>>>> so i find some sense in what keith t says though i personally cant >>>>> agree >>>>> with his inner idea this group is only for discussing >>>>> >>>>> 1) c standards >>>>> >>>>> not >>>>> 2) c ideas >>>>> or >>>>> 3) c programming >>>> Yeah, I don't worry about Keith and trolls like him, and discuss what I >>>> want in comp.lang.c. Including meta discussions like this one, about >>>> what should and shouldn't be discussed in comp.lang.c. >>>> >>>> Plus, it's fairly clear none of the usual trolls code anything in C, as >>>> I demonstrated when I gave you some book recommendations. >>>> >>>> >>>> Best wishes, and happy C coding! >>> >>> keith probably used to call me a troll (oz i not stick to his own >>> rigid rules) >>> so i could eventuall call him back a troll but as i once said if i >>> noticed >>> it is better to value regular users of this group becouse if not hem >>> the group culd not exist and i would have no place to talk at all >>> >>> so i dont call him a troll, becouse he is okay user overally i just >>> disagree in some things >>> >> besides he is partally right - he has a bit rigid definitions who >> troll is - but this is kinda complex matter becouse depending on >> definitions i may be a troll according to one, he may be atroll >> according to another >> and so on..and which definitions are good and for what reason is a >> complex thing - not sure if this is resolvable... >> >> generally i find whats good to improve some focus and knowledge here >> as godo and whats the oposite makin brainless spam is bad etc > > Indeed. And for that reason, I still hope you'll read /Patterns in C/ > one of these days. Or if I -- or someone else -- comes across a better > reference, to share it with you. > > There is a lot of C knowledge out there, and the language standard isn't > the end game of being a C wizard. if those patterns are typical like by this insane oop crowd im not interesyed, im interested in more algebraical concise solutions only
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-09-18 17:42 +0800 |
| Message-ID | <DI7rS.267366$nBp.92636@fx02.ams4> |
| In reply to | #402211 |
On 18/09/2026 3:38 PM, fir wrote: > Johann 'Myrkraverk' Oskarsson pisze: >> On 09/09/2026 8:37 PM, fir wrote: >>> fir pisze: >>>> Johann 'Myrkraverk' Oskarsson pisze: >>>>> On 09/09/2026 4:18 PM, fir wrote: >>>>>> Johann 'Myrkraverk' Oskarsson pisze: >>>>>>> On 08/09/2026 7:52 AM, Keith Thompson wrote: >>>>>>>> Lane W <cactus_DAC@yahoo.com> writes: >>>>>>>> [128 lines deleted] >>>>>>>> >>>>>>>>> One of the things I avoid in C# is a nasty makefile, and generally >>>>>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>>>>> compiler included in the suite I use to generate my programs. >>>>>>>> >>>>>>>> OK, I think we've established that you like C# better than C >>>>>>>> (or C++). >>>>>>>> >>>>>>>> This is comp.lang.c. Complaints about C are topical here, even >>>>>>>> though some of the ones that introduced this thread are silly. >>>>>>>> But if you want to discuss C#, please do so elsewhere. >>>>>>>> >>>>>>> >>>>>>> Oh, don't mind Keith. He likes to butt in on other people's >>>>>>> discussions >>>>>>> and behave like he's some owner of comp.lang.c. He's not. There >>>>>>> isn't >>>>>>> even a comp.lang.csharp group to direct people towards. I guess >>>>>>> Keith >>>>>>> will just have to start a discussion in news.groups.proposals >>>>>>> about it. >>>>>>> >>>>>>> I've added microsoft.public.dotnet.csharp.general to this >>>>>>> discussion, >>>>>>> but I have no idea if Eternal September subscribes to it, which I >>>>>>> be- >>>>>>> lieve is what most techies use to access usenet. And the last >>>>>>> on- topic >>>>>>> post in microsoft.public.dotnet.csharp.general seems to have been >>>>>>> six- >>>>>>> teen years ago. >>>>>>> >>>>>>> That's a long time for nobody to get comp.lang.csharp running. >>>>>>> >>>>>>> So please feel free to complain in comp.lang.c -- and let the # >>>>>>> be si- >>>>>>> lent -- until someone gets irritated enough to make a proposal that >>>>>>> sticks! >>>>>>> >>>>>>> >>>>>>> Best wishes, and happy coding in C#! >>>>>> >>>>>> this is probably not god taking on this ...the offtopics imo >>>>>> depending on amount (yet quality)..if group has some focus it >>>>>> should be focus on >>>>>> c realted things with some offtopics possible not focus on c not >>>>>> realted >>>>>> offtopics with slight amount of c related... >>>>>> >>>>>> so i find some sense in what keith t says though i personally cant >>>>>> agree >>>>>> with his inner idea this group is only for discussing >>>>>> >>>>>> 1) c standards >>>>>> >>>>>> not >>>>>> 2) c ideas >>>>>> or >>>>>> 3) c programming >>>>> Yeah, I don't worry about Keith and trolls like him, and discuss >>>>> what I >>>>> want in comp.lang.c. Including meta discussions like this one, about >>>>> what should and shouldn't be discussed in comp.lang.c. >>>>> >>>>> Plus, it's fairly clear none of the usual trolls code anything in >>>>> C, as >>>>> I demonstrated when I gave you some book recommendations. >>>>> >>>>> >>>>> Best wishes, and happy C coding! >>>> >>>> keith probably used to call me a troll (oz i not stick to his own >>>> rigid rules) >>>> so i could eventuall call him back a troll but as i once said if i >>>> noticed >>>> it is better to value regular users of this group becouse if not hem >>>> the group culd not exist and i would have no place to talk at all >>>> >>>> so i dont call him a troll, becouse he is okay user overally i just >>>> disagree in some things >>>> >>> besides he is partally right - he has a bit rigid definitions who >>> troll is - but this is kinda complex matter becouse depending on >>> definitions i may be a troll according to one, he may be atroll >>> according to another >>> and so on..and which definitions are good and for what reason is a >>> complex thing - not sure if this is resolvable... >>> >>> generally i find whats good to improve some focus and knowledge here >>> as godo and whats the oposite makin brainless spam is bad etc >> >> Indeed. And for that reason, I still hope you'll read /Patterns in C/ >> one of these days. Or if I -- or someone else -- comes across a better >> reference, to share it with you. >> >> There is a lot of C knowledge out there, and the language standard isn't >> the end game of being a C wizard. > > if those patterns are typical like by this insane oop crowd im not > interesyed, im interested in more algebraical concise solutions only Tornhill makes it quite clear that while the original /gang of four/ patterns were phrased and presented in terms of OOP, his patterns are /not OOP/. You don't need classes to use Tornhill's patterns. He does use the same names for them, I believe; it's been quite a while since I read the original /Design Patterns/ book. This is both good and bad, because if you know what pattern you want to apply to C code, you can just look it up by the name in his book. It's bad because -- well he explains it better than I can in a summary. It's best you just read his words on the nomenclature. Best wishes, and happy reading C books! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-08 03:11 +0200 |
| Message-ID | <117nncr$2236i$3@dont-email.me> |
| In reply to | #401701 |
On 2026-09-08 01:35, bart wrote: > On 07/09/2026 23:50, Janis Papanagnou wrote: >> On 2026-09-07 17:34, bart wrote: >>> On 07/09/2026 14:33, David Brown wrote: >>>> On 07/09/2026 14:55, bart wrote: [ big snip ] >>>>> Files with the same name are always troublesome. [...] >> >> Unless (if the used language doesn't support any inherent means) you >> take organizational precautions to alleviate that situation. > > It's messy anyway. Searching for include files in C is implementation > defined. If the compiler is given a set of relative include paths to > search in some order, then it will take the first 'file.h' it sees. > > If that has been deleted or renamed, then it may find a 'file.h' > elsewhere, but the wrong one. You hope that it will generate some > errors. Or maybe it you submitted the search paths in the wrong order. I seem to recall that you weren't using Makefiles (or similar) to organize your projects? - We did that, and we had never any naming issues in our projects. - I don't recall every detail, but we used hierarchical Makefiles for sub-components, we had libraries with well defined (usually terse and clean) interfaces to be im/exported from/to parallel working groups, the same for interoperability with groups on other sites and in other companies we cooperated with in our huge projects, naming conventions on every "interface" (in depth and width dimension); not everyone needed to see every file. > [...] > > I work with three levels of a project: > > * A single EXE may import external DLL/shared libraries which in turn > import others, so a hierarchy. In this case, each EXE/DLL file, which is > a single binary, would represent a whole project for my language/ > compiler if it was my source code > > * Within a single EXE/DLL program, my 'subprograms' have their own > hierarchy, usually simple > > * But within each subprogram, the module structure is flat, by design. > > (You will surely have seen projects that uses large numbers of tiny > files, with perhaps one function in each. There is clearly little > hierarchy there.) > > > that's > > not the magnitude of files we worked with in our professional project > > contexts. > > So, what are you saying: that a simple module scheme stops working at a > certain scale? I'm saying that VERY MANY applications and libraries are > at a scale where such a scheme would work. What I was saying was that if you use programming languages that don't inherently support a good modularization concept you should take action to structure your (sub-)project(s) accordingly. And I'm also suggesting that you should apply principles that work. > > Including most open source C programs I've tried to build, and failed, > because the build process was so complex and/or Linux-centric. I'm unsure what exactly you feel "was complex", and what you think is "Linux-centric"; I recall your inability or unwillingness to make use of 'make' (which is available not only on the Unix platforms); in some multi-platform projects we used it flawlessly on/with various OSes. If you had "failed" (as you say) you might have needed to spend a bit more time "learning" that - it's not difficult, though -, or get some external build-management expertise. (In our larger projects we had own "build-managers" who also provided standards, but most developers were able to write, modify, or extend Makefiles.) >> (But I see below that you have your very own view of what you think is >> a "project" and see how you organize it. You'll know what suits you.) >> >>> >>>> For bigger projects with multiple developers, and libraries and code >>>> from different places, it is unworkable. >>> >>> Projects that produce one giant, monolithic binary? If multiple >>> binaries are involved, then each is a separate project. >> >> (You may defined that so if you feel that to be right for your cases.) >> >> Generally projects and binaries are not directly 1-to-1 related as you >> seem to believe. > > So what do you call that part of a project which does yield a single > binary? I call that: "A process to create a binary." Try to distinguish the concepts of projects (with its many tasks from planning, resource allocation (all sorts of resources!), specification, design, implementation, testing, etc. etc.), processes that are set up for development, and the artifacts that various process phases create (like tar-files, archives, executables, test-results, documentation, etc. etc.). - Please note that this is an unsystematic and incomplete list of entities, just as examples and off the top of my head; inspect some project management sources to learn about projects. (The documents from my own, meanwhile expired IPMA certificate spans 2500 pages; it's nothing suited for private "toy projects", but there's principles that can be applied also to low-scale software development. - Don't expect that I make a try to explain substantial amounts of project management basics to a person who is known to notoriously avoid even Makefiles.) > > It's that single binary, comprised from so many individual source files > and that use some specific, existing shared libraries, which is what my > whole-program language+compiler addresses. > > It is also what a big chunk of a C makefile is about, and such a tool > would eliminate that part of it. Fine. Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-08 16:40 +0000 |
| Message-ID | <8UWnS.8$e54.4@fx15.iad> |
| In reply to | #401701 |
bart <bc@freeuk.com> writes: >On 07/09/2026 23:50, Janis Papanagnou wrote: <snip> >> >> It's even worse; given - as mentioned in another part of the thread - >> that #includes are costly we often find some means to avoid not only >> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif) >> in the header files but also to prevent accessing the header file in >> the first place (by #ifndef LABEL, #include <label.h>, #endif). That >> makes such C/C++ code rather messy, IMO. (And makes one appreciate >> languages with an inherent good modularization method yet more.) > >The duplication is a problem. If 50 modules each includes the header >files for a library such as SDL2, then a full build means a scanning the >headers 50 times, which means 4000 header files (80 unique) and 2.5M >lines of code (50K unique). On a modern machine, this may add a few milliseconds to the build. The operating systems, of course, would have the include files cached in memory so there is no appreciable disk overhead caused by this soi disant "duplication". Of course, it is highly unlikely that a competent programmer would include sdl header files in all fifty modules rather than dedicating one module to handle all SDL wrappers.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-08 20:08 +0100 |
| Message-ID | <117pmg7$f5ba$1@dont-email.me> |
| In reply to | #401732 |
On 08/09/2026 17:40, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 07/09/2026 23:50, Janis Papanagnou wrote:
>
> <snip>
>
>>>
>>> It's even worse; given - as mentioned in another part of the thread -
>>> that #includes are costly we often find some means to avoid not only
>>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
>>> in the header files but also to prevent accessing the header file in
>>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That
>>> makes such C/C++ code rather messy, IMO. (And makes one appreciate
>>> languages with an inherent good modularization method yet more.)
>>
>> The duplication is a problem. If 50 modules each includes the header
>> files for a library such as SDL2, then a full build means a scanning the
>> headers 50 times, which means 4000 header files (80 unique) and 2.5M
>> lines of code (50K unique).
>
> On a modern machine, this may add a few milliseconds to the build.
I don't think so. Here is a one-file test C program:
'#include <SDL3/SDL.h>'
This is a test that compiles 50 copies of it:
c:\sdl>tm gcc -c -I. s*.c
TM: 36.59
That's 36,000 milliseconds, rather more than a few. (SDL3 is not 80Kloc
rather than 50Kloc.)
If I use a precompiled header, then it reduces to 5000 milliseconds.
However that header is 30MB, 8 times the size of the headers.
(I believe that SDL3 uses windows.h, another huge set of headers. Using
TCC here takes 1.5 seconds without using precompiled headers, but TCC
uses a compact version of windows.h.)
My idea to flatten the headers into one file would reduce them to a
fraction of the original, perhaps 0.25mb. No need for GCH files, and it
benefits every compiler.
> The operating systems, of course, would have the include files cached
> in memory so there is no appreciable disk overhead caused by this
> soi disant "duplication".
All timings I post about about build-times take account of that and
assume files are cached. The SDL3 headers are anyway only about 3.6MB.
> Of course, it is highly unlikely that a competent programmer would
> include sdl header files in all fifty modules rather than
> dedicating one module to handle all SDL wrappers.
The overheads of compiling multiple header files, in fact anything I
mentioned about build-systems, is always a non-problem according to you.
That's why all these solutions and workarounds exist!
Actually the last time I worked on an SDL project, not mine, each of the
20 modules did in fact include SDL.H.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 09:35 +0200 |
| Message-ID | <117r282$3r5qn$3@dont-email.me> |
| In reply to | #401734 |
On 2026-09-08 21:08, bart wrote: > On 08/09/2026 17:40, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 07/09/2026 23:50, Janis Papanagnou wrote: >>>> >>>> It's even worse; given - as mentioned in another part of the thread - >>>> that #includes are costly we often find some means to avoid not only >>>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif) >>>> in the header files but also to prevent accessing the header file in >>>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That >>>> makes such C/C++ code rather messy, IMO. (And makes one appreciate >>>> languages with an inherent good modularization method yet more.) >>> >>> The duplication is a problem. If 50 modules each includes the header >>> files for a library such as SDL2, then a full build means a scanning the >>> headers 50 times, which means 4000 header files (80 unique) and 2.5M >>> lines of code (50K unique). >> >> On a modern machine, this may add a few milliseconds to the build. > > I don't think so. [...] I second that. - At least in our very huge C++ projects back then the repeated and cascaded inclusion (with fibonacci call-characteristics) was a build-performance killer. That was the reason we introduced the #ifndef in the first place. - If the dependencies weren't in cascaded form I might be less concerned with modern machines, but as it is... Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 10:18 +0200 |
| Message-ID | <117r4on$s9ir$1@dont-email.me> |
| In reply to | #401734 |
On 08/09/2026 21:08, bart wrote: > On 08/09/2026 17:40, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 07/09/2026 23:50, Janis Papanagnou wrote: >> >> <snip> >> >>>> >>>> It's even worse; given - as mentioned in another part of the thread - >>>> that #includes are costly we often find some means to avoid not only >>>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif) >>>> in the header files but also to prevent accessing the header file in >>>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That >>>> makes such C/C++ code rather messy, IMO. (And makes one appreciate >>>> languages with an inherent good modularization method yet more.) >>> >>> The duplication is a problem. If 50 modules each includes the header >>> files for a library such as SDL2, then a full build means a scanning the >>> headers 50 times, which means 4000 header files (80 unique) and 2.5M >>> lines of code (50K unique). >> >> On a modern machine, this may add a few milliseconds to the build. > > I don't think so. Here is a one-file test C program: > > '#include <SDL3/SDL.h>' > > This is a test that compiles 50 copies of it: > > c:\sdl>tm gcc -c -I. s*.c > TM: 36.59 > > That's 36,000 milliseconds, rather more than a few. (SDL3 is not 80Kloc > rather than 50Kloc.) > > If I use a precompiled header, then it reduces to 5000 milliseconds. > > However that header is 30MB, 8 times the size of the headers. > > (I believe that SDL3 uses windows.h, another huge set of headers. Using > TCC here takes 1.5 seconds without using precompiled headers, but TCC > uses a compact version of windows.h.) > Without having used SDL, or done any comparisons or measurements, I think there are a few things worth considering here. I am not commenting directly on your particular setup. 1. SDL headers are /big/, because the library is big. Programs that use SDL general involve a lot of files and a lot of code. So compilation of SDL programs is naturally going to be more demanding than compilation of "hello world" programs - the time taken to "digest" the headers is then a smaller proportion of the compilation compared to analysing and optimising the user code. 2. A "modern machine", in my mind, has multiple cores, plenty of ram, and a fast disk (good M2 SSD). If you are programming for a living, a machine that fits your uses is important. 3. "Modern machine" implies, to some people, a "modern OS" suitable for the task. That means *nix, most likely Linux. There is no doubt that Linux is far better at dealing with large numbers of files at a time, such as big include sets, and far more efficient for handling the large number of processes used when doing big gcc builds. The gcc architecture is a fit for the strengths of *nix systems - it assumes that files are cached and fast to re-use, that splitting things into many small processes is efficient, and so on. (For comparison, MSVC is designed to play to Windows strengths - it holds much more in its own memory rather than OS file caches, and works as a monolithic multi-threaded program.) 4. Modern development is done with build systems - make, cmake, ninja, bazel, whatever. The real work is done in parallel, making good use of the multi-core machine. This also exasperates OS limitations - now instead of dealing with a thousand file reads and a dozen processes for one compilation, you are doing that twenty times in parallel. On *nix systems, that's effortless - Windows has far more bottlenecks. And if you have some kind of on-access anti-virus software running on the Windows system, that can cripple performance. I see my current project taking perhaps an order of magnitude longer to build on Windows systems than Linux, with similar processors (I do have more ram in my system, but I don't think that's critical). I understand your desire to speed up compilations, because compilation speed is important to you. (Why SDL matters to you is another question.) But you should also understand that many other people have different, more general ways to make build speed a minor issue (at least for C programs). If I can make build speed a non-issue for my work by using a decent PC, using Linux, using make, then that is something I can apply to /all/ my programs. Trying to optimise or flatten header sets for some library would be a waste of effort - the effect is too minor. Of course, for someone writing and distributing a popular library, it might be worth making flattened versions of their headers available as even a small effect is multiplied by the number of people using the library. I did a brief check of the most include-heavy file in my current project. There are about 160 include files going into the compile, with about 200 include directives executed (some headers presumably have include directives before their include guard). Total pre-processed code is 3.6 million lines, of which 400 are from the actual C++ file. Pre-processing takes 0.1 seconds, with the full optimised compile taking 0.55 seconds. "Touching" that one file, and doing "make -j" takes 1.3 seconds - it includes linking after the compiler. A full clean "make -j 18" rebuild takes 6.4 seconds in parallel. A non-parallel build takes 63 seconds. During typical development, I rebuild after changing a file. 1.3 seconds is close enough to "instant" that it is not an issue - I make changes, press ctrl-S then ctrl-B, and the error markers are in the IDE after 0.5 seconds (there's no linking when I have compile-time errors in the code!). Saving a hypothetical maximum of 0.1 seconds from flattened headers would make no difference. But using parallel builds controlled by make, rather than serial builds, cuts the full build time by 90%. (Sometimes a header change triggers a re-compile of large parts of the code base.) Using make to handle dependencies and compile only when needed saves 98% of the time compared to full serial builds. Of course it would be nice to shave off another 10% from faster header handling - but it's a drop in the ocean compared to the other generic techniques I already use.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 12:32 +0100 |
| Message-ID | <117rg3p$13gcr$1@dont-email.me> |
| In reply to | #401763 |
On 09/09/2026 09:18, David Brown wrote:
> On 08/09/2026 21:08, bart wrote:
>> On 08/09/2026 17:40, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 07/09/2026 23:50, Janis Papanagnou wrote:
>>>
>>> <snip>
>>>
>>>>>
>>>>> It's even worse; given - as mentioned in another part of the thread -
>>>>> that #includes are costly we often find some means to avoid not only
>>>>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
>>>>> in the header files but also to prevent accessing the header file in
>>>>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That
>>>>> makes such C/C++ code rather messy, IMO. (And makes one appreciate
>>>>> languages with an inherent good modularization method yet more.)
>>>>
>>>> The duplication is a problem. If 50 modules each includes the header
>>>> files for a library such as SDL2, then a full build means a scanning
>>>> the
>>>> headers 50 times, which means 4000 header files (80 unique) and 2.5M
>>>> lines of code (50K unique).
>>>
>>> On a modern machine, this may add a few milliseconds to the build.
>>
>> I don't think so. Here is a one-file test C program:
>>
>> '#include <SDL3/SDL.h>'
>>
>> This is a test that compiles 50 copies of it:
>>
>> c:\sdl>tm gcc -c -I. s*.c
>> TM: 36.59
>>
>> That's 36,000 milliseconds, rather more than a few. (SDL3 is not
>> 80Kloc rather than 50Kloc.)
>>
>> If I use a precompiled header, then it reduces to 5000 milliseconds.
>>
>> However that header is 30MB, 8 times the size of the headers.
>>
>> (I believe that SDL3 uses windows.h, another huge set of headers.
>> Using TCC here takes 1.5 seconds without using precompiled headers,
>> but TCC uses a compact version of windows.h.)
>>
>
> Without having used SDL, or done any comparisons or measurements, I
> think there are a few things worth considering here. I am not
> commenting directly on your particular setup.
>
> 1. SDL headers are /big/, because the library is big. Programs that use
> SDL general involve a lot of files and a lot of code. So compilation of
> SDL programs is naturally going to be more demanding than compilation of
> "hello world" programs - the time taken to "digest" the headers is then
> a smaller proportion of the compilation compared to analysing and
> optimising the user code.
Actually I chose SDL because it was a substantial library that was still
fairly small and compact! SDL3 has grown somewhat from SDL2 but this is
a comparison with GTK2 (for a C program that includes only SDL.h or GTK.h):
SDL3 GTK2 (approx figures)
No of unique headers 86 550
Line count 82 Kloc 330 Kloc across unique headers
Total #includes 346 1100
Folders 1 12 at least
The latest GTK is GTK4; no doubt that is bigger.
My experiments in reducing each to a compact one-file representation
suggested these would be the C header sizes that would result:
SDL2 GTK2
Number of files 1 1
Line count 3 Kloc 25 Kloc (3Kloc reduced from 50Kloc)
Total #includes 1 1
(Based on converting SDL2/GTK2 headers files to sets of bindings in my
language. In that language, the file would be processed exactly once per
build; in C it would still be per module that includes the header.)
> I see my current project taking perhaps an order of magnitude longer to
> build on Windows systems than Linux, with similar processors (I do have
> more ram in my system, but I don't think that's critical).
I tried my SDL3 test with WSL and Windows:
WSL 22.5 seconds (real)
Windows 38 seconds (elapsed)
This is that amount of files/includes described above, times 50. Tests
were done twice and this is the faster of the two. (Yesterday the
Windows one was 36; timings vary.)
However, this doesn't tell me much about whether building on Windows is
inherently slower, since SDL for Windows uses 'windows.h', while for
Linux it may use X11 or whatever. Maybe the former is much larger.
It's possible that your magnitude difference is because you need
windows.h or some other MS header that will be more bloated than the
equivalent POSIX.
Or maybe WSL is still really Windows (but I haven't seen a spectacular
difference when I used a true Linux).
> Trying to optimise or flatten header sets
> for some library would be a waste of effort - the effect is too minor.
If that was routinely done, then perhaps we wouldn't need all those
extra resources, tools, and workarounds!
Take some library whose source uses dozens of headers scattered over a
multiple nested folders, full of conditional blocks for half a dozen
different platforms.
Say that library is made available as a shared binary, one DLL file on
Windows. That makes sense (or even one .a file). The DLL will export (if
you look inside) a linear set of functions and variables.
But to use the library from C, you will need to process all those dozens
of headers still, even though the developers' organisational choices are
completely irrelevant to us.
Wouldn't it be better, since they have already produced the one-file DLL
file for out platform, to have a compact one-file header too?
(I also had an idea to embed the header inside the DLL, that a compiler
could extract, but that would need too much cooperation.)
> Of course, for someone writing and distributing a popular library, it
> might be worth making flattened versions of their headers available as
> even a small effect is multiplied by the number of people using the
> library.
One-header libraries are popular, making them very easy to deploy.
Although usually they will contain the implementation too.
> I did a brief check of the most include-heavy file in my current
> project. There are about 160 include files going into the compile, with
> about 200 include directives executed (some headers presumably have
> include directives before their include guard). Total pre-processed
> code is 3.6 million lines, of which 400 are from the actual C++ file.
> Pre-processing takes 0.1 seconds, with the full optimised compile taking
> 0.55 seconds.
>
> "Touching" that one file, and doing "make -j" takes 1.3 seconds - it
> includes linking after the compiler. A full clean "make -j 18" rebuild
> takes 6.4 seconds in parallel. A non-parallel build takes 63 seconds.
>
> During typical development, I rebuild after changing a file. 1.3
> seconds is close enough to "instant" that it is not an issue - I make
> changes, press ctrl-S then ctrl-B, and the error markers are in the IDE
> after 0.5 seconds (there's no linking when I have compile-time errors in
> the code!). Saving a hypothetical maximum of 0.1 seconds from flattened
> headers would make no difference.
>
> But using parallel builds controlled by make, rather than serial builds,
> cuts the full build time by 90%. (Sometimes a header change triggers a
> re-compile of large parts of the code base.) Using make to handle
> dependencies and compile only when needed saves 98% of the time compared
> to full serial builds.
>
> Of course it would be nice to shave off another 10% from faster header
> handling - but it's a drop in the ocean compared to the other generic
> techniques I already use.
Yes, these are all techniques that can be used to mitigate what remains,
at heart, a slow compiler.
This seems of more priority than increasing raw compilation speeds.
But it you are processing 3.6Mloc in 0.1 seconds, then that's 36Mlps of
parsing speed, which is impressive for a big compiler, and therefore
suspect! Even if most of it is comments or skipped conditional code.
On my machine TCC processes the 82Kloc of SDL2 at only some 1.6Mlps.
Although I don't know how many of those are re-processed due to repeated
includes, even if that is skipping code between include guards.
However, I doubt it will be anywhere near the speed of your compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 14:30 +0200 |
| Message-ID | <117rjga$s9ir$7@dont-email.me> |
| In reply to | #401780 |
On 09/09/2026 13:32, bart wrote:
> On 09/09/2026 09:18, David Brown wrote:
>> On 08/09/2026 21:08, bart wrote:
>>> On 08/09/2026 17:40, Scott Lurndal wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 07/09/2026 23:50, Janis Papanagnou wrote:
>>>>
>>>> <snip>
>>>>> The duplication is a problem. If 50 modules each includes the header
>>>>> files for a library such as SDL2, then a full build means a
>>>>> scanning the
>>>>> headers 50 times, which means 4000 header files (80 unique) and 2.5M
>>>>> lines of code (50K unique).
>>>>
>>>> On a modern machine, this may add a few milliseconds to the build.
>>>
>>> I don't think so. Here is a one-file test C program:
>>>
>>> '#include <SDL3/SDL.h>'
>>>
>>> This is a test that compiles 50 copies of it:
>>>
>>> c:\sdl>tm gcc -c -I. s*.c
>>> TM: 36.59
>>>
>>> That's 36,000 milliseconds, rather more than a few. (SDL3 is not
>>> 80Kloc rather than 50Kloc.)
I only happen to have SDL2/SDL.h on my machine, but I tested that :
$ cat s1.c
#include <SDL2/SDL.h>
$ time gcc -c s1.c
real 0m0.223s
user 0m0.184s
sys 0m0.039s
$ for i in {2..50}; do cp s1.c s$i.c; done
$ time gcc -c s*.c
real 0m10.088s
user 0m8.600s
sys 0m1.483s
$ touch s*.c
$ time make -j s*.o
real 0m0.958s
user 0m14.600s
sys 0m2.206s
Compiling these 50 files on my system, in a sensible way, is about 40
times faster than yours. My cpu has 6 real cores at 5 GHz, and 8
low-power cores that might help a bit. I can believe it is inherently
faster than your PC, but not 40 times faster.
>
> I tried my SDL3 test with WSL and Windows:
>
> WSL 22.5 seconds (real)
> Windows 38 seconds (elapsed)
>
> This is that amount of files/includes described above, times 50. Tests
> were done twice and this is the faster of the two. (Yesterday the
> Windows one was 36; timings vary.)
>
> However, this doesn't tell me much about whether building on Windows is
> inherently slower, since SDL for Windows uses 'windows.h', while for
> Linux it may use X11 or whatever. Maybe the former is much larger.
>
> It's possible that your magnitude difference is because you need
> windows.h or some other MS header that will be more bloated than the
> equivalent POSIX.
Other than occasional nonsense tests like this one, I rarely do native
compilation. It's all cross-compilation for bare-metal embedded targets.
>
> Or maybe WSL is still really Windows (but I haven't seen a spectacular
> difference when I used a true Linux).
>
>
>> Trying to optimise or flatten header sets for some library would be
>> a waste of effort - the effect is too minor.
>
> If that was routinely done, then perhaps we wouldn't need all those
> extra resources, tools, and workarounds!
>
Note that in my example above, the "extra resources, tools and
workarounds" was one line.
And again, let me reiterate the numbers from my real-world use-case. In
comparison to a serial build of all files in my project, these
"workarounds" improve my builds by a factor of 50 or more, compared to
your suggestion that could at most save about 10% if it managed to
completely eliminate /all/ pre-processing time.
Using appropriate tools and development practices is not a "workaround",
it is common sense. If you were a lumberjack rather than a programmer,
you'd be using a flint axe and accusing chainsaw users as using
workarounds when really the answer is to grow trees without bark. That
really is the absurdity of your argument.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 15:09 +0100 |
| Message-ID | <117rpa8$16ttd$1@dont-email.me> |
| In reply to | #401787 |
On 09/09/2026 13:30, David Brown wrote:
> On 09/09/2026 13:32, bart wrote:
>> On 09/09/2026 09:18, David Brown wrote:
>>> On 08/09/2026 21:08, bart wrote:
>>>> On 08/09/2026 17:40, Scott Lurndal wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>>> On 07/09/2026 23:50, Janis Papanagnou wrote:
>>>>>
>>>>> <snip>
>
>>>>>> The duplication is a problem. If 50 modules each includes the header
>>>>>> files for a library such as SDL2, then a full build means a
>>>>>> scanning the
>>>>>> headers 50 times, which means 4000 header files (80 unique) and 2.5M
>>>>>> lines of code (50K unique).
>>>>>
>>>>> On a modern machine, this may add a few milliseconds to the build.
>>>>
>>>> I don't think so. Here is a one-file test C program:
>>>>
>>>> '#include <SDL3/SDL.h>'
>>>>
>>>> This is a test that compiles 50 copies of it:
>>>>
>>>> c:\sdl>tm gcc -c -I. s*.c
>>>> TM: 36.59
>>>>
>>>> That's 36,000 milliseconds, rather more than a few. (SDL3 is not
>>>> 80Kloc rather than 50Kloc.)
>
> I only happen to have SDL2/SDL.h on my machine, but I tested that :
>
> $ cat s1.c
> #include <SDL2/SDL.h>
>
>
> $ time gcc -c s1.c
>
> real 0m0.223s
> user 0m0.184s
> sys 0m0.039s
>
> $ for i in {2..50}; do cp s1.c s$i.c; done
>
> $ time gcc -c s*.c
>
> real 0m10.088s
> user 0m8.600s
> sys 0m1.483s
>
> $ touch s*.c
> $ time make -j s*.o
>
> real 0m0.958s
> user 0m14.600s
So actual CPU time is 14 seconds?
> Note that in my example above, the "extra resources, tools and
> workarounds" was one line.
No, they were invoked in one line. Otherwise you're saying NASA didn't
need the Saturn 5 rocket, just the launch button!
> And again, let me reiterate the numbers from my real-world use-case. In
> comparison to a serial build of all files in my project, these
> "workarounds" improve my builds by a factor of 50 or more, compared to
> your suggestion that could at most save about 10% if it managed to
> completely eliminate /all/ pre-processing time.
>
> Using appropriate tools and development practices is not a "workaround",
> it is common sense. If you were a lumberjack rather than a programmer,
> you'd be using a flint axe and accusing chainsaw users as using
> workarounds when really the answer is to grow trees without bark. That
> really is the absurdity of your argument.
Wrong sort of analogy and the wrong sort of approach.
Let's try this one: you have a task to do, and it takes T time on a
certain machine using a certain tool. But now you need to it 50 times so
it would take 50T.
Your solution is to buy 10 machines each 5 times as fast so that all 50
tasks still complete in time T.
To me, just throwing resources at the problem is the wrong approach. Why
aren't you looking at why the task takes T seconds in the first place?
In this case, I mentioned too approaches:
(1) Use a faster tool. I said that that TCC is considerably faster at
this stuff, taking 1.5s versus 38s on Windows. (It turns out windows.h,
while it occurs in the headers, is not actually used, so both do the
same work.)
Now, TCC is very poor at generating executable code, however we're
talking about scanning declarations! There is no code; it only has to
populate a symbol table. (Actually, there are a dozen small function defs.)
I'm not suggesting to use TCC, but gcc etc ought to work faster.
(2) Reduce the size of the task. I applied my tool to the SDL3 headers,
and the 86 files/82Kloc/3.6MB can be reduced to 1 file/4Kloc/0.18MB.
That is a *95% reduction in source code*.
Combine these two approaches, and you can be looking at a two magnitudes
improvement in *raw* compilation speed. You might need to buy a smaller
computer!
Your approach is akin to buying a 250mph supercar to get from A to B via
some long-winded, torturous route, when you can do it faster in a Model
T by being more sensible.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 16:58 +0200 |
| Message-ID | <117rs5p$170nh$1@dont-email.me> |
| In reply to | #401802 |
On 09/09/2026 16:09, bart wrote:
> On 09/09/2026 13:30, David Brown wrote:
>> On 09/09/2026 13:32, bart wrote:
>>> On 09/09/2026 09:18, David Brown wrote:
>>>> On 08/09/2026 21:08, bart wrote:
>>>>> On 08/09/2026 17:40, Scott Lurndal wrote:
>>>>>> bart <bc@freeuk.com> writes:
>>>>>>> On 07/09/2026 23:50, Janis Papanagnou wrote:
>>>>>>
>>>>>> <snip>
>>
>>>>>>> The duplication is a problem. If 50 modules each includes the header
>>>>>>> files for a library such as SDL2, then a full build means a
>>>>>>> scanning the
>>>>>>> headers 50 times, which means 4000 header files (80 unique) and 2.5M
>>>>>>> lines of code (50K unique).
>>>>>>
>>>>>> On a modern machine, this may add a few milliseconds to the build.
>>>>>
>>>>> I don't think so. Here is a one-file test C program:
>>>>>
>>>>> '#include <SDL3/SDL.h>'
>>>>>
>>>>> This is a test that compiles 50 copies of it:
>>>>>
>>>>> c:\sdl>tm gcc -c -I. s*.c
>>>>> TM: 36.59
>>>>>
>>>>> That's 36,000 milliseconds, rather more than a few. (SDL3 is not
>>>>> 80Kloc rather than 50Kloc.)
>>
>> I only happen to have SDL2/SDL.h on my machine, but I tested that :
>>
>> $ cat s1.c
>> #include <SDL2/SDL.h>
>>
>>
>> $ time gcc -c s1.c
>>
>> real 0m0.223s
>> user 0m0.184s
>> sys 0m0.039s
>>
>> $ for i in {2..50}; do cp s1.c s$i.c; done
>>
>> $ time gcc -c s*.c
>>
>> real 0m10.088s
>> user 0m8.600s
>> sys 0m1.483s
>>
>> $ touch s*.c
>> $ time make -j s*.o
>>
>> real 0m0.958s
>> user 0m14.600s
>
> So actual CPU time is 14 seconds?
That's the sum of the time the cores spent, yes. This is more than the
wall-clock time for a serial build, because there is some contention
(shared memory caches and buses, for example), and hyper-threading and
slower "low power" cores mean the parallel scaling is not linear.
But I am not bothered about how much effort my computer has to do - the
"real" time here is the wall-clock time that is vastly more relevant.
>
>
>> Note that in my example above, the "extra resources, tools and
>> workarounds" was one line.
>
> No, they were invoked in one line. Otherwise you're saying NASA didn't
> need the Saturn 5 rocket, just the launch button!
When I am compiling my project, I am not particularly interested in how
much time and effort by other people it took to have the tools. You
don't consider it a big effort to sit down in your chair - you don't
think about how much work it took to make the oil rig that drilled for
the oil that was used to make the plastic that your chair is made from.
I've got "make" and "gcc" on my computer. Using them here was one line.
I'll admit that compiling all the s*.c files, then using "s*.o" as
makefile targets could be called cheating - the files have to be there
to be matched by the wildcard for re-building. So "make -j s*.o" would
not work after a "rm s*.o". But I felt that a single-line solution to
that would be a bit distracting, even though it still shows that no
makefile was needed :
ls s*.c | sed 's/c/o/g' | xargs make -j
>
>
>> And again, let me reiterate the numbers from my real-world use-case.
>> In comparison to a serial build of all files in my project, these
>> "workarounds" improve my builds by a factor of 50 or more, compared to
>> your suggestion that could at most save about 10% if it managed to
>> completely eliminate /all/ pre-processing time.
>>
>> Using appropriate tools and development practices is not a
>> "workaround", it is common sense. If you were a lumberjack rather
>> than a programmer, you'd be using a flint axe and accusing chainsaw
>> users as using workarounds when really the answer is to grow trees
>> without bark. That really is the absurdity of your argument.
>
> Wrong sort of analogy and the wrong sort of approach.
>
> Let's try this one: you have a task to do, and it takes T time on a
> certain machine using a certain tool. But now you need to it 50 times so
> it would take 50T.
>
> Your solution is to buy 10 machines each 5 times as fast so that all 50
> tasks still complete in time T.
Imagine I already have these 10 machines that are each 5 times as fast.
Should /I/ continue to do the tasks one at a time, using the old
machine, just because /you/ think the old way is "more traditional" ?
Imagine that I have already spent a few days (spread out over years)
getting the hang of "make". Should I now not use it? Imagine I have
already purchased a computer with more than one core. Should I stick to
using just a single core? Should I throw away all my good tools, and
instead choose some weak little compiler, piss-poor excuse for an OS,
and a batch file for build control - and then moan that big header files
make builds slow?
>
> To me, just throwing resources at the problem is the wrong approach. Why
> aren't you looking at why the task takes T seconds in the first place?
I am looking at what /I/ can do to get the results I need in a timely
fashion. I am not interested in spending years making a new C compiler
just because it might be a bit faster than gcc - which sane customer
would pay me to do that? I am not interested in spending days or weeks
trying to minimise and optimise the headers from manufacturer's SDKs and
third-party libraries to shave a few percent off my built times.
Instead, I can take previously-written makefiles, adjust a bit to suit
my current project, and I've got all I need.
Now, if my job was working at a microcontroller manufacturer's
development tool department, then I might consider how to arrange header
files to improve built speeds - because lots of people could benefit.
But in practice I would be far more interested in improving the code
quality, clarity, organisation and re-usability than tiny speedups.
>
> In this case, I mentioned too approaches:
>
> (1) Use a faster tool. I said that that TCC is considerably faster at
> this stuff, taking 1.5s versus 38s on Windows. (It turns out windows.h,
> while it occurs in the headers, is not actually used, so both do the
> same work.)
>
TCC is, at best, a very niche tool. It is not an alternative for
serious development work.
> Now, TCC is very poor at generating executable code, however we're
> talking about scanning declarations! There is no code; it only has to
> populate a symbol table. (Actually, there are a dozen small function defs.)
No one cares about the speed of scanning declarations. The speed at
which actual programs are compiled can be relevant (though I have yet to
see it as an issue for my work). It doesn't matter how quickly or
slowly a computer can do a useless task.
>
> I'm not suggesting to use TCC, but gcc etc ought to work faster.
>
> (2) Reduce the size of the task. I applied my tool to the SDL3 headers,
> and the 86 files/82Kloc/3.6MB can be reduced to 1 file/4Kloc/0.18MB.
>
> That is a *95% reduction in source code*.
As I showed in my timings, in real use, that could, at most, reduce the
compile time by about 15%. It does not matter how long it takes to read
the SDL3 headers and throw them away, because it is not a useful task.
>
> Combine these two approaches, and you can be looking at a two magnitudes
> improvement in *raw* compilation speed. You might need to buy a smaller
> computer!
>
You /know/ you are talking drivel here. Either that or you are combing
a appallingly inefficient file handling with an extremely simplistic
compiler, if you think that reading the header files is the dominant
time factor for actual real-world compilation of C code.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 18:34 +0100 |
| Message-ID | <117s5b8$1bikd$1@dont-email.me> |
| In reply to | #401814 |
On 09/09/2026 15:58, David Brown wrote:
> On 09/09/2026 16:09, bart wrote:
> I am looking at what /I/ can do to get the results I need in a timely
> fashion. I am not interested in spending years making a new C compiler
> just because it might be a bit faster than gcc - which sane customer
> would pay me to do that?
I'm not saying that. But people SHOULD be more critical of how fast
their tools are, instead of just throwing more brute force at the problem.
Tiny C *does* seem to do the same task (parse huge amounts of
declarations) at least a magnitude faster than TCC. TCC wouldn't need
those extra cores. Maybe gcc wouldn't either.
You see the same thing assemblers. There, there is no backend optimising
of the kind that compilers do. Assembling is a simple, linear process.
And yet, you can see 10:1 difference in assembling the same program.
What on earth are those slow ones up to?
> I am not interested in spending days or weeks
> trying to minimise and optimise the headers from manufacturer's SDKs and
> third-party libraries to shave a few percent off my built times.
I'm not saying that either. I think people who supply the API headers
should do that.
> TCC is, at best, a very niche tool. It is not an alternative for
> serious development work.
It provides one invaluable service: it shows just how slow some
compilers are, even doing the same task.
>> Now, TCC is very poor at generating executable code, however we're
>> talking about scanning declarations! There is no code; it only has to
>> populate a symbol table. (Actually, there are a dozen small function
>> defs.)
>
> No one cares about the speed of scanning declarations. The speed at
> which actual programs are compiled can be relevant (though I have yet to
> see it as an issue for my work). It doesn't matter how quickly or
> slowly a computer can do a useless task.
And yet, precompiled headers were introduced. Why, if it is a non-issue?
>>
>> I'm not suggesting to use TCC, but gcc etc ought to work faster.
>>
>> (2) Reduce the size of the task. I applied my tool to the SDL3
>> headers, and the 86 files/82Kloc/3.6MB can be reduced to 1
>> file/4Kloc/0.18MB.
>>
>> That is a *95% reduction in source code*.
>
> As I showed in my timings, in real use, that could, at most, reduce the
> compile time by about 15%.
So it doesn't matter at all how large and bloated any library's headers are?
This attitude is why we see bloat everywhere as well as some dead-slow
applications. Maybe some people want to sell more RAM and more hardware;
that's not going to happen if existing tools are too fast!
>> Combine these two approaches, and you can be looking at a two
>> magnitudes improvement in *raw* compilation speed. You might need to
>> buy a smaller computer!
>>
>
> You /know/ you are talking drivel here. Either that or you are combing
> a appallingly inefficient file handling with an extremely simplistic
> compiler, if you think that reading the header files is the dominant
> time factor for actual real-world compilation of C code.
Certainly, the line counts of big libraries are likely to dwarf that of
many applications, and that's if you only count them once.
But if an application has N modules that import those big headers, then
they have to be processed N times.
So yes I think it can be significant. GTK4 may well approach half a
million lines now, and windows.h may be up to 200K lines.
It doesn't bother you because you've found a way to work with slow
compilers. That's fine; long ago *I* had to find a way to work with slow
hardware.
Here is a 4-line Hello program using Windows, mess.c:
#include <windows.h>
int main() {
MessageBoxA(0, "caption", "hello", 0);
}
This is how it takes to build on my Windows PC:
c:\c>tim tcc mess.c -luser32
Time: 0.044
c:\c>tim bcc mess
Compiling mess.c to mess.exe
Time: 0.035
c:\c>tim gcc mess.c
Time: 1.359
1.3 seconds for a 4-line program!
Since gcc takes 0.2 seconds even for a text hello.c, 1.1 seconds is
spent processing windows.h.
That is the reality for me and for lots of other people.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-09 18:37 +0000 |
| Message-ID | <DHhoS.17262$eXV3.13540@fx39.iad> |
| In reply to | #401827 |
bart <bc@freeuk.com> writes: >On 09/09/2026 15:58, David Brown wrote: >> On 09/09/2026 16:09, bart wrote: > >> I am looking at what /I/ can do to get the results I need in a timely >> fashion. I am not interested in spending years making a new C compiler >> just because it might be a bit faster than gcc - which sane customer >> would pay me to do that? > >I'm not saying that. But people SHOULD be more critical of how fast >their tools are, instead of just throwing more brute force at the problem. That is a strawman argument. You assume that a 50 millisecond difference in execution time is a critical issue that must be addressed, when in fact, the traditional unix tools are fast, elegent and efficient. You don't like them, fine. Don't claim that everyone else should agree with you. The days of submitting a deck of cards and waiting 24 hours for your output are long gone. > >Tiny C *does* seem to do the same task (parse huge amounts of >declarations) at least a magnitude faster than TCC. TCC wouldn't need >those extra cores. Maybe gcc wouldn't either. Neither TCC nor Tiny C can compile my code successfully. Nor would I trust them to generate production quality code. <snip> > >And yet, you can see 10:1 difference in assembling the same program. >What on earth are those slow ones up to? We've been surreptitiously adding special code to the assembler that recognizes when Bart is running it so it can randomly add a bunch of spurious sleep(3) calls just to piss you off. > >> I am not interested in spending days or weeks Then don't. Nobody else thinks that the size and organization of these header files are out of the ordinary or in any way defective. >> trying to minimise and optimise the headers from manufacturer's SDKs and >> third-party libraries to shave a few percent off my built times. > >I'm not saying that either. I think people who supply the API headers >should do that. Just to make you happy? It wouldn't work, you'd just find something else to complain about. > > >> TCC is, at best, a very niche tool. It is not an alternative for >> serious development work. > >It provides one invaluable service: it shows just how slow some >compilers are, even doing the same task. No, they're not "doing the same task". TCC will not compile my code successfully. gcc and clang will. > > >>> Now, TCC is very poor at generating executable code, however we're >>> talking about scanning declarations! There is no code; it only has to >>> populate a symbol table. (Actually, there are a dozen small function >>> defs.) >> >> No one cares about the speed of scanning declarations. The speed at >> which actual programs are compiled can be relevant (though I have yet to >> see it as an issue for my work). It doesn't matter how quickly or >> slowly a computer can do a useless task. > >And yet, precompiled headers were introduced. Why, if it is a non-issue? Because someone like you pushed for them. I'm not aware of anyone that actually uses precompiled headers.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 20:12 +0100 |
| Message-ID | <117sb2p$1dkkf$1@dont-email.me> |
| In reply to | #401830 |
On 09/09/2026 19:37, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> I'm not saying that either. I think people who supply the API headers >> should do that. > > Just to make you happy? It wouldn't work, you'd just find something > else to complain about. No, to do it Right. There is no need to expose all the machinery and innards of a developer's header files; users just need a flat API. If they include SDK.h, why exactly does it need to be 86 files rather than one? The whole thing will need processing in either case. >> >> >>> TCC is, at best, a very niche tool. It is not an alternative for >>> serious development work. >> >> It provides one invaluable service: it shows just how slow some >> compilers are, even doing the same task. > > No, they're not "doing the same task". TCC will not compile > my code successfully. gcc and clang will. You're ignoring the point: it shows that 4 million lines of headers can be parsed 20 times faster gcc. There is little executable code here.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 22:11 +0200 |
| Message-ID | <117sei5$3r5qn$9@dont-email.me> |
| In reply to | #401830 |
On 2026-09-09 20:37, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: > The days of submitting a deck of cards and waiting 24 hours for your > output are long gone. Hey, where have you been working? - We regularly waited less than 1 hour to get the output from our card decks! - Upgrade your systems or employ more admins. ;-} [...] >> >> And yet, precompiled headers were introduced. Why, if it is a non-issue? > > Because someone like you pushed for them. I'm not aware of anyone > that actually uses precompiled headers. I have to admit that my memories are faint here, but I seem to recall that we took advantage from precompiled headers. And, sadly, I cannot tell whether it were "someone [like you]" (the customers) that "pushed" the demand or whether the vendors recognized that feature (whether by customer feedback or by own investigation). (If you have some substantial evidence about that I'd like to hear.) Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-09 21:15 +0000 |
| Message-ID | <A%joS.30364$4Fj3.12774@fx21.iad> |
| In reply to | #401837 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 2026-09-09 20:37, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>
>> The days of submitting a deck of cards and waiting 24 hours for your
>> output are long gone.
>
>Hey, where have you been working? - We regularly waited less than 1
>hour to get the output from our card decks! - Upgrade your systems
>or employ more admins. ;-}
>
>[...]
>>>
>>> And yet, precompiled headers were introduced. Why, if it is a non-issue?
>>
>> Because someone like you pushed for them. I'm not aware of anyone
>> that actually uses precompiled headers.
>
>I have to admit that my memories are faint here, but I seem to recall
>that we took advantage from precompiled headers.
>
>And, sadly, I cannot tell whether it were "someone [like you]" (the
>customers) that "pushed" the demand or whether the vendors recognized
>that feature (whether by customer feedback or by own investigation).
>
>(If you have some substantial evidence about that I'd like to hear.)
It does appear to be used by MSVC somewhat automatically, but it's been
three decades since I wrote any Windows code (and it was driver code for
NT 3.51).
Other restrictions on the GCC implementation include:
Include order matters: The PCH must be the absolute first token the
compiler encounters. You cannot put any code, variable declarations,
or macro defines before it.
One per compilation: Only one precompiled header can be used in a particular
compilation.
Identical flags: The .gch file must be built using the exact same flags
(e.g., -O3, -g, -std=c++20, -m64) as the source files using it.
Matching compiler binary: You must use the exact same compiler version to
build the PCH and the final executable
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 23:37 +0200 |
| Message-ID | <117sjjc$3r5qn$11@dont-email.me> |
| In reply to | #401841 |
On 2026-09-09 23:15, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-09-09 20:37, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >> >>> The days of submitting a deck of cards and waiting 24 hours for your >>> output are long gone. >> >> Hey, where have you been working? - We regularly waited less than 1 >> hour to get the output from our card decks! - Upgrade your systems >> or employ more admins. ;-} >> >> [...] >>>> >>>> And yet, precompiled headers were introduced. Why, if it is a non-issue? >>> >>> Because someone like you pushed for them. I'm not aware of anyone >>> that actually uses precompiled headers. >> >> I have to admit that my memories are faint here, but I seem to recall >> that we took advantage from precompiled headers. >> >> And, sadly, I cannot tell whether it were "someone [like you]" (the >> customers) that "pushed" the demand or whether the vendors recognized >> that feature (whether by customer feedback or by own investigation). >> >> (If you have some substantial evidence about that I'd like to hear.) > > It does appear to be used by MSVC somewhat automatically, but it's been > three decades since I wrote any Windows code (and it was driver code for > NT 3.51). > > Other restrictions on the GCC implementation include: > > Include order matters: The PCH must be the absolute first token the > compiler encounters. You cannot put any code, variable declarations, > or macro defines before it. > > One per compilation: Only one precompiled header can be used in a particular > compilation. > > Identical flags: The .gch file must be built using the exact same flags > (e.g., -O3, -g, -std=c++20, -m64) as the source files using it. > > Matching compiler binary: You must use the exact same compiler version to > build the PCH and the final executable Our usages were back in the 1990's on commercial Unix systems. The precompiled headers feature was (in our C++ context) just there, but not per default, it needed some option (or so) to make use of them. I don't recall any organizational restrictions with their use. They were obviously considered worthwhile (or even necessary) by the vendors to be provided for their customers for performance reasons in projects of non-trivial size. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 21:39 +0200 |
| Message-ID | <117scm8$1dkqe$1@dont-email.me> |
| In reply to | #401827 |
On 09/09/2026 19:34, bart wrote: > On 09/09/2026 15:58, David Brown wrote: >> On 09/09/2026 16:09, bart wrote: > >> I am looking at what /I/ can do to get the results I need in a timely >> fashion. I am not interested in spending years making a new C >> compiler just because it might be a bit faster than gcc - which sane >> customer would pay me to do that? > > I'm not saying that. But people SHOULD be more critical of how fast > their tools are, instead of just throwing more brute force at the problem. > That could make sense if there was a wide selection of tools to choose from. The options in my line of work are gcc, clang (which is not as mature in the field, and not significantly faster to use), or one of a few very expensive commercial toolchains that are not faster to use, have fewer features, are significantly behind the times in standards support, are often slower to fix bugs, and much less practical due to unpleasant security locks. (They can sometimes be useful for providing arse-coverage in court cases, however - "The bugs that lead to your car crashing are not our fault - we used the most expensive tools available".) The simple fact is that good quality C compilers, with good static analysis, good error messages, solid optimisations, standards support, and useful (for many uses, essential) extensions need to do a lot of work. That takes time. There is always scope for making tools a bit faster, at least. And that happens to some extent. Competition from the newbie clang/llvm lead to gcc putting a little more effort into speed of compilation, and a lot more effort into the quality of warning messages (especially in C++), as people saw that clang did better there. Then as clang got stronger optimisations and error analysis to compete with gcc, it slowed down - now they have a fair degree of similarity. Compiler developers have limited time and resources, just like everyone else. When they are prioritising tool speed, they do so where it matters most - the link-time optimisation. The speed of simple C compilation is fast enough that it usually doesn't matter, so they priorities better static analysis, better code generation, support for newer standards, bug fixes - things that really matter to users. Sure, I'd be happier if gcc were faster. But it's not in my top twenty list of things I'd like to see improved in the toolchain. I've occasionally filed bugs / issues with suggestions, and at least once had my suggestion directly used to improve the toolchain (IMHO, of course) - simply filing a request "make the compiler faster" is unlikely to be considered helpful. > Tiny C *does* seem to do the same task (parse huge amounts of > declarations) at least a magnitude faster than TCC. TCC wouldn't need > those extra cores. Maybe gcc wouldn't either. > > You see the same thing assemblers. There, there is no backend optimising > of the kind that compilers do. Assembling is a simple, linear process. > > And yet, you can see 10:1 difference in assembling the same program. > What on earth are those slow ones up to? > It's not hard to make programs that are slow for a particular task. Once you have reached a certain point, however, it's far harder to make them much faster. I believe there was a mainstream assembler that had a particularly poor algorithm somewhere, resulting in surprisingly long run times once input was over a certain size. I don't imagine it is a general problem, however. >> I am not interested in spending days or weeks trying to minimise and >> optimise the headers from manufacturer's SDKs and third-party >> libraries to shave a few percent off my built times. > > I'm not saying that either. I think people who supply the API headers > should do that. > Again, I'd be happy with that - but again, it would not make my top-twenty list of things I'd rather the spend time on if they want to make a better SDK. > >> TCC is, at best, a very niche tool. It is not an alternative for >> serious development work. > > It provides one invaluable service: it shows just how slow some > compilers are, even doing the same task. > I don't know how often it needs repeating - tcc is not doing the same job as gcc (or clang, or MSVC, or other serious compilers). That's not an insult to the tool or its developers, it's just a different tool with very different priorities. > >>> Now, TCC is very poor at generating executable code, however we're >>> talking about scanning declarations! There is no code; it only has to >>> populate a symbol table. (Actually, there are a dozen small function >>> defs.) >> >> No one cares about the speed of scanning declarations. The speed at >> which actual programs are compiled can be relevant (though I have yet >> to see it as an issue for my work). It doesn't matter how quickly or >> slowly a computer can do a useless task. > > And yet, precompiled headers were introduced. Why, if it is a non-issue? > They are primarily for C++, not C. Reading in big C++ headers is a totally different scale of operation from reading C headers of the same line count. > >>> >>> I'm not suggesting to use TCC, but gcc etc ought to work faster. >>> >>> (2) Reduce the size of the task. I applied my tool to the SDL3 >>> headers, and the 86 files/82Kloc/3.6MB can be reduced to 1 >>> file/4Kloc/0.18MB. >>> >>> That is a *95% reduction in source code*. >> >> As I showed in my timings, in real use, that could, at most, reduce >> the compile time by about 15%. > > So it doesn't matter at all how large and bloated any library's headers > are? > Again - I would always be happier if they were smaller or better organised. Of course I would prefer a 15% speedup if it were freely available without reduction of functionality or features. But it is not a matter that concerns me. I'd rather see effort put into improving the quality (in various aspects) of headers I need to use than. > This attitude is why we see bloat everywhere as well as some dead-slow > applications. Maybe some people want to sell more RAM and more hardware; > that's not going to happen if existing tools are too fast! You still don't understand. No one is looking for "bloat" or slow tools. But once something is fast enough for what you want, making it faster or smaller should not be a major priority. If I felt I spent a lot of time waiting for my builds, I would want them to be faster - but I don't have to wait for them. There are plenty of other things I'd rather get annoyed about instead.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 21:39 +0100 |
| Message-ID | <117sg5h$1fbn7$1@dont-email.me> |
| In reply to | #401835 |
On 09/09/2026 20:39, David Brown wrote:
> On 09/09/2026 19:34, bart wrote:
>> You see the same thing [with] assemblers. There, there is no backend
>> optimising of the kind that compilers do. Assembling is a simple,
>> linear process.
>>
>> And yet, you can see 10:1 difference in assembling the same program.
>> What on earth are those slow ones up to?
>>
>
> It's not hard to make programs that are slow for a particular task. Once
> you have reached a certain point, however, it's far harder to make them
> much faster. I believe there was a mainstream assembler that had a
> particularly poor algorithm somewhere, resulting in surprisingly long
> run times once input was over a certain size. I don't imagine it is a
> general problem, however.
NASM, MASM, or both?
I know there is a long standing bug in NASM which leads to result like
these, for this 270Kloc input (actually, an SQL test compiled into three
different x64 ASM formats):
nasm -O0 -fwin64 250 seconds (to .obj)
yasm -fwin64 1.06 seconds (to .obj)
as 0.65 seconds (to .o)
aa 0.10 seconds (to .exe)
Obviously, 'aa' is my product. And clearly, NASM has something wrong.
(Without -O0, it would be 60% slower!)
MASM (as 'ml64.exe') had its own bug to do with using RESB in a .DATA
segment; it got exponentially slower with the size of the block. (I no
longer have it to test.)
For whole-program compilers that generate a single ASM file, assembly
speed is critical.
[toc] | [prev] | [next] | [standalone]
Page 2 of 25 — ← Prev page 1 [2] 3 4 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web