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 20 of 25 — ← Prev page 1 … 18 19 [20] 21 22 … 25 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-18 11:13 +0100 |
| Message-ID | <118j2si$160ub$1@dont-email.me> |
| In reply to | #402219 |
On 18/09/2026 11:05, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> But I /can/ tell you exactly how my own C implementation for Windows >> works. > > But I don't care. > Sure, you don't care how simple it is and how easy to give the whole picture of how it works. Or how, knowing that picture, anyone can see how they can install or copy this compiler anywhere. Or how much easier it is to see where the lines are: the implementation owns its standard headers, not the OS. And the OS provides the C library. This simplicity and transparency is by design.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-16 17:33 +0000 |
| Message-ID | <xpAqS.65705$k62.25402@fx14.iad> |
| In reply to | #402124 |
bart <bc@freeuk.com> writes: >On 16/09/2026 12:47, David Brown wrote: >> On 16/09/2026 12:21, bart wrote: > >>> The recent example of those SDL3 headers is a good one. Even without >>> needing to change the C language, or have super-fast compilers for it, >>> those headers are grossly inefficient. >> >> So what? >> >> I did the timings there. The savings achievable from "instant" headers >> would be tiny fractions of a second. > >I don't really trust your figures. I've today done a mock-up of a >streamlined header for SDL3. > >In this form it is a file of just over 6K lines (probably there's stuff >that doesn't need to be there, but it will suffice for this test). > >So here are my figures for a single 'hello-world' test for SDL3: > > sdl.h newsdl.h (normal vs compact) >gcc 0.88 seconds 0.34 seconds That seems to be "tiny fractions of a second" to me. Pointless optimization for no appreciable return, almost in the noise.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 19:19 +0100 |
| Message-ID | <118emjm$3kkjd$1@dont-email.me> |
| In reply to | #402129 |
On 16/09/2026 18:33, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 16/09/2026 12:47, David Brown wrote: >>> On 16/09/2026 12:21, bart wrote: >> >>>> The recent example of those SDL3 headers is a good one. Even without >>>> needing to change the C language, or have super-fast compilers for it, >>>> those headers are grossly inefficient. >>> >>> So what? >>> >>> I did the timings there. The savings achievable from "instant" headers >>> would be tiny fractions of a second. >> >> I don't really trust your figures. I've today done a mock-up of a >> streamlined header for SDL3. >> >> In this form it is a file of just over 6K lines (probably there's stuff >> that doesn't need to be there, but it will suffice for this test). >> >> So here are my figures for a single 'hello-world' test for SDL3: >> >> sdl.h newsdl.h (normal vs compact) >> gcc 0.88 seconds 0.34 seconds > > That seems to be "tiny fractions of a second" to me. Pointless > optimization for no appreciable return, almost in the noise. > This is for *one* C source file that contains little more than that header. Typically there are multiple source files containing code of their own that need compiling, and which might need there own header. This is spending the best part of a second compiling 1300 function signatures; this is 1980s machine speed. You seem to be involved in developing new, higher performance processors, and yet you're happy to all see all that power wasted because people who write these bloated messes of code are so fucking lazy.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-16 18:34 +0000 |
| Message-ID | <MiBqS.249308$ORN1.55542@fx24.iad> |
| In reply to | #402131 |
bart <bc@freeuk.com> writes: >On 16/09/2026 18:33, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 16/09/2026 12:47, David Brown wrote: >>>> On 16/09/2026 12:21, bart wrote: >>> >>>>> The recent example of those SDL3 headers is a good one. Even without >>>>> needing to change the C language, or have super-fast compilers for it, >>>>> those headers are grossly inefficient. >>>> >>>> So what? >>>> >>>> I did the timings there. The savings achievable from "instant" headers >>>> would be tiny fractions of a second. >>> >>> I don't really trust your figures. I've today done a mock-up of a >>> streamlined header for SDL3. >>> >>> In this form it is a file of just over 6K lines (probably there's stuff >>> that doesn't need to be there, but it will suffice for this test). >>> >>> So here are my figures for a single 'hello-world' test for SDL3: >>> >>> sdl.h newsdl.h (normal vs compact) >>> gcc 0.88 seconds 0.34 seconds >> >> That seems to be "tiny fractions of a second" to me. Pointless >> optimization for no appreciable return, almost in the noise. >> > >This is for *one* C source file that contains little more than that >header. Typically there are multiple source files containing code of >their own that need compiling, and which might need there own header. > >This is spending the best part of a second compiling 1300 function >signatures; this is 1980s machine speed. Sure. Pull the other one. Early 80's compilers were often limited by the speed of the input file (e.g. 300 lines-per-minute compile speeds with a 300CPM card reader). > >You seem to be involved in developing new, higher performance >processors, and yet you're happy to all see all that power wasted >because people who write these bloated messes of code are so fucking lazy. Actually none of that power is wasted, because 99.999% of the available processor cycles are running compiled application code, not compiling code. Compiling code is in the noise when considering modern workloads on PCs or servers.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 20:21 +0100 |
| Message-ID | <118eq7g$3m37a$1@dont-email.me> |
| In reply to | #402133 |
On 16/09/2026 19:34, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 16/09/2026 18:33, Scott Lurndal wrote: >>> bart <bc@freeuk.com> writes: >>>> On 16/09/2026 12:47, David Brown wrote: >>>>> On 16/09/2026 12:21, bart wrote: >>>> >>>>>> The recent example of those SDL3 headers is a good one. Even without >>>>>> needing to change the C language, or have super-fast compilers for it, >>>>>> those headers are grossly inefficient. >>>>> >>>>> So what? >>>>> >>>>> I did the timings there. The savings achievable from "instant" headers >>>>> would be tiny fractions of a second. >>>> >>>> I don't really trust your figures. I've today done a mock-up of a >>>> streamlined header for SDL3. >>>> >>>> In this form it is a file of just over 6K lines (probably there's stuff >>>> that doesn't need to be there, but it will suffice for this test). >>>> >>>> So here are my figures for a single 'hello-world' test for SDL3: >>>> >>>> sdl.h newsdl.h (normal vs compact) >>>> gcc 0.88 seconds 0.34 seconds >>> >>> That seems to be "tiny fractions of a second" to me. Pointless >>> optimization for no appreciable return, almost in the noise. >>> >> >> This is for *one* C source file that contains little more than that >> header. Typically there are multiple source files containing code of >> their own that need compiling, and which might need there own header. >> >> This is spending the best part of a second compiling 1300 function >> signatures; this is 1980s machine speed. > > Sure. Pull the other one. Early 80's compilers were often > limited by the speed of the input file (e.g. 300 lines-per-minute > compile speeds with a 300CPM card reader). I think it's you who's having a laugh. I said 1980s not 70s or 60s. In the 80s my own compilers probably managed some thousands of lines per seconds, running on microprocessors. They also all had at least floppy disk, and often hard drives. >> >> You seem to be involved in developing new, higher performance >> processors, and yet you're happy to all see all that power wasted >> because people who write these bloated messes of code are so fucking lazy. > > Actually none of that power is wasted, because 99.999% of the available > processor cycles are running compiled application code, not compiling code. > > Compiling code is in the noise when considering modern workloads > on PCs or servers. I'm sorry but it sounds very much like you don't have a clue. Just because your own builds take 10 minutes/elapsed and 75 minutes/cpu or whatever it was, you consider a 10-second build to be 'noise'? That's just your bad luck (if it is luck; more likely you're not curious enough to find the reason). In ten seconds I expect 30-50MB of compiled binary even on my slow machine. If it's taking that long to do very little, then there is something wrong.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-16 13:16 +0000 |
| Message-ID | <118e4qm$1v8pr$1@paganini.bofh.team> |
| In reply to | #402120 |
bart <bc@freeuk.com> wrote:
> On 16/09/2026 08:08, David Brown wrote:
>> On 15/09/2026 22:56, bart wrote:
>
> The recent example of those SDL3 headers is a good one. Even without
> needing to change the C language, or have super-fast compilers for it,
> those headers are grossly inefficient.
>
> That is something that could be partly be tackled by the people who
> distribute the header files, but more could also be done by those who
> create the tools.
>
> For example:
>
> * There are 86 files/82K lines of headers, counted statically, but
> nearly 500 dynamic #includes are done, scanning or skipping over half a
> million lines of declarations
Do SDL3 use include guards? The expected convention is that header
looks like:
#ifndef XXXXXX
#define XXXXXX
...
#endif
with possibly some trivial variation. That first non-comment thing
in a header is a test and the whole body is inside a conditional.
Assuming that SDL3 is doing this (and if not you should complain to
them), then your compiler could recognize this pattern and skip
the header when it is included second time. For this you need to
recognize when two paths lead to the same file, recognize the test
and check that test is indeed false when doing second include.
Some headers may be intentionally included multiple times, but
with include guards you should be able to include most files just
once. IIUC both GCC and TCC handle this.
> * Yet they contain only about 4000 lines of actual information necessary
> to compile a program that uses that library. This is 1% of the lines
> that are scanned.
>
> * For a start, half the source is comments. Why are comments even needed
> for a header meant to be consumed by machine? There are surely separate
> docs! If they are for the SDL3 developers, then somebody using the
> library *is not the developer*!
If you are developing an application you sometimes need to look
at content of the headers. Comments presumably make it easier to
understand the headers. Concerning documentation, this is derived
thing, which hopefully agrees with the sources, but actual source
is the ultimate truth and looking at source is more reliable (even if
harder) than looking at documentation.
> * There are thousands of /static/ conditional blocks (and a lot more
> encountered dynamically) all testing the same invariants over and over
> again.
>
> For example, once it is established that the compiler is not __MSCVER__,
> you don't need to test that (and to skip over blocks only relevant to
> that platform) 100 more times.
>
> So this could be done by recognising that a compact, streamlined API,
> dedicated to a particular platform (and maybe compiler) would be far better.
>
> But because that would mean many versions (more than the number of
> DLLs/.sos for different targets for example), this sounds like a
> compiler task.
I guess that smart compiler could create streamlined version of headers.
That could be done when istalling the library. Or maybe the compiler
could have a cache of streamline versions and use cached result
when it is newer than library headers. As saying goes, this is
small matter of programming. So somebody needs to implement it.
And take into account that this should work without need of cooperation
of all involved parties. Namely, if one compiler implement needed
features, there is no warranty that other will do the same. And
without support in all compilers library authors normally would
write code for the lowest common denominator, that is assume no
special support (and the same for packagers). You can not expect
special action from users, most of them will just do what they
learned as "standard commands" and "let computer do the rest"
regardless how much CPU time it takes.
> Most compilers already have an -E option to generate preprocessed source
> code. What is needed is say a -H option which does not discard
> information that a compiler still needs, if using an AOT-preprocessed
> header.
>
> Mostly this will be #defines. So it would not be too difficult. (Just
> tricky as SDL3 uses lots of #undefines too.)
Combine '#undefine' with conditionals unknown at preprocessing time
and the problem becomes more interesting. IIUC developers of major
comilers gave up at this point.
> Maybe you don't think this is interesting or relevant or you think it is
> a waste of time. But if someone decided to add this to your favourite
> compiler I bet you would use it!
>
> In this case, it would reduce header code that needs to be processed
> /per module/, by some 99%, not 95%.
>
> Note that this is the same sort of principle as gcc's precompiled
> headers. But that doesn't simplify the headers at all; just
> pre-tokenises or something. The 3.6MB of SDL3 headers turn into one
> giant 30MB file. My approach would reduce them to one file of perhaps 0.2MB.
IIUC GCC precompiled header is simplified quite a lot, for example
all preprocessor conditonals are removed and replaced by resulting
expansion. Size may be just consequence of how this works. IIUC
GCC just dump memory containing internal representation of content
if the header. Given that modern machines have high memory bandwidth,
loading it is pretty efficient.
You mentioned 4000 nontivial lines, which probably means 4000 declarations.
Internally GCC represents this as tree nodes and rather conservative
estimate is that GCC needs 3 nodes per declaration. GCC tree nodes
need probably about 100 bytes each (they contain several pointers),
so that alone would imply about 1MB.
GCC now prints rather detailed information about includes when printing
error messages, so there must be enough additional information
to track back result of expansion to the sources. And given that
GCC uses memory dump, it is likely to contain some unneded garbage.
At first glance 30 MB looks like a lot, but in advanced compiler
you need a lot of information. And there is always a compromise:
storing info means that it is "immediately" available, recomputing
means that you can avoid memory acceses (which are expensive if
you miss the cache). IIUC a lot of effort of GCC developers went
into recomputing what can be cheaply recomputed, using packed
representations and discarding not needed information. But
a lot needs to be stored to avoid making GCC slower than it is.
And the dump approach was chosen as the fastest one.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 15:26 +0100 |
| Message-ID | <118e8u6$3f3kt$1@dont-email.me> |
| In reply to | #402123 |
On 16/09/2026 14:16, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 16/09/2026 08:08, David Brown wrote: >>> On 15/09/2026 22:56, bart wrote: >> >> The recent example of those SDL3 headers is a good one. Even without >> needing to change the C language, or have super-fast compilers for it, >> those headers are grossly inefficient. >> >> That is something that could be partly be tackled by the people who >> distribute the header files, but more could also be done by those who >> create the tools. >> >> For example: >> >> * There are 86 files/82K lines of headers, counted statically, but >> nearly 500 dynamic #includes are done, scanning or skipping over half a >> million lines of declarations > > Do SDL3 use include guards? The expected convention is that header > looks like: > > #ifndef XXXXXX > #define XXXXXX > ... > #endif > > with possibly some trivial variation. That first non-comment thing > in a header is a test and the whole body is inside a conditional. Guards are used, but conditional must still be skipped, not that simple as a closing '#endif' for example must match, or some could be inside comments. > > Assuming that SDL3 is doing this (and if not you should complain to > them), then your compiler could recognize this pattern and skip > the header when it is included second time. For this you need to > recognize when two paths lead to the same file, recognize the test > and check that test is indeed false when doing second include. > > Some headers may be intentionally included multiple times, but > with include guards you should be able to include most files just > once. IIUC both GCC and TCC handle this. > >> * Yet they contain only about 4000 lines of actual information necessary >> to compile a program that uses that library. This is 1% of the lines >> that are scanned. >> >> * For a start, half the source is comments. Why are comments even needed >> for a header meant to be consumed by machine? There are surely separate >> docs! If they are for the SDL3 developers, then somebody using the >> library *is not the developer*! > > If you are developing an application you sometimes need to look > at content of the headers. Comments presumably make it easier to > understand the headers. Concerning documentation, this is derived > thing, which hopefully agrees with the sources, but actual source > is the ultimate truth and looking at source is more reliable (even if > harder) than looking at documentation. > >> * There are thousands of /static/ conditional blocks (and a lot more >> encountered dynamically) all testing the same invariants over and over >> again. >> >> For example, once it is established that the compiler is not __MSCVER__, >> you don't need to test that (and to skip over blocks only relevant to >> that platform) 100 more times. >> >> So this could be done by recognising that a compact, streamlined API, >> dedicated to a particular platform (and maybe compiler) would be far better. >> >> But because that would mean many versions (more than the number of >> DLLs/.sos for different targets for example), this sounds like a >> compiler task. > > I guess that smart compiler could create streamlined version of headers. > That could be done when istalling the library. Or maybe the compiler > could have a cache of streamline versions and use cached result > when it is newer than library headers. As saying goes, this is > small matter of programming. So somebody needs to implement it. > And take into account that this should work without need of cooperation > of all involved parties. Namely, if one compiler implement needed > features, there is no warranty that other will do the same. And > without support in all compilers library authors normally would > write code for the lowest common denominator, that is assume no > special support (and the same for packagers). You can not expect > special action from users, most of them will just do what they > learned as "standard commands" and "let computer do the rest" > regardless how much CPU time it takes. > >> Most compilers already have an -E option to generate preprocessed source >> code. What is needed is say a -H option which does not discard >> information that a compiler still needs, if using an AOT-preprocessed >> header. >> >> Mostly this will be #defines. So it would not be too difficult. (Just >> tricky as SDL3 uses lots of #undefines too.) > > Combine '#undefine' with conditionals unknown at preprocessing time > and the problem becomes more interesting. IIUC developers of major > comilers gave up at this point. > >> Maybe you don't think this is interesting or relevant or you think it is >> a waste of time. But if someone decided to add this to your favourite >> compiler I bet you would use it! >> >> In this case, it would reduce header code that needs to be processed >> /per module/, by some 99%, not 95%. >> >> Note that this is the same sort of principle as gcc's precompiled >> headers. But that doesn't simplify the headers at all; just >> pre-tokenises or something. The 3.6MB of SDL3 headers turn into one >> giant 30MB file. My approach would reduce them to one file of perhaps 0.2MB. > > IIUC GCC precompiled header is simplified quite a lot, for example > all preprocessor conditonals are removed and replaced by resulting > expansion. Size may be just consequence of how this works. IIUC > GCC just dump memory containing internal representation of content > if the header. Given that modern machines have high memory bandwidth, > loading it is pretty efficient. > > You mentioned 4000 nontivial lines, which probably means 4000 declarations. > Internally GCC represents this as tree nodes and rather conservative > estimate is that GCC needs 3 nodes per declaration. GCC tree nodes > need probably about 100 bytes each (they contain several pointers), > so that alone would imply about 1MB. > > GCC now prints rather detailed information about includes when printing > error messages, so there must be enough additional information > to track back result of expansion to the sources. And given that > GCC uses memory dump, it is likely to contain some unneded garbage. > > At first glance 30 MB looks like a lot, but in advanced compiler > you need a lot of information. And there is always a compromise: > storing info means that it is "immediately" available, recomputing > means that you can avoid memory acceses (which are expensive if > you miss the cache). IIUC a lot of effort of GCC developers went > into recomputing what can be cheaply recomputed, using packed > representations and discarding not needed information. But > a lot needs to be stored to avoid making GCC slower than it is. > And the dump approach was chosen as the fastest one. See my post of a few minutes ago where I give the results of my experiments. >
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-16 15:58 +0000 |
| Message-ID | <118eeam$1vjnt$1@paganini.bofh.team> |
| In reply to | #402125 |
bart <bc@freeuk.com> wrote:
> On 16/09/2026 14:16, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 16/09/2026 08:08, David Brown wrote:
>>>> On 15/09/2026 22:56, bart wrote:
>>>
>>> The recent example of those SDL3 headers is a good one. Even without
>>> needing to change the C language, or have super-fast compilers for it,
>>> those headers are grossly inefficient.
>>>
>>> That is something that could be partly be tackled by the people who
>>> distribute the header files, but more could also be done by those who
>>> create the tools.
>>>
>>> For example:
>>>
>>> * There are 86 files/82K lines of headers, counted statically, but
>>> nearly 500 dynamic #includes are done, scanning or skipping over half a
>>> million lines of declarations
>>
>> Do SDL3 use include guards? The expected convention is that header
>> looks like:
>>
>> #ifndef XXXXXX
>> #define XXXXXX
>> ...
>> #endif
>>
>> with possibly some trivial variation. That first non-comment thing
>> in a header is a test and the whole body is inside a conditional.
>
> Guards are used, but conditional must still be skipped, not that simple
> as a closing '#endif' for example must match, or some could be inside
> comments.
Of course you need to parse the file at least one time. But once
you parsed file once and checked that it has correct include guard
you mark it as having the guard and store test expression.
Next time when the same file is included you just look in compiler
tables and see that file has include guard. Then you verify the test
condition. If everthing is OK (as it should be) you can skip
the file on second and subsequent readings. According to your
data instead of reading and parsing 0.5M lines you can limit
this to 82K lines. Maybe not as good as your "compressed"
header idea, but this works transparently with existing C sources.
Note: above the assumption is that file did not change between
two times when you should read it. I think that this is reasonable
assumption. IIUC C standard leaves specific properties there
to the implementation and given variation in compiler speed
I do not think that anyone can usefuly modify headers during
compilation. With assumption that header was not modified,
the matching '#endif' must be in the same place as during
first reading.
>> Assuming that SDL3 is doing this (and if not you should complain to
>> them), then your compiler could recognize this pattern and skip
>> the header when it is included second time. For this you need to
>> recognize when two paths lead to the same file, recognize the test
>> and check that test is indeed false when doing second include.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 19:13 +0100 |
| Message-ID | <118em83$3kgbp$1@dont-email.me> |
| In reply to | #402128 |
On 16/09/2026 16:58, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 16/09/2026 14:16, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>> On 16/09/2026 08:08, David Brown wrote:
>>>>> On 15/09/2026 22:56, bart wrote:
>>>>
>>>> The recent example of those SDL3 headers is a good one. Even without
>>>> needing to change the C language, or have super-fast compilers for it,
>>>> those headers are grossly inefficient.
>>>>
>>>> That is something that could be partly be tackled by the people who
>>>> distribute the header files, but more could also be done by those who
>>>> create the tools.
>>>>
>>>> For example:
>>>>
>>>> * There are 86 files/82K lines of headers, counted statically, but
>>>> nearly 500 dynamic #includes are done, scanning or skipping over half a
>>>> million lines of declarations
>>>
>>> Do SDL3 use include guards? The expected convention is that header
>>> looks like:
>>>
>>> #ifndef XXXXXX
>>> #define XXXXXX
>>> ...
>>> #endif
>>>
>>> with possibly some trivial variation. That first non-comment thing
>>> in a header is a test and the whole body is inside a conditional.
>>
>> Guards are used, but conditional must still be skipped, not that simple
>> as a closing '#endif' for example must match, or some could be inside
>> comments.
>
> Of course you need to parse the file at least one time. But once
> you parsed file once and checked that it has correct include guard
An include guard looks the same as any other conditional block. There
may be dozens in the same file.
So here some analysis that a guard, which may have comments before and
after, has a particular pattern and applies to the whole file.
In any case, my stats show that 400K lines are still part of normal
processing, while 150K lines are skipped due to false conditional blocks.
This is despite those guards being everywhere. Here's an include
structure for one header, 'sdl_init.h', which is one of a list of 60
includes in stl.h:
#include sdl.h
#include sdl_init.h
#include sdl_stdinc.h
#include sdl_platform_defines.h
#include sdl_begin_code.h
#include sdl_close_code.h
#include sdl_error.h
#include sdl_stdinc.h
#include sdl_begin_code.h
#include sdl_close_code.h
#include sdl_events.h
#include sdl_stdinc.h
#include sdl_audio.h
#include sdl_stdinc.h
#include sdl_endian.h
#include sdl_stdinc.h
...
#include sdl_error.h
#include sdl_mutex.h
#include sdl_properties.h
#include sdl_iostream.h
13 more includes within sdl_events
#include sdl_begin_code.h
#include sdl_close_code.h
I haven't bothered expanding all of them, and haven't included non-SDL
headers.
Every one of those has a guard. So, does that mean that the body of
'SDL_stdinc.h' for example should only ever be encountered once?
I tested this by inserting a function body just after the guard of
stl_stdinc.h. First I wrote it twice, to ensure it generated an error.
Then I went back to one definition. This was fine, so the guards work.
In that case, what the hell is it spending 400000 lines processing?!
Some more investigation is needed via special tracking info added to my
compiler. I will update this later.
But in the meantime, just look at that tree: this is just for one top
level-header, and is not even fully expanded. It's horrible mess, and
that's without develving into the contents.
Even if the library needs to be split into 60-80 parts for development
reasons, this is over the top. And the user is still is not interested
in those 60 parts, just the one library called 'SDL'.
The headers actually define these entities (figures approx, derived from
the tool that generates my bindings):
1300 Functions (1050 functions and 250 procedures
350 Named constants (defined from #defines)
1100 Enumerations
260 Struct definitions
There's another stuff, like typedefs, and 15 actual function
definitions. But the above is 3000 lines at one per line (plus some 1000
more lines for struct fields).
If I look at SDL3.DLL, it exports exactly 1270 functions, and no variables.
Clearly all that's needed are signatures for those functions, plus any
typedefs, structs, #defines and enums that are used. Exactly what my
tool extracts.
>>> Assuming that SDL3 is doing this (and if not you should complain to
>>> them), then your compiler could recognize this pattern and skip
>>> the header when it is included second time. For this you need to
>>> recognize when two paths lead to the same file, recognize the test
>>> and check that test is indeed false when doing second include.
>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-16 18:30 +0000 |
| Message-ID | <OeBqS.249307$ORN1.97631@fx24.iad> |
| In reply to | #402130 |
bart <bc@freeuk.com> writes: >On 16/09/2026 16:58, Waldek Hebisch wrote: >> bart <bc@freeuk.com> wrote: <snip> >Every one of those has a guard. So, does that mean that the body of >'SDL_stdinc.h' for example should only ever be encountered once? > Cf. #pragma once
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 20:30 +0100 |
| Message-ID | <118eqok$3m9nf$1@dont-email.me> |
| In reply to | #402130 |
On 16/09/2026 19:13, bart wrote: > On 16/09/2026 16:58, Waldek Hebisch wrote: > In any case, my stats show that 400K lines are still part of normal > processing, while 150K lines are skipped due to false conditional blocks. > > Then I went back to one definition. This was fine, so the guards work. > In that case, what the hell is it spending 400000 lines processing?! > > Some more investigation is needed via special tracking info added to my > compiler. I will update this later. The problem was block- and line-comments. Their line-count was added to the total for normal tokenising and not that for skipping over false blocks, since both share the same comment routines. And there are a lot of comments, including quite a few outside the guards. I think 380K lines of comments are processed in all, including repeated passes through skipped blocks. Anyway the guards work, although it may still be interesting to try your (WH's) suggestion to recognise a primary header guard and abort the file immediately.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 21:16 +0100 |
| Message-ID | <118etf5$3naff$1@dont-email.me> |
| In reply to | #402135 |
On 16/09/2026 20:30, bart wrote: > On 16/09/2026 19:13, bart wrote: >> On 16/09/2026 16:58, Waldek Hebisch wrote: > >> In any case, my stats show that 400K lines are still part of normal >> processing, while 150K lines are skipped due to false conditional blocks. >> >> Then I went back to one definition. This was fine, so the guards work. >> In that case, what the hell is it spending 400000 lines processing?! >> >> Some more investigation is needed via special tracking info added to >> my compiler. I will update this later. > > The problem was block- and line-comments. Their line-count was added to > the total for normal tokenising and not that for skipping over false > blocks, since both share the same comment routines. > > And there are a lot of comments, including quite a few outside the > guards. I think 380K lines of comments are processed in all, including > repeated passes through skipped blocks. > > Anyway the guards work, although it may still be interesting to try your > (WH's) suggestion to recognise a primary header guard and abort the file > immediately. > I did try this via a bodge. It worked enough to eliminate most of the skipped comments. But it only made it (my C compiler) perhaps 20% faster at processing the full SDL3 headers. But skipping had already been tested to be not far off TCC, and so was comment scanning after some tweaks. Using the compact header, made it 4 times as fast. Conclusion: nothing really. C builds /could/ be made significantly faster when using large libraries across lots of modules, without needing to use workarounds, makefiles etc. But not one person had anything positive to say about it, and two have been hostile. A nice attitude. Anyway it was an interesting exercise for me, but if I use such a library for real, it will be via the generated bindings in my language. And the compiler for that has no such problems. The overheads of processing 4K declarations literally is some single-figure milliseconds per build.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-17 02:56 +0000 |
| Message-ID | <118fksl$2748v$1@paganini.bofh.team> |
| In reply to | #402137 |
bart <bc@freeuk.com> wrote:
> On 16/09/2026 20:30, bart wrote:
>> On 16/09/2026 19:13, bart wrote:
>>> On 16/09/2026 16:58, Waldek Hebisch wrote:
>>
>>> In any case, my stats show that 400K lines are still part of normal
>>> processing, while 150K lines are skipped due to false conditional blocks.
>>>
>>> Then I went back to one definition. This was fine, so the guards work.
>>> In that case, what the hell is it spending 400000 lines processing?!
>>>
>>> Some more investigation is needed via special tracking info added to
>>> my compiler. I will update this later.
>>
>> The problem was block- and line-comments. Their line-count was added to
>> the total for normal tokenising and not that for skipping over false
>> blocks, since both share the same comment routines.
>>
>> And there are a lot of comments, including quite a few outside the
>> guards. I think 380K lines of comments are processed in all, including
>> repeated passes through skipped blocks.
>>
>> Anyway the guards work, although it may still be interesting to try your
>> (WH's) suggestion to recognise a primary header guard and abort the file
>> immediately.
>>
>
> I did try this via a bodge. It worked enough to eliminate most of the
> skipped comments. But it only made it (my C compiler) perhaps 20% faster
> at processing the full SDL3 headers.
>
> But skipping had already been tested to be not far off TCC, and so was
> comment scanning after some tweaks.
There is still question were the time goes? You say that skipping
is fast. But after you skip comments and false branches of conditionals
you should have essentially the same thing as your compact header.
So, where is the problem? In evaluating conditions? In opening
files?
> Using the compact header, made it 4 times as fast.
> Conclusion: nothing really. C builds /could/ be made significantly
> faster when using large libraries across lots of modules, without
> needing to use workarounds, makefiles etc.
>
> But not one person had anything positive to say about it, and two have
> been hostile. A nice attitude.
All other things being equal faster is better. But there is long
way before such speedup is common. It seems that I have an SDL2
sources on my computer so I did a little experiment. Trying
cpp -E -dD SDL.h
I get 63491 lines. '-dD' instructs 'cpp' to preserve '#define' lines,
so I think that the result is usable as a replacement header.
The result contains 14733 empty lines, and 2512 lines specifying
line numbers (both are needed to present original line numbers in
compiler messages). Removing both of the above still leaves
46246 lines. There is 5715 lines begining with 'extern',
3912 lines begining with '__attribute__', 3498 '#define' lines,
463 lines begining with 'typedef', 44 lines begining with 'struct'.
I see enum declaration, struct declarations seem to be rather
large, each '__attribute__' line seem to be part of declaration
of inline function.
So, there is way more stuff than the 4000 lines that you report.
Clearly processing them takes more time than in the case that
you report. And presumably without all those inline functions
(probably 20000 lines) resulting code will be slower.
There are few hundred '#undef' lines, they are probably junk,
but most of 46246 lines above seem to be doing useful work.
And actually, the 14733 empty lines and 2512 lines specifying
line numbers improve compiler diagnostics, so are useful too.
BTW, on my machine 'gcc -O2 -c tsdl.c' where 'tsdl.c' contains
single '#include "SDL.h" takes 0.173s. Doing the same with
'tsdl2.c' where 'tsdl2.c' is result of 'cpp -E -dD SDL.h'
takes 0.133s. The 'cpp' command takes about '0.032s'. So,
it seems that 'gcc' can skip lines at reasonable speed and
that most of the time goes into processing of declarations.
Dividing number of lines it seems that on my machine gcc is
able to process about 340000 declaration lines per second.
If your count of 0.5M lines applies to sources that I have,
then the 'cpp' time would indicate that it can skip lines
at effective speed of about 15M lines per second. Of course,
since gcc/cpp implements include guards most of that is
skipped by skipping whole files (which you may consider
cheating), but looking at effect gcc speed of skipping lines
seem to be impressive even using your criteria.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-30 02:32 +0000 |
| Message-ID | <119hsbf$3r0er$6@dont-email.me> |
| In reply to | #402123 |
On Wed, 16 Sep 2026 13:16:08 -0000 (UTC), Waldek Hebisch wrote: > Do SDL3 use include guards? The expected convention is that header > looks like: > > #ifndef XXXXXX > #define XXXXXX > ... > #endif > > with possibly some trivial variation. That first non-comment thing > in a header is a test and the whole body is inside a conditional. > > Assuming that SDL3 is doing this (and if not you should complain to > them), then your compiler could recognize this pattern and skip the > header when it is included second time. For this you need to > recognize when two paths lead to the same file, recognize the test > and check that test is indeed false when doing second include. This is basically a giant fudge to get around C’s lack of a proper module facility. Some compilers support “#pragma once”, which lets the compiler do the check just on the pathname of the include file, *before* actually opening it. This would be faster. And then I think there are also precompiled headers. Not sure if they’re worth the trouble ... > Some headers may be intentionally included multiple times, but with > include guards you should be able to include most files just once. > IIUC both GCC and TCC handle this. This is where “#pragma once” falls down.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-29 19:58 -0700 |
| Message-ID | <119htss$3r6p5$1@kst.eternal-september.org> |
| In reply to | #402536 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
[...]
> Some compilers support “#pragma once”, which lets the compiler do the
> check just on the pathname of the include file, *before* actually
> opening it. This would be faster.
Here's what the GNU C Preprocessor manual says about it:
‘#pragma once’
If ‘#pragma once’ is seen when scanning a header file, that file
will never be read again, no matter what. It is a less-portable
alternative to using ‘#ifndef’ to guard the contents of header
files against multiple inclusions.
As the name implies, the header file has to be opened once.
Presumably the GNU preprocessor remembers the name of the file so
it won't open it again. Or it remembers *something* that uniquely
identifies the file. I don't know what happens if the same header
file is referred to by multiple names (due to hard links, symbolic
links, mount points, etc.).
One advantage of the #ifndef hack is that it lets the programmer
assign a unique name to a header file. Another advantage, as GNU's
own documentation points out, is that it's more portable.
[...]
>> Some headers may be intentionally included multiple times, but with
>> include guards you should be able to include most files just once.
>> IIUC both GCC and TCC handle this.
>
> This is where “#pragma once” falls down.
I wouldn't say it falls down. It's just a case where "#pragma once"
would be inappropriate -- and "#ifndef" would be equally inappropriate.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-05 02:15 +0000 |
| Message-ID | <119v17t$ekf9$3@dont-email.me> |
| In reply to | #402098 |
On Tue, 15 Sep 2026 14:54:17 -0000 (UTC), Waldek Hebisch wrote: > OTOH I would guesstimate that language features increase > productivity by 50% or more. Fred Brooks analyzed the software-development productivity trend in his “No Silver Bullet” essay of 1986. This was included in the 20th Anniversary Edition of his famous “Mythical Man-Month” book, released in 1995. Basically, there had been an order-of-magnitude improvement in the productivity of software developers in the decade from 1975, after the publication of the first edition of the book. This happened largely because of improvements in the interactivity of computer systems, moving away from big, expensive, unapproachable mainframe batch systems towards, smaller, cheaper, friendlier timeshared minicomputers, and single-user PCs as well. And the greater computing power available made a big difference, too. This improvement was not repeated in the second decade. Something else happened in that second decade: the rise of object-oriented programming. But, contrary to many predictions, that did not in itself give rise to much improvement in programmer productivity. People continued talking about a “software crisis” -- too much code needing to be written, not enough programming talent to write it. Things have greatly improved since then, for a different reason which Brooks did predict in that later edition of his book: the rise of what he called “metaprogramming”, aka “very-high-level languages”. His quoted example (AppleScript) was a bit off the mark; in retrospect Perl would have been a much more forward-looking choice. Then came Tcl and Python, and even JavaScript is part of that trend these days. Again, increased computer power has helped to make popular whole categories of tools that would have been considered too resource-hungry for practical use just a decade earlier. Something else we now take for granted is huge libraries of reusable open-source code, all just a “git clone” or an “apt-get install” away. Plus the rediscovery of the command line in Unix-type systems, with their ability to orchestrate the operation of complex chains built out of simpler operations, without having to write entire new programs from scratch each time. Basically, all these factors put together are the reasons why nobody talks about a “software crisis” any more.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-29 03:22 +0000 |
| Message-ID | <119fat9$2trdt$4@dont-email.me> |
| In reply to | #402050 |
On Mon, 14 Sep 2026 07:41:03 -0000 (UTC), Waldek Hebisch wrote: > You may view interface as information about what needs to be shared, > but IMO there is more to this. In badly designed program a lot must > be shared. In well designed program and assuming that problem domain > is suitable for modularization sharing is quite limited. There is an important principle at play here, best summed up by an old engineering adage: “in any system, complexity arises, not so much from the number of different components, but from the number of potential interactions between them”. Visibility control is an important part of limiting the potential for interactions, particularly unexpected ones, between components of a software system. > And frequently is is possible to replace implementation part by > quite a different thing without affectiong correctness of the > program. Separation of interface from implementation -- a key part of the general principle of abstraction.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-14 09:49 +0200 |
| Message-ID | <11888u4$1am9u$1@dont-email.me> |
| In reply to | #402049 |
bart pisze: > > And it isn't really much to do with modules. C libraries have > interfaces, usually as headers, but it doesn't have modules. out of contex as i not readed most of this branch but obviously C has modules if you may compile some c files with no resolved 'linkage' to like .o or .obj etc they are modules if you would need "close up" all linkage and compiel only to exe etc that it can be said it has not (c has no this new concept im talking about it is if you mix structure and function then function vanish structures vanish (stays as edge cases) and you only have some 'modules' here - but thats quite other story ;C
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-14 11:27 +0100 |
| Message-ID | <1188i66$1e61i$1@dont-email.me> |
| In reply to | #402051 |
On 14/09/2026 08:49, fir wrote: > bart pisze: >> >> And it isn't really much to do with modules. C libraries have >> interfaces, usually as headers, but it doesn't have modules. > > > > out of contex as i not readed most of this branch but obviously C has > modules > > if you may compile some c files with no resolved 'linkage' to like .o > or .obj etc they are modules No. We might informally use 'modules' to mean individual source files or translation units. A program may comprise multiple translation units. C allows independent compilation of such units and there needs to be a linking process to combine them. This is not the same as a language supporting a proper module scheme. Otherwise even Assembly has modules! Without modules, building a program in C looks like this: tcc prog.c a.c b.c c.c d.c e.c ... With modules, it would be just: tcc prog.c Both produce prog.exe. This illustrates automatic discovery of the source files, but real modules would have other benefits too.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-14 16:03 +0200 |
| Message-ID | <1188use$1j3q8$1@dont-email.me> |
| In reply to | #402053 |
bart pisze: > On 14/09/2026 08:49, fir wrote: >> bart pisze: >>> >>> And it isn't really much to do with modules. C libraries have >>> interfaces, usually as headers, but it doesn't have modules. >> >> >> >> out of contex as i not readed most of this branch but obviously C has >> modules >> >> if you may compile some c files with no resolved 'linkage' to like .o >> or .obj etc they are modules > > No. We might informally use 'modules' to mean individual source files or > translation units. A program may comprise multiple translation units. C > allows independent compilation of such units and there needs to be a > linking process to combine them. > > This is not the same as a language supporting a proper module scheme. > Otherwise even Assembly has modules! > > Without modules, building a program in C looks like this: > > tcc prog.c a.c b.c c.c d.c e.c ... > > With modules, it would be just: > > tcc prog.c > > Both produce prog.exe. This illustrates automatic discovery of the > source files, but real modules would have other benefits too. > > No, C has modules those compilation units are modules (it that make binary modules that you can then link) ofc those modules are quite 'thin' or how to call it but for shure those are modules.. what you cay with this example is specific functionality related to modules but not all need to have it (also no need to enlight me on things i was talking quite clearly and loudly many years ago (as far as i remember my first post oon this group was on related things - i mean the problem that c cupports those modules but dont support module names and it may simply make crash or clask of symbols
[toc] | [prev] | [next] | [standalone]
Page 20 of 25 — ← Prev page 1 … 18 19 [20] 21 22 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web