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 5 of 25 — ← Prev page 1 … 3 4 [5] 6 7 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 17:12 +0200 |
| Message-ID | <117rt0l$170nh$3@dont-email.me> |
| In reply to | #401810 |
On 09/09/2026 16:25, Lane W wrote: > I gauged that RUDENESS is something you try to avoid here. If you don't want rude replies, don't make rude posts. Ridiculous sarcasm and exaggeration are not helpful. Your new code is less bad - the enumeration avoids the meaningless magic numbers. But it is not clear if you intend this to be separate functions (which could be a useful thing if the code section is reusable - only the OP can tell us if that's the case), or if it is intended to be combined inside one function. If it is is the later, that is unhelpful additional complexity as the code stands. You have fixed some of the syntax errors in the original code, but introduced new ones (hint - look at the definition of the enumeration type). You might find <https://godbolt.org> a useful tool here - it's an online compiler that makes it very easy to check the syntax of code. It's a site I use multiple times a day for a variety of purposes.
[toc] | [prev] | [next] | [standalone]
| From | "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-09-09 23:59 +0800 |
| Message-ID | <onfoS.424830$9H1.346792@fx01.ams4> |
| In reply to | #401818 |
On 9/9/2026 11:12 PM, David Brown wrote: > On 09/09/2026 16:25, Lane W wrote: > >> I gauged that RUDENESS is something you try to avoid here. > > If you don't want rude replies, don't make rude posts. Ridiculous > sarcasm and exaggeration are not helpful. > You shouldn't call other people rude, David Brown, the brown, because you're always rude. You just don't understand it, because you're always rude. So to stop being rude, you'll have to stop posting on Usenet. Go away! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-09 15:30 -0700 |
| Message-ID | <117smm4$1g635$3@kst.eternal-september.org> |
| In reply to | #401810 |
Lane W <cactus_DAC@yahoo.com> writes:
[...]
> enum Dodges {
> NEAT : 1
> FLAWED : 2
> BARELY : 3
> UNSUCCESS : 4
> };
I strongly suggest you try compiling any code that you're going to post
here. This is not the correct syntax for an enum type. I presume
you're trying to specify values for NEAT, FLAWED, et al, but I see no
reason not to just rely on the default values of 0, 1, ....
Unlike your initial code snippet, you're giving names to the cases
rather than just using constants 1, 2, 3, which is an improvement.
> enum Dodges d = UNSUCCESS;
>
> if (dodge < 1)
> d = BARELY;
> if (dodge < 0.9)
> d = FLAWED;
> if (dodge < 0.5)
> d = NEAT;
As I recall (I might be mistaken), your original code ignored
the possibility that dodge could be >= 1. (For consistency, I'd
definitely write 1.0 rather than 1 here).
If dodge < 0.5, you test its value 3 times and update the value of d
3 times. The performance impact is trivial, but it's conceptually
more complex than it needs to be. I'd put the (dodge < 0.5) test
first and use an else-if chain. (The fact that this forces the
order of the tests is mildly annoying, I suppose.)
> switch (d)
> {
> case NEAT:
> slog("%s easily dodged attack...", being[k].name);
> return 1;
> case FLAWED:
> slog("%s hardly dodged attack...", being[k].name);
> return 1;
> case BARELY:
> slog("%s dodged attack...", being[k].name);
> return 1;
> default:
> return -1; // not dodged.
> }
The association between NEAT and "easily", FLAWED and "hardly", and
BARELY and nothing, seems arbitrary. I'd probably give the enumeration
constants names that match the string.
> WHERE IS THIS DUPLICATION?
>
> WHERE ARE THESE SYNTAX ERRORS YOU NEVER EXPLICITLY STATE?
I don't know whether there were syntax errors in your previous code.
If the syntax errors in your new code were corrected, this might
be a decent demonstration of a useful technique: transforming a
range of floating-point values into discrete values so they can be
operated on more easily. In this particular case, I wouldn't bother.
There are only 3 normal and 1 exceptional cases being considered, and
I personally would prefer to test the floating-point value directly.
If I want to assign names to the ranges, the strings passed to slog()
express that clearly enough, or I might add comments.
if (dodge < 0.5) {
slog("%s dodged attack...", being[k].name);
}
else if (dodge < 0.9) {
slog("%s hardly dodged attack...", being[k].name);
}
else if // ...
In a more complicated case, setting up the enum values could be a
good idea, particularly if those values are going to be used later
in the code. If this is a simple example meant to demonstrate the
technique, that's fine. There's a big difference between writing
code to demonstrate a concept (which often needs to be simplified)
and writing real-world code.
> Am I cleared for Heaven now?
>
> Can we get ten more people to hop on the bandwagon and RUDELY tell me
> how bad it is?
>
> I gauged that RUDENESS is something you try to avoid here.
*yawn*
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-10 06:50 +0200 |
| Message-ID | <117tcu2$1ls9s$1@dont-email.me> |
| In reply to | #401795 |
On 2026-09-09 15:31, David Brown wrote: > On 09/09/2026 15:14, Lane W wrote: >> David Brown wrote: > >>> C's include system works well when used in a sensible and disciplined >>> manner, but unfortunately not all C programmers are sensible and >>> disciplined. >>> >> Agreed. Plus some C programmers use the switch keyword, which we all >> agree is BAD BAD BAD, right Janis and Keith? What makes you think so? - That is not only wrong, it's completely absurd! (I also wonder about that personal obsession.) >> [...] > > [ snip ] (Yes to all you wrote and that I snipped just for brevity.) > > It would be a lot better if you stuck to writing posts that are sensible > replies within threads, or start new topical threads. Post C code, get > feedback on it, and treat that feedback as constructive criticism of the > code - not as some kind of personal attack. Let me add that in case there's some deeper idea behind any criticized code it could have been explained by the poster. (Not that it is likely that the regulars with decades years of experience would not be able to tell apart good and bad code. - But that would at least be a sign that the poster is interested in discussions about any pros and the cons of some particular code.) > (My post here is intended > as constructive criticism - it is not a personal attack.) (I think no sane person would have suspected bad intent of your post.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-09 15:13 -0700 |
| Message-ID | <117sllk$1g635$2@kst.eternal-september.org> |
| In reply to | #401794 |
Lane W <cactus_DAC@yahoo.com> writes:
> David Brown wrote:
[...]
>> C's include system works well when used in a sensible and
>> disciplined manner, but unfortunately not all C programmers are
>> sensible and disciplined.
>>
> Agreed. Plus some C programmers use the switch keyword, which we all
> agree is BAD BAD BAD, right Janis and Keith?
No, of course not.
David Brown already covered most of the points I was going to make,
and I agree with what he wrote in this subthread.
I initially ignored your code because it was in a thread I wasn't
particularly interested in. I later decided to review it because
it was brought to my attention.
If you think I dislike the switch statement, you've reached a
completely incorrect and unjustified conclusion.
I dislike the particular code snippet that you posted, code
that happened to use a switch statement (inappropriately IMHO).
There are plenty of valid uses for switch statements, and I don't
hesitate to use it when it's appropriate. It seemed to me that you
artificially added a layer of complexity so you could use a switch
statement rather than an if/else chain -- and to set that up, you
used a sequence of if statements (with no "else" for some reason).
My criticism of your code has nothing to do with the fact that you
wrote it. To be blunt, I don't care enough about you personally to
go out of my way to nitpick your code. I would have had similar
criticisms if the code had been posted by the late Dennis Ritchie
or by Brian Kernighan, though I would have been more reticent in
expressing my opinions.
The idea behind your code is not necessarily a bad one.
You transformed a floating-point input value partitioned into
ranges into a discrete value, with one discrete value corresponding
to each range. That can be a useful technique. For one thing,
it's an opportunity to give a meaningful name to each input range
(but you just used 1, 2, 3). In some cases, it might allow fewer
floating-point operations to be performed before making a decision,
which could be significant in performance-critical code.
But your specific code in this specific case was not good.
Leaving out the extra transformation step would, in this case,
make the code clearer and more efficient.
> In fact at work, I'm regularly known as __The Evil One__ because of my
> propensity to use the switch construct.
>
> Every company brochure shows my position as Sauron in the company
> fables, with my signature golden ring. Pure evil, I guarantee it.
Dude, get over yourself. Pretending to be persecuted because someone
criticized your code is not a good look.
--
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 | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-09-09 15:16 +0100 |
| Message-ID | <117rpo0$1730g$1@dont-email.me> |
| In reply to | #401775 |
On 09/09/2026 10:45, Keith Thompson wrote: > I'd choose a non-reserved name for the macro, probably > H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a > reserved name for a header whose name starts with 'e'). Which header? I get that __anything, _Capital, E, str, mem and probably a few I've forgotten are reserved prefixes. I never heard of NUM or NUMBER being off limits. Seems a very common prefix that would get used a lot.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-09 15:43 -0700 |
| Message-ID | <117sndo$1g635$4@kst.eternal-september.org> |
| In reply to | #401806 |
Richard Harnden <richard.nospam@gmail.invalid> writes:
> On 09/09/2026 10:45, Keith Thompson wrote:
>> I'd choose a non-reserved name for the macro, probably
>> H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
>> reserved name for a header whose name starts with 'e').
>
> Which header?
>
> I get that __anything, _Capital, E, str, mem and probably a few I've
> forgotten are reserved prefixes. I never heard of NUM or NUMBER being
> off limits. Seems a very common prefix that would get used a lot.
Sorry if I was unclear.
I was referring to a hypothetical header whose name starts with 'e',
and using a consistent convention for creating macro names from header
names that avoids reserved identifiers.
NUMBER_GENERATOR_H is not reserved. EVENT_H (for "event.h",
a header file in my /usr/include directory) is.
(That actual header file uses "EVENT1_EVENT_H_INCLUDED_" -- not
what I'd use, but vanishingly unlikely to be a problem in practice.
It could also be argued that it's part of the implementation.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-10 07:16 +0200 |
| Message-ID | <117teg1$1ls9r$2@dont-email.me> |
| In reply to | #401806 |
On 2026-09-09 16:16, Richard Harnden wrote: > On 09/09/2026 10:45, Keith Thompson wrote: >> I'd choose a non-reserved name for the macro, probably >> H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a >> reserved name for a header whose name starts with 'e'). > > Which header? > > I get that __anything, _Capital, E, str, mem and probably a few I've > forgotten are reserved prefixes. I never heard of NUM or NUMBER being > off limits. Seems a very common prefix that would get used a lot. This was also my first thought when I read Keith's formulation. On a second thought I presumed he meant that with such a method some other header names (those starting with 'e') might lead to problems; I suppose only if there's clashes with existing ones in the actual environment (or as part of the standard). Personally I think that it's not good to twist ones own coherent naming conventions only due to the fact that there's these (IMO) very unfortunate exceptions for sub-ranges of these identifiers, and some (very low?) probability that there may be clashes. I don't known when the E-words found their way into the standard. Back in the days we had used names primarily resembling the file names. (We never encountered a problem. And, in case there would have been one, it were certainly not a situation that couldn't then be specifically handled and resolved, I'd think.) Janis
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-08 00:02 +0000 |
| Message-ID | <117nj9s$36as3$2@paganini.bofh.team> |
| In reply to | #401689 |
bart <bc@freeuk.com> wrote:
> On 07/09/2026 14:33, David Brown wrote:
>> On 07/09/2026 14:55, bart wrote:
>
>>> A typical module scheme works like this:
>>>
>>> * You have, say, a project of 100 modules
>>> * Each module selectively exports some entities
>>> * Each module selectively imports some subset of the other 99 modules
>>>
>>
>> OK so far.
>>
>>> The result is that each module starts with some rag-tag collection of
>>> 'import' statements, each different from any other module, and needing
>>> a lot of maintenance.
>>
>> No. People who write /structured/ code do not do "rag-tag".
>>
>> When a project is of a size where it is inconvenient to keep track of
>> all the separate "import" (or "#include", or whatever) statements, you
>> use a hierarchy. Instead of importing "dns", "udp", "http", etc.,
>> modules, you import "network". The common "network" module pulls in the
>> sub-modules. You probably also organise things in directories and sub-
>> directories, matching the module layout. It is /structured/.
>
> But it's a pattern I've seen a lot. In C also, as collections of
> #includes; this example is from Lua, a project of only 35 modules, and
> from one of its .c files:
>
> #include "lprefix.h"
>
> #include <float.h>
> #include <limits.h>
> #include <math.h>
> #include <stdlib.h>
>
> #include "lua.h"
>
> #include "lcode.h"
> #include "ldebug.h"
> #include "ldo.h"
> #include "lgc.h"
> #include "llex.h"
> #include "lmem.h"
> #include "lobject.h"
> #include "lopcodes.h"
> #include "lparser.h"
> #include "lstring.h"
> #include "ltable.h"
> #include "lvm.h"
>
> Every file has a different set. In all, there are 28K lines of C code
> among the .c files, and there are 466 #include lines. That is similar to
> the maintenance nightmare where each file imports a particular set of
> modules.
The organization looks sensible to me. Given that #include lines
are less than 2% of total and are likely to change very infrequently
I see no maintennce problem. However, if that bothers you, in
each file of your project you can put
#include "proj.h"
and put all needed includes in inside 'proj.h'. I you choose
good name you will never need to change it so maintenance cost
of '#include "proj.h"' will be close to 0. AFAICS maintenance
cost of 'proj.h' will be very similar to maintenance cost of
your module listing.
C gives you choice: you can have detailed control of what is
imported at cost of writing a lot of '#include' lines or you
can have common header which includes "everthing". With external
tools you can even automate maintanence of includes (say
automatially force any C file in a directory to include all
.h files in the same directory). You implemented a specific
way which you like. But if developers want something different
(as apparently Lua developers want) your compiler (if they
decide to use it) will force on them your way.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-08 12:47 +0100 |
| Message-ID | <117osjv$4ti6$1@dont-email.me> |
| In reply to | #401704 |
On 08/09/2026 01:02, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 07/09/2026 14:33, David Brown wrote: >>> On 07/09/2026 14:55, bart wrote: >> >>>> A typical module scheme works like this: >>>> >>>> * You have, say, a project of 100 modules >>>> * Each module selectively exports some entities >>>> * Each module selectively imports some subset of the other 99 modules >>>> >>> >>> OK so far. >>> >>>> The result is that each module starts with some rag-tag collection of >>>> 'import' statements, each different from any other module, and needing >>>> a lot of maintenance. >>> >>> No. People who write /structured/ code do not do "rag-tag". >>> >>> When a project is of a size where it is inconvenient to keep track of >>> all the separate "import" (or "#include", or whatever) statements, you >>> use a hierarchy. Instead of importing "dns", "udp", "http", etc., >>> modules, you import "network". The common "network" module pulls in the >>> sub-modules. You probably also organise things in directories and sub- >>> directories, matching the module layout. It is /structured/. >> >> But it's a pattern I've seen a lot. In C also, as collections of >> #includes; this example is from Lua, a project of only 35 modules, and >> from one of its .c files: >> >> #include "lprefix.h" >> >> #include <float.h> >> #include <limits.h> >> #include <math.h> >> #include <stdlib.h> >> >> #include "lua.h" >> >> #include "lcode.h" >> #include "ldebug.h" >> #include "ldo.h" >> #include "lgc.h" >> #include "llex.h" >> #include "lmem.h" >> #include "lobject.h" >> #include "lopcodes.h" >> #include "lparser.h" >> #include "lstring.h" >> #include "ltable.h" >> #include "lvm.h" >> >> Every file has a different set. In all, there are 28K lines of C code >> among the .c files, and there are 466 #include lines. That is similar to >> the maintenance nightmare where each file imports a particular set of >> modules. > > The organization looks sensible to me. Not to me. This project uses these 35 files: lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c lundump.c lutf8lib.c lvm.c lzio.c onelua.c (A build will use 34 of them, depending whether it is EXE or DLL.) With a module scheme, there should be no need for any additional info at all. But my point was, with how such schemes typically work, you still have lots of mixed sets of 'import' statements at the start of each file. > Given that #include lines > are less than 2% of total and are likely to change very infrequently > I see no maintennce problem. You can't quantify it like that. In any case, they will only change infrequently once you've finished development! I found it annoying enough, and taking up enough time to devise a new way of doing modules. And it is utter bliss. But in this C project, there are also 28 .h files occupying 5Kloc. Much of that is duplicating stuff that that is in a corresponding .c file. There is also a makefile of 224 lines, but dense so about 0.8% of the total .c and .h files. However with a module scheme like mine and using the same file structure, the project info needed occupies only 34 lines and 470 bytes. There would be no header files, no developer makefiles (Lua uses a separate installation makefile), and no hundreds of #includes. > However, if that bothers you, in > each file of your project you can put > > #include "proj.h" > > and put all needed includes in inside 'proj.h'. I you choose > good name you will never need to change it so maintenance cost > of '#include "proj.h"' will be close to 0. AFAICS maintenance > cost of 'proj.h' will be very similar to maintenance cost of > your module listing. > > C gives you choice: you can have detailed control of what is > imported at cost of writing a lot of '#include' lines or you > can have common header which includes "everthing". With external > tools you can even automate maintanence of includes (say > automatially force any C file in a directory to include all > .h files in the same directory). You implemented a specific > way which you like. But if developers want something different > (as apparently Lua developers want) your compiler (if they > decide to use it) will force on them your way. Yeah, external tools and workarounds. My first big project in C also used a script to collate the local and exported functions. Still, modern languages tend to have a module scheme, suggesting the 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-09 01:59 +0000 |
| Message-ID | <117qehd$3mtn3$1@paganini.bofh.team> |
| In reply to | #401719 |
bart <bc@freeuk.com> wrote:
> On 08/09/2026 01:02, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 07/09/2026 14:33, David Brown wrote:
>>>> On 07/09/2026 14:55, bart wrote:
>>>
>>>>> A typical module scheme works like this:
>>>>>
>>>>> * You have, say, a project of 100 modules
>>>>> * Each module selectively exports some entities
>>>>> * Each module selectively imports some subset of the other 99 modules
>>>>>
>>>>
>>>> OK so far.
>>>>
>>>>> The result is that each module starts with some rag-tag collection of
>>>>> 'import' statements, each different from any other module, and needing
>>>>> a lot of maintenance.
>>>>
>>>> No. People who write /structured/ code do not do "rag-tag".
>>>>
>>>> When a project is of a size where it is inconvenient to keep track of
>>>> all the separate "import" (or "#include", or whatever) statements, you
>>>> use a hierarchy. Instead of importing "dns", "udp", "http", etc.,
>>>> modules, you import "network". The common "network" module pulls in the
>>>> sub-modules. You probably also organise things in directories and sub-
>>>> directories, matching the module layout. It is /structured/.
>>>
>>> But it's a pattern I've seen a lot. In C also, as collections of
>>> #includes; this example is from Lua, a project of only 35 modules, and
>>> from one of its .c files:
>>>
>>> #include "lprefix.h"
>>>
>>> #include <float.h>
>>> #include <limits.h>
>>> #include <math.h>
>>> #include <stdlib.h>
>>>
>>> #include "lua.h"
>>>
>>> #include "lcode.h"
>>> #include "ldebug.h"
>>> #include "ldo.h"
>>> #include "lgc.h"
>>> #include "llex.h"
>>> #include "lmem.h"
>>> #include "lobject.h"
>>> #include "lopcodes.h"
>>> #include "lparser.h"
>>> #include "lstring.h"
>>> #include "ltable.h"
>>> #include "lvm.h"
>>>
>>> Every file has a different set. In all, there are 28K lines of C code
>>> among the .c files, and there are 466 #include lines. That is similar to
>>> the maintenance nightmare where each file imports a particular set of
>>> modules.
>>
>> The organization looks sensible to me.
>
> Not to me. This project uses these 35 files:
>
> lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c
> ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c
> lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c
> lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c
> lundump.c lutf8lib.c lvm.c lzio.c onelua.c
>
> (A build will use 34 of them, depending whether it is EXE or DLL.)
>
> With a module scheme, there should be no need for any additional info at
> all. But my point was, with how such schemes typically work, you still
> have lots of mixed sets of 'import' statements at the start of each file.
>
>
>> Given that #include lines
>> are less than 2% of total and are likely to change very infrequently
>> I see no maintennce problem.
>
> You can't quantify it like that. In any case, they will only change
> infrequently once you've finished development!
If a program is "finished" it will not change at all. During
normal developement I need to add #include lines, but once
added they tend to stay. Sometimes I realize that given
include is not needed or I decide to rename a file. Normal
code is different, first version may have bugs which need
fixing, I may realize that different structure is better, so
there is lot of changes. Relatively to that I perceive changes
to #include lines to be very infrequent.
> I found it annoying enough, and taking up enough time to devise a new
> way of doing modules. And it is utter bliss.
I agree that maintaing info that you do not value may be annoying.
But if you are used to maintaing C code bases, than maintaining
#include lines does not take much time.
> But in this C project, there are also 28 .h files occupying 5Kloc. Much
> of that is duplicating stuff that that is in a corresponding .c file.
>
> There is also a makefile of 224 lines, but dense so about 0.8% of the
> total .c and .h files.
>
> However with a module scheme like mine and using the same file
> structure, the project info needed occupies only 34 lines and 470 bytes.
>
> There would be no header files, no developer makefiles (Lua uses a
> separate installation makefile), and no hundreds of #includes.
>
>
>> However, if that bothers you, in
>> each file of your project you can put
>>
>> #include "proj.h"
>>
>> and put all needed includes in inside 'proj.h'. I you choose
>> good name you will never need to change it so maintenance cost
>> of '#include "proj.h"' will be close to 0. AFAICS maintenance
>> cost of 'proj.h' will be very similar to maintenance cost of
>> your module listing.
>>
>> C gives you choice: you can have detailed control of what is
>> imported at cost of writing a lot of '#include' lines or you
>> can have common header which includes "everthing". With external
>> tools you can even automate maintanence of includes (say
>> automatially force any C file in a directory to include all
>> .h files in the same directory). You implemented a specific
>> way which you like. But if developers want something different
>> (as apparently Lua developers want) your compiler (if they
>> decide to use it) will force on them your way.
>
> Yeah, external tools and workarounds. My first big project in C also
> used a script to collate the local and exported functions.
>
> Still, modern languages tend to have a module scheme, suggesting the
> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.
Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.
Third, modules resolve name clashes: the "same" name in
two different modules is disambiguated by its source module.
Fourth, given a main module compiler can track its imports
and build the program without need for separate Makefile.
There are different styles. Ada, Modula 2 and Extended Pascal
use separate interface modules. In typical practice they are
stored in separate files so this looks similar to C practice
of having .c and .h files. Other languages like UCSD/Turbo
Pascal have modules with separate iterface and implementation
parts, but both parts are considered a single module. In
practice with such languages whole module is kept in a single
file, so number of separate files is smaller. But you still
have separate declarations in interface part and definitions
in implementation part. Wirth Oberon (or at least some variant
of it) uses different apprach, IIRC exported functions are
marked putting asterisk before function name. That means less
code to write, but to see what is exported you need a separate
tool.
IIUC modules with separate iterface and implementation were
advocated together with database-like storage of source code.
Database technology was supposed to mitigate space overhead
related to having many small files. Appropriate editors
were supposed to make such system convenient. AFAICS
this supporting technology did not get popular, and most
developers simply used files.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 10:26 +0200 |
| Message-ID | <117r587$3r5qo$5@dont-email.me> |
| In reply to | #401752 |
On 2026-09-09 03:59, Waldek Hebisch wrote: > [...] > > Module system has other advantages over C. First, in C sane > developers use headers in consistent way, but language > does not enforce it. Typical module system enforces > consistency. Second, module interfaces can be parsed once, > avoiding problem of repeated re-parsing of C headers. > Third, modules resolve name clashes: the "same" name in > two different modules is disambiguated by its source module. > Fourth, given a main module compiler can track its imports > and build the program without need for separate Makefile. > Please bear with me that I quote this part from the longish post; I think these contents should not be missed in the lot and emphasized. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 19:12 +0100 |
| Message-ID | <117s7is$1ccug$1@dont-email.me> |
| In reply to | #401752 |
On 09/09/2026 02:59, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 08/09/2026 01:02, Waldek Hebisch wrote: >>> bart <bc@freeuk.com> wrote: >>>> On 07/09/2026 14:33, David Brown wrote: >>>>> On 07/09/2026 14:55, bart wrote: >>>> >>>>>> A typical module scheme works like this: >>>>>> >>>>>> * You have, say, a project of 100 modules >>>>>> * Each module selectively exports some entities >>>>>> * Each module selectively imports some subset of the other 99 modules >>>>>> >>>>> >>>>> OK so far. >>>>> >>>>>> The result is that each module starts with some rag-tag collection of >>>>>> 'import' statements, each different from any other module, and needing >>>>>> a lot of maintenance. >>>>> >>>>> No. People who write /structured/ code do not do "rag-tag". >>>>> >>>>> When a project is of a size where it is inconvenient to keep track of >>>>> all the separate "import" (or "#include", or whatever) statements, you >>>>> use a hierarchy. Instead of importing "dns", "udp", "http", etc., >>>>> modules, you import "network". The common "network" module pulls in the >>>>> sub-modules. You probably also organise things in directories and sub- >>>>> directories, matching the module layout. It is /structured/. >>>> >>>> But it's a pattern I've seen a lot. In C also, as collections of >>>> #includes; this example is from Lua, a project of only 35 modules, and >>>> from one of its .c files: >>>> >>>> #include "lprefix.h" >>>> >>>> #include <float.h> >>>> #include <limits.h> >>>> #include <math.h> >>>> #include <stdlib.h> >>>> >>>> #include "lua.h" >>>> >>>> #include "lcode.h" >>>> #include "ldebug.h" >>>> #include "ldo.h" >>>> #include "lgc.h" >>>> #include "llex.h" >>>> #include "lmem.h" >>>> #include "lobject.h" >>>> #include "lopcodes.h" >>>> #include "lparser.h" >>>> #include "lstring.h" >>>> #include "ltable.h" >>>> #include "lvm.h" >>>> >>>> Every file has a different set. In all, there are 28K lines of C code >>>> among the .c files, and there are 466 #include lines. That is similar to >>>> the maintenance nightmare where each file imports a particular set of >>>> modules. >>> >>> The organization looks sensible to me. >> >> Not to me. This project uses these 35 files: >> >> lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c >> ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c >> lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c >> lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c >> lundump.c lutf8lib.c lvm.c lzio.c onelua.c >> >> (A build will use 34 of them, depending whether it is EXE or DLL.) >> >> With a module scheme, there should be no need for any additional info at >> all. But my point was, with how such schemes typically work, you still >> have lots of mixed sets of 'import' statements at the start of each file. >> >> >>> Given that #include lines >>> are less than 2% of total and are likely to change very infrequently >>> I see no maintennce problem. >> >> You can't quantify it like that. In any case, they will only change >> infrequently once you've finished development! > > If a program is "finished" it will not change at all. During > normal developement I need to add #include lines, but once > added they tend to stay. Sometimes I realize that given > include is not needed or I decide to rename a file. Normal > code is different, first version may have bugs which need > fixing, I may realize that different structure is better, so > there is lot of changes. Relatively to that I perceive changes > to #include lines to be very infrequent. > >> I found it annoying enough, and taking up enough time to devise a new >> way of doing modules. And it is utter bliss. > > I agree that maintaing info that you do not value may be annoying. > But if you are used to maintaing C code bases, than maintaining > #include lines does not take much time. People around here always seems to be making excuses for C! I find that adding include files, creating headers, maintaining forward declarations etc to be a complete PITA. >> Still, modern languages tend to have a module scheme, suggesting the >> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough. > > I used or at least looked at several languages with module systems > or things intended to perform similar duty. You approach seem to > be unique, all other require explicit import or equivalent at least > in some (rather frequent) cases. Some languages do not support > re-export, in such case you can rightfully complain. The ones with > re-export allow forming common interface module do that number > of import statements is minimised. But this is developers choice > and apparently most prefer to import only needed things, even > though it requires more import statements. Some even specify individual names to be imported from a module. What a complete waste of time! It's bad enough listing the modules themselves, of which there may a dozen or two, but there could be hundreds of imported functions. A module scheme should mean less work not more. > Module system has other advantages over C. First, in C sane > developers use headers in consistent way, but language > does not enforce it. Typical module system enforces > consistency. Second, module interfaces can be parsed once, > avoiding problem of repeated re-parsing of C headers. According to David Brown and Scott Lurndal, that is a non-problem! And according to DB, reducing a large, complex mass of header files (of external library) into one compact file 95% smaller, would be a waste of time. > Third, modules resolve name clashes: the "same" name in > two different modules is disambiguated by its source module. > Fourth, given a main module compiler can track its imports > and build the program without need for separate Makefile. I tried a scheme in C once. That is, a scheme where you submitted only the main.c file to the compiler, then it discovered the rest. It worked well, but required programs to be written in a certain way. For example, each module file.c required a matching file.h header. In the main module, you only included the .h files needed by this module. It would then add those .c files, and applied the process recursively. However all the projects I wanted to build weren't structured like this. > There are different styles. Ada, Modula 2 and Extended Pascal > use separate interface modules. In typical practice they are > stored in separate files so this looks similar to C practice > of having .c and .h files. Other languages like UCSD/Turbo > Pascal have modules with separate iterface and implementation > parts, but both parts are considered a single module. In > practice with such languages whole module is kept in a single > file, so number of separate files is smaller. But you still > have separate declarations in interface part and definitions > in implementation part. Wirth Oberon (or at least some variant > of it) uses different apprach, IIRC exported functions are > marked putting asterisk before function name. That means less > code to write, but to see what is exported you need a separate > tool. With separate interface files, who writes the interface: is it the programmer who has to duplicate what is in the implementation? (In which case, what checks are made that it matches?) Or is it automatic? My first attempts at (modern) modules tried to do the latter, but it was hard. For example, compile module A.m and it generates A.exp which is the interface that can be used elsewhere via 'import A'. But suppose A and B import each other; which is compiled first? This is an advantage of a manually written interface, in that cyclic imports become easier, and you don't need a heirarchical structure. > > IIUC modules with separate iterface and implementation were > advocated together with database-like storage of source code. I now work with whole program compilers. There, a discrete interface file doesn't make sense and is not needed between the modules of the same program. But they still exist at the boundaries of the program: when the program imports an external library, or my program is a library that exports functions. In that case, they are only partly automated.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-09-09 21:01 +0200 |
| Message-ID | <117saee$27j9$1@news.gegeweb.eu> |
| In reply to | #401829 |
On 9/9/26 20:12, bart wrote:
>
> A module scheme should mean less work not more.
>
So, just use Modern Fortran.
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 21:45 +0200 |
| Message-ID | <117sd09$1dkqe$2@dont-email.me> |
| In reply to | #401829 |
On 09/09/2026 20:12, bart wrote: > > According to David Brown and Scott Lurndal, that is a non-problem! > > And according to DB, reducing a large, complex mass of header files (of > external library) into one compact file 95% smaller, would be a waste of > time. Please stop paraphrasing me (and other people) incorrectly. Instead, just assume that you have misunderstood what people have said, and continue discussing them in the relevant thread in the hope that you eventually understand it. I am happy to discuss many things with you, but I find your repeated misquoting extremely frustrating.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 21:18 +0100 |
| Message-ID | <117seuh$1euj0$1@dont-email.me> |
| In reply to | #401836 |
On 09/09/2026 20:45, David Brown wrote: > On 09/09/2026 20:12, bart wrote: >> >> According to David Brown and Scott Lurndal, that is a non-problem! >> >> And according to DB, reducing a large, complex mass of header files >> (of external library) into one compact file 95% smaller, would be a >> waste of time. > Please stop paraphrasing me (and other people) incorrectly. Instead, > just assume that you have misunderstood what people have said, and > continue discussing them in the relevant thread in the hope that you > eventually understand it. I am happy to discuss many things with you, > but I find your repeated misquoting extremely frustrating. You said this: >As I showed in my timings, in real use, that [reducing headers by 95%] could, at most, reduce the compile time by about 15%. It does not matter how long it takes to read the SDL3 headers and throw them away, because it is not a useful task. In an earlier post (09:18 BST today) you said: > Trying to optimise or flatten header sets for some library would be a waste of effort - the effect is too minor. Both sound very much as though consider it a waste of time. You are also ignoring a simple fact: how large is a typical source file size in C; 1000 lines maybe? Well each .c file that includes SDK.h needs to first process 82,000 /unique/ lines of source, before getting around to those 1000 lines. But that's also ignoring that a lot more than 82Kloc needs to be either processed or skipped since many are re-included: there are 466 #includes! In fact here are the figures from my compiler: Total lines processed: 551,674 Of those, 150,000 are conditional false blocks that skipped over, but it still leaves 400,000 lines. This is 400Kloc for a ONE module of 1Kloc, and there could be other modules pulling in the same header. So, I would say that is quite dominant, for a non-optimising build.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-10 09:32 +0200 |
| Message-ID | <117tmea$1o1jf$4@dont-email.me> |
| In reply to | #401838 |
On 09/09/2026 22:18, bart wrote: > On 09/09/2026 20:45, David Brown wrote: >> On 09/09/2026 20:12, bart wrote: >>> >>> According to David Brown and Scott Lurndal, that is a non-problem! >>> >>> And according to DB, reducing a large, complex mass of header files >>> (of external library) into one compact file 95% smaller, would be a >>> waste of time. >> Please stop paraphrasing me (and other people) incorrectly. Instead, >> just assume that you have misunderstood what people have said, and >> continue discussing them in the relevant thread in the hope that you >> eventually understand it. I am happy to discuss many things with you, >> but I find your repeated misquoting extremely frustrating. > You said this: > > >As I showed in my timings, in real use, that [reducing headers by 95%] > could, at most, reduce the compile time by about 15%. It does not > matter how long it takes to read the SDL3 headers and throw them away, > because it is not a useful task. > > In an earlier post (09:18 BST today) you said: > > > Trying to optimise or flatten header sets for some library would be > a waste of effort - the effect is too minor. > > Both sound very much as though consider it a waste of time. You have managed to read, then quote, what I wrote - and you still do not see how it differs substantially from what you /claim/ I said? I gave numbers demonstrating that, for /me/, with /my/ code, no reduction or simplification of headers could have an effect on /my/ build times that was big enough to be worth /my/ time. I also, several times, said that it is possible that it would be helpful for widely used libraries to provide more efficient headers. I don't think it is often the case, but I am open to the possibility. I have said nothing about "reducing a large, complex mass of headers into one compact file 95% smaller" - how could I have commented on a circumstance that you did not mention until later? If a library has a collection of headers that can be reduced by a factor of 20 without affecting functionality (including any helpful comments), then it seems likely that the project could be improved by a re-factorisation and cleanup. The prime motivation would be improving maintainability, making the headers easier to navigate and understand, and reducing the risk of errors from out-of-sync duplications. It may also marginally reduce build times for library users, but that would be a bonus side-effect, not the reason for such a cleanup. > > > You are also ignoring a simple fact: how large is a typical source file > size in C; 1000 lines maybe? > > Well each .c file that includes SDK.h needs to first process 82,000 / > unique/ lines of source, before getting around to those 1000 lines. > > But that's also ignoring that a lot more than 82Kloc needs to be either > processed or skipped since many are re-included: there are 466 > #includes! In fact here are the figures from my compiler: > > Total lines processed: 551,674 > > Of those, 150,000 are conditional false blocks that skipped over, but it > still leaves 400,000 lines. > > This is 400Kloc for a ONE module of 1Kloc, and there could be other > modules pulling in the same header. So, I would say that is quite > dominant, for a non-optimising build. > Compilers chew through typical C header stuff at high speed. They are usually nothing more than macros and simple declarations. With the exception of occasional inline function definitions, it's all quickly digested. The time and effort of compiling - at least for grown-up compilers - is in code analysis, inter-procedural optimisations, error analysis, register allocation algorithms, variable lifetime analysis, code generation, and countless optimisation passes. The average "lines of code handled per second" speed is probably a thousand times faster while reading the SDL.h headers than while handling the user code.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 23:26 +0200 |
| Message-ID | <117sita$3r5qo$7@dont-email.me> |
| In reply to | #401829 |
On 2026-09-09 20:12, bart wrote: > On 09/09/2026 02:59, Waldek Hebisch wrote: >> [...] > > Some even specify individual names to be imported from a module. What a > complete waste of time! I fear you're just exposing your very limited perception and experience here. (And en passant probably also the mindset of a technocratic paper pusher than a software designer.) Myself I'm favoring _to be able_ to import only what I need and not the whole bunch of existing things of a module (with all potential implicit and explicit consequences). Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 23:30 +0100 |
| Message-ID | <117smmo$1hgkq$1@dont-email.me> |
| In reply to | #401842 |
On 09/09/2026 22:26, Janis Papanagnou wrote: > On 2026-09-09 20:12, bart wrote: >> On 09/09/2026 02:59, Waldek Hebisch wrote: >>> [...] >> >> Some even specify individual names to be imported from a module. What >> a complete waste of time! > > I fear you're just exposing your very limited perception and experience > here. (And en passant probably also the mindset of a technocratic paper > pusher than a software designer.) > > Myself I'm favoring _to be able_ to import only what I need and not the > whole bunch of existing things of a module (with all potential implicit > and explicit consequences). Why? What is the advantage of so much micromanagement? Is even the pain of having to do '#include <string.h>' not enough when your code uses string functions, you would prefer to list them individually too?! With other languages, do you also need to specify importing individual variables, enumerations, types, structs and macros? An enumeration set may have hundreds of names; do you have to list all of them? That would be insane. I'd originally complained about having to list modules individually in in each file; this would be literally magnitudes worse. You might as well put each entity into its own module, and have a subset of 1000 modules to manage instead - in each of the 1000 functions. You people seem to like making life difficult. Well, go ahead! > Myself I'm favoring _to be able_ to import only what I need and not the > whole bunch of existing things of a module (with all potential implicit > and explicit consequences). Which consequences are these? If there's too much unrelated stuff in a module, that suggests it is poorly structured. If you import modules A and B, and use functions from each, but some may clash (say you want F from A but not F from B), then that's not a problem because you will say A.F or B.F. If you want to use 'using' because you don't want to type 'A.' or 'B.', just F and it will be from a specific import, that /that/ would be bad form. In any case, there are better ways.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-10 08:45 +0200 |
| Message-ID | <117tjn1$1ls9r$3@dont-email.me> |
| In reply to | #401850 |
On 2026-09-10 00:30, bart wrote: > On 09/09/2026 22:26, Janis Papanagnou wrote: >> [...] >> >> Myself I'm favoring _to be able_ to import only what I need and not the >> whole bunch of existing things of a module (with all potential implicit >> and explicit consequences). > > Why? What is the advantage of so much micromanagement? The advantages of _modularity_ are for example to structure entities that may be typically used together or to restrict yourself to the subset of what you actually need. (Neither an "include all" nor an "include value_x_of_y" are usually sensible choices!) - You may want to inspect the various options you have in other languages (inspect, just for example, Java - beyond any personal liking of that language). > > Is even the pain of having to do '#include <string.h>' not enough when > your code uses string functions, you would prefer to list them > individually too?! No. What makes you think so? (And it is also no "pain" for me, BTW.) But if all I need from the string class is, say, strcmp() then it is completely sensible to be able to include just that. (This is not "C" but explaining just the principle of import or export control here.) If it turns out that I need more I can include the whole "tool-chest" (unless I get name clashes that a specific import would prevent). > > With other languages, do you also need to specify importing individual > variables, enumerations, types, structs and macros? That depends on the specific language. - Note that I'm not competent to know all the module concepts of the many languages; I know just a few. And we're anyway speaking about the principles of modularity and its control. Ideally you may control the import level (all, or selected items) to your needs. Typically the modules are (or should be) structured in a way that elements that "belong together" are collected in a module, so that with a single import you have all you need for using it; as you write in your question this may be types, functions, singleton objects, or whatever the respective language supports. For example; my recent Algol 68 option parser defines the necessary types and the (exported) function to handle the options. (All other internally used functions are hidden.) Or my array shuffler function uses a swap operator, but since that is useful also generally I have it visible in the module for use. In an encryption module I have the functions to create the subkey-sequence, the encryption/decryption functions, data types resembling the entities you use with these functions (e.g. 64-bit and 56-bit integrals). - So these facilities provide all the _necessary_ in one module each. But there may also be tool-chests-like modules; and in this case you may prefer to just pick the requested entities if the subset is small. - For example my ansi-controls module is a huge collection of functions; I'd like to just pick the 5 or 6 functions I'm needing (but with the language I'm using I can only pick an include file as a whole; unless I split the functions myself in sub-groups - good that we spoke about that; I'll probably do that to separate the colors at least - anyway there's a lot of entries that I'd prefer not to pollute my name space). Note also that languages may provide structuring means that allow an own level of modularization. Consider for example the object oriented languages where you collect things that belong together in classes. BTW, you may want to consider reading more about modularity; B. Meyer has an introductory small chapter about aspects in his "OO Software Development" book. (I'm sure there's plenty other resources.) You can also search the Web on principles and advantages including control of modularization. > > An enumeration set may have hundreds of names; do you have to list all > of them? That would be insane. Yes, that would be insane. - How do you manage it to breed such absurd ideas?! Didn't there for a moment appear the option in your mind that it's not about having to do that in one extreme or in another!? > > I'd originally complained about having to list modules individually in > in each file; this would be literally magnitudes worse. It's not about "having to"; it's about _having the option_ to do, depending on the actual case (and of course primarily depending on the methods that any specific language provides). > > You might as well put each entity into its own module, and have a subset > of 1000 modules to manage instead - in each of the 1000 functions. Why would you do that? I wouldn't. - You completely missed the point. > > You people seem to like making life difficult. Well, go ahead! Nonsense. - You seem to be stubbornly focused on some "idee fixe" you have, incapable of evading your own mental cage. > > > Myself I'm favoring _to be able_ to import only what I need and not the > > whole bunch of existing things of a module (with all potential implicit > > and explicit consequences). > > Which consequences are these? If there's too much unrelated stuff in a > module, that suggests it is poorly structured. Yes. (As I've expanded on.) > > If you import modules A and B, and use functions from each, but some may > clash (say you want F from A but not F from B), then that's not a > problem because you will say A.F or B.F. Yes, if namespaces are supported. But that's also not that "simple" or clear as you pretend. - Consider for example C++ with its stream output; would you really write as in this _simple_ example - there's yet more common things with streams, like standard-modifiers (e.g. std::oct, std:: setw()) that may often complicate the expression WRT legibility! - always 'std::' like std::cout << "hello world" << std::endl; or prefer an extensive all-is-the-least-"burden" directive using std; and for all the many output commands just the better legible cout << "hello world" << endl; Or would you take the "burden" to restrict your imports for this common case once with the _specific_ references like using std::cout; using std::endl; I'd say, it depends. - And I think it's good to have full control over all the sensible options. > > If you want to use 'using' because you don't want to type 'A.' or 'B.', > just F and it will be from a specific import, that /that/ would be bad > form. In any case, there are better ways. I suppose you are referring to the C++ model here. - Yes, in C++ you have the option from explicitly qualifying the entity to "get all" into the namespace. The point is that you should have the possibility to modularize, and to control it. Janis
[toc] | [prev] | [next] | [standalone]
Page 5 of 25 — ← Prev page 1 … 3 4 [5] 6 7 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web