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 13 of 25 — ← Prev page 1 … 11 12 [13] 14 15 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-16 13:47 +0200 |
| Message-ID | <118dvk6$3ac4e$1@dont-email.me> |
| In reply to | #402120 |
On 16/09/2026 12:21, bart wrote: > On 16/09/2026 08:08, David Brown wrote: >> On 15/09/2026 22:56, bart wrote: >> >>> So you've adapted to what you have and learned how to work >>> effectively with it. >>> >> >> You are forever trying to claim that this is somehow a bad thing. >> >> Most of us regulars here in comp.lang.c are not omnipotent, nor do we >> have unlimited time. We prefer to spend our time and effort on >> particular focused tasks - usually the tasks we get paid to do, or >> alternatively the tasks we enjoy doing. >> >> We cannot do /everything/ - there is not the time. I'm sure most of >> us, deep down, know that we could write a better C compiler than gcc >> or clang, and design a better language than C. >> >> But we don't have the time or inclination. We don't have the need. >> The tools that exist already do the job we need. We find convenient >> ways to make the whole process more efficient, and get on with the >> programming we actually want to do. (And we don't have to look far to >> find these methods - millions of developers use build systems and >> decent editors. We are not teenagers with a ZX Spectrum in our >> bedrooms, we are professionals who use professional tools.) >> >> What do you really want people here to do? Should we intentionally >> make our lives difficult by doing serial clean rebuilds all the time, >> and use MS Notepad as an editor, just so that we too can feel the pain >> and suffering you feel? Should we stop all our work, give up our >> jobs, and write our own C compilers? Should we spend have our life >> whining and moaning in Usenet groups and other online forums about how >> terrible C is and how bad compilers are, complaining to people who >> have no influence over any of it and can work fine with the language >> and tools? >> >> Or do you want us to bow down to you and exclaim our undying >> admiration for your language and compilers? > > No. But you don't need actively dislike them either or be so patronising > about them. > I am not dismissive about the language or tools - I have said many times that I think it is impressive that you've written a C compiler (however good, bad or indifferent it might be for anyone's uses), and the same about your languages. I am dismissive about your /claims/ based on these - your absurd comparisons to serious tools and real-world languages. > My language is probably the nearest to C in this class and level of > language, while also being very different in look and feel. It would be > foolish to just dismiss it. > It has no relevance in the world outside your bubble, so it is entirely reasonable to dismiss your language. If you had chosen a path of promoting your language and encouraging cooperation and collaboration, listening to feedback and working towards something that could be relevant to other people - then it would be a different matter. But you have chosen to assume that you, and you alone, can make the perfect language and perfect tools, and consider every other programmer, language designed and toolchain developer as amateurs incapable of making a decent language and tools. You chose to isolate yourself and your language, and to make it irrelevant. That is, of course, a choice you are free to make - and I am not in any way saying you made a bad choice here. You've had a successful career, and you have full control of your language - you do what you want with it, and don't have to consider anyone else or any knock-on effects when changing things. You can be justifiably proud of your achievements. The only thing you don't get to do is complain when no one takes your language seriously or considers it relevant to anyone else. >> >> I presume you are not interested in hearing that we too would be happy >> if compilers were faster, or that we too think that C has quirks, >> oddities, and aspects that we would prefer were different - if so, >> you'd have switched the broken record a couple of decades ago. >> >> So what would actually make you /happy/ here, and would let you change >> the subject? > What I would like is for somebody to actually admit that there might be > a problem instead of just brushing it under the carpet. > But we don't have a problem. We have the C language, and C compilers. And it's a good (not perfect) language for a lot of uses, with good (not perfect) tools. Programmers should use that language and tools where they are suitable, and different languages and tools where those are better choices. And the language and tools improve over time. > What I would like is to know that there is somebody out there who is > keeping on top of inefficiencies and checking that a simple task doesn't > take an inordinate and disproportionate amount of resources to do. > Why? What makes you think that toolchain vendors do not consider time and resource uses as a factor in their development? What makes you think that anyone in this Usenet group could do anything about it if we agreed with you? > I'm not saying that /you/ should do it or most who post here. You are > just the users who have to work with what's available, eg. by applying > more hardware resources and more ingenuity. > Note that this "ingenuity" - using a build system - has been considered standard practice for software development for perhaps half a century or more. > Even WH has said they have worked at improving the throughput of their > tools (although that was not for C). > There are plenty of situations where tools take significant time, and improving their speed is very much a priority (whether it is by improving the tools, or using faster hosts). C compilation is not one of those situations, for the vast majority of projects. Even for fairly big projects, such as the Linux kernel, the C compilation is only one part of the built time. The closest case is C++ compilation - big C++ projects can take a very long time to build. That is why the effort spent by clang, gcc and MSVC on improvement of build times is primarily for C++ and for link-time optimisation. Outside that, other tools such as simulations, testing, and serious code analysers can take a very long time to run. > The recent example of those SDL3 headers is a good one. Even without > needing to change the C language, or have super-fast compilers for it, > those headers are grossly inefficient. So what? I did the timings there. The savings achievable from "instant" headers would be tiny fractions of a second. I have not used SDL, and don't know anything about their development processes, but I am confident that most SDL users would rather the SDL developers prioritised features and run-time efficiency of the resulting binaries rather than saving 0.1 seconds per build. You are utterly obsessed with something that is utterly irrelevant in most cases (again, we are talking about C). > > Maybe you don't think this is interesting or relevant or you think it is > a waste of time. But if someone decided to add this to your favourite > compiler I bet you would use it! If I wanted to compile SDL code on my host, I'd use the SDL headers and the compiler on the host. If later versions of those SDL headers were re-organised for faster compiles, I'd use them if and when I updated the headers. I would not notice the saved milliseconds, but of course I would be using them. Would I use a compiler that has special fast-path handling of headers to skip extra includes, quickly discard unused code between "#if ... #endif" sets, and skim comments efficiently? Yes, I would use such a compiler - gcc has done so since very early versions, and I expect all other serious compilers do so too. > > In this case, it would reduce header code that needs to be processed / > per module/, by some 99%, not 95%. > > Note that this is the same sort of principle as gcc's precompiled > headers. But that doesn't simplify the headers at all; just pre- > tokenises or something. The 3.6MB of SDL3 headers turn into one giant > 30MB file. My approach would reduce them to one file of perhaps 0.2MB. > Your approach would make no difference to me (assuming I used SDL). I would not expect it to make a noticeable difference to anyone else doing real development work with the SDL libraries. There's a reason almost no one uses precompiled headers with C - it is rare that pure C projects have build times that are inconveniently long for development, and rarer still that this is because of headers.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-16 15:20 +0100 |
| Message-ID | <118e8k4$3f00c$1@dont-email.me> |
| In reply to | #402122 |
On 16/09/2026 12:47, David Brown wrote:
> On 16/09/2026 12:21, bart wrote:
>> The recent example of those SDL3 headers is a good one. Even without
>> needing to change the C language, or have super-fast compilers for it,
>> those headers are grossly inefficient.
>
> So what?
>
> I did the timings there. The savings achievable from "instant" headers
> would be tiny fractions of a second.
I don't really trust your figures. I've today done a mock-up of a
streamlined header for SDL3.
In this form it is a file of just over 6K lines (probably there's stuff
that doesn't need to be there, but it will suffice for this test).
So here are my figures for a single 'hello-world' test for SDL3:
sdl.h newsdl.h (normal vs compact)
gcc 0.88 seconds 0.34 seconds
gcc 0.24 seconds 0.22 seconds (using precompiled headers)
bcc 0.17 seconds 0.04 seconds
gcc 0.4 seconds 0.08 seconds (Linux/real time)
And this is the test for 50 files each including one of those headers:
sdl.h newsdl.h (normal vs compact)
gcc 38 seconds 6 seconds (gcc *.c)
bcc 8 seconds 1.7 seconds (bcc needs 50 invocations)
That looks quite worthwhile to me. Another advantage is that the header
is a single file that is easy to use, copy, bundle etc. You don't need
-I options.
> You are utterly obsessed with something that is utterly irrelevant in
> most cases (again, we are talking about C).
Let me ask you: how big, bloated and inefficient does such a header need
to be for you to think there is a problem? How much does it need to slow
down the build process?
Or would you invest in a server farm first before you will admit there
is a problem? Or is that only before you will admit it to me?
Here are some file sizes:
SDL3\*.h 3.6 MB
SDL3.dll 5.4 MB
newsdl.h 0.3 MB
sdl.h.gch 30.4 MB
newsdl.h.gch 7.2 MB
sdl.m 0.17MB
The DLL contains all the code to do all the work. The headers should
only define the interface, and yet they're nearly as big as the library
itself!
With these figures, performance is on a par with using gcc's precompiled
headers, for this project.
However, my newsdl.h file could be used for multiple compilers on
Windows. And it is 100 times smaller than that main .gch file.
(That last file is what my conversion tool produces from the same 3.6MB,
converting to bindings in my language. I don't know what unnecessary
crap is still within newsdl.h. Today was just a proof of concept.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-16 17:53 +0200 |
| Message-ID | <118ee2b$3cakn$1@dont-email.me> |
| In reply to | #402124 |
On 16/09/2026 16:20, bart wrote: > On 16/09/2026 12:47, David Brown wrote: >> On 16/09/2026 12:21, bart wrote: > >>> The recent example of those SDL3 headers is a good one. Even without >>> needing to change the C language, or have super-fast compilers for >>> it, those headers are grossly inefficient. >> >> So what? >> >> I did the timings there. The savings achievable from "instant" >> headers would be tiny fractions of a second. > > I don't really trust your figures. I've today done a mock-up of a > streamlined header for SDL3. You are using an older computer, an old version of an inappropriate OS (Windows has its strengths, good points and good uses - this is not one of them), and have consistently shown you have trouble getting toolchain installations to work. So I don't trust your numbers to be a realistic reflection of real-world timings for other developers. I /do/ trust that the numbers you post are the numbers that /you/ measured on /your/ system, however. You should similarly believe the numbers I give, even if you think that most people using SDL will have setups more like your own one. > > In this form it is a file of just over 6K lines (probably there's stuff > that doesn't need to be there, but it will suffice for this test). > > So here are my figures for a single 'hello-world' test for SDL3: > > sdl.h newsdl.h (normal vs compact) > gcc 0.88 seconds 0.34 seconds > gcc 0.24 seconds 0.22 seconds (using precompiled headers) > bcc 0.17 seconds 0.04 seconds > > gcc 0.4 seconds 0.08 seconds (Linux/real time) > > And this is the test for 50 files each including one of those headers: > > sdl.h newsdl.h (normal vs compact) > gcc 38 seconds 6 seconds (gcc *.c) > bcc 8 seconds 1.7 seconds (bcc needs 50 invocations) > > That looks quite worthwhile to me. I can certainly agree that it is faster. But I am far from convinced that it is worthwhile. A rational developer working on an SDL project in C of any reasonable size is likely to be using gcc on Linux, and not be using precompiled headers. They will also use "make" (or another build system) and will, for most re-builds during development, have more cores than the number of files that need to be re-compiled. So the only figure that counts is the 0.4 vs 0.08 timing. They can expect, on average, to save 0.3 seconds on their builds. Is it worth the SDL maintainers making a compact header, and being sure that it is always in sync? They could write automated tools to generate it, but it would be extra work, restrict what they can reasonably put in headers (to fit with their generator program), risk subtle problems, and mean that different people will use different sets of headers. No, it is not worth it. I don't have SDL3 - I have only looked at SDL2 headers, because I happen to have them on my system. I note that there are 26778 lines of code in the 78 header files, when comments and blank lines are omitted. That's a lot more than your 6K lines. I can't say if that is purely from pre-processor lines (which "cloc" counts, but you may have removed), or differences between SDL2 and SDL3. > Another advantage is that the header > is a single file that is easy to use, copy, bundle etc. You don't need - > I options. My test file contained a single line : #include <SDL2/SDL.h> and compiled with gcc -c test.c There are no -I options. Single header files are not particularly exciting for a library like this. They can be useful for some libraries, especially if no additional source files are needed (that's more a C++ thing than a C thing). But when I am also getting manual pages, shared library files, etc., with a single "apt install libsdl2-dev" or click in a graphical package manager, there's no significant advantage to single headers. But I do like that from an IDE, I can easily navigate into headers and see the real header file, along with information and brief documentation. (I don't know or care how nice this is in SDL, as I don't use it.) It is easier to navigate multiple small headers than one huge one (within reason, of course), and it is better to have at least some information in these headers. I realise you like single compact files. That's fair enough - your preferences are your own. Don't make the mistake of assuming they apply to everyone else. > >> You are utterly obsessed with something that is utterly irrelevant in >> most cases (again, we are talking about C). > > Let me ask you: how big, bloated and inefficient does such a header need > to be for you to think there is a problem? How much does it need to slow > down the build process? I've yet to use anything remotely too big. So any attempt at giving a number would be completely artificial. > > Or would you invest in a server farm first before you will admit there > is a problem? Or is that only before you will admit it to me? I have not found header sizes in C to be a problem, at any time. I haven't used SDL, but if I choose to do so, I do not expect the header sizes to be a problem. So without a problem, there is nothing to "admit". And if I do, one day, find a set of headers that I need to use and which I felt made my work slower and less productive, then I most certainly would find a solution that does not involve decades of whinging in a newsgroup. I can't say what the right solution would be without seeing a problem, but certainly a faster host would be a feasible option. (Distributed compilation is sometimes used for big C++ projects.) We do, in fact, have a build server at my office. It's just a mini-PC with a nice AMD multi-core laptop processor and 64 GB ram. It is used for building embedded Linux setups and kernels, because those builds take quite a while on some of the other developer's desktops. The headers are not an issue - the main inconvenience is the many bottlenecks of configuration scripts rather than the actual compiles.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 00:36 +0100 |
| Message-ID | <118f96l$3r91f$1@dont-email.me> |
| In reply to | #402127 |
On 16/09/2026 16:53, David Brown wrote:
> On 16/09/2026 16:20, bart wrote:
>> Another advantage is that the header is a single file that is easy to
>> use, copy, bundle etc. You don't need - I options.
>
> My test file contained a single line :
>
> #include <SDL2/SDL.h>
>
> and compiled with
>
> gcc -c test.c
>
> There are no -I options.
Where is your SDL2 folder located relative to the current directory?
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
c:\sdl>wsl
root@DESKTOP-11:/mnt/c/sdl# cat s.c
#include <SDL3/SDL.h>
root@DESKTOP-11:/mnt/c/sdl# gcc -c s.c
s.c:1:10: fatal error: SDL3/SDL.h: No such file or directory
1 | #include <SDL3/SDL.h>
| ^~~~~~~~~~~~
compilation terminated.
c:\sdl>gcc -c s.c
s.c:1:10: fatal error: SDL3/SDL.h: No such file or directory
1 | #include <SDL3/SDL.h>
| ^~~~~~~~~~~~
compilation terminated.
>
> Single header files are not particularly exciting for a library like
> this.
Why not? stb_image works fine as a single header for example (which also
contains the implementation). There are even sites that list
single-header libraries.
It is convenient for a user to have a library presented as just one
file. The binary SDL3.DLL is one file; what possible advantage is there,
to the user, for SDL.h to be anything other than a single self-contained
file too?
There is also the question of transparency: if there are two files (.dll
and .h) I can see easily if they are present or not, rather than be a
sprawling mess buried somewhere in your file system.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-16 16:59 -0700 |
| Message-ID | <118fago$3r7f3$1@kst.eternal-september.org> |
| In reply to | #402144 |
bart <bc@freeuk.com> writes:
> On 16/09/2026 16:53, David Brown wrote:
>> On 16/09/2026 16:20, bart wrote:
>>> Another advantage is that the header is a single file that is easy
>>> to use, copy, bundle etc. You don't need - I options.
>> My test file contained a single line :
>> #include <SDL2/SDL.h>
>> and compiled with
>> gcc -c test.c
>> There are no -I options.
>
> Where is your SDL2 folder located relative to the current directory?
On my system (Ubuntu 24.04), it's "/usr/include/SDL2". David's
system is probably similar.
> Was there some installation process that put the headers in a place
> where gcc will look for it without being told? Does it involve using
> 'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config. There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
> Mine is in the current directory (that is, ./SDL3 is a folder that
> contains the headers). gcc doesn't work without '-I.' on either OS:
Did you set that up manually? If you had two projects that use SDL,
would you have to create "./SDL3" folders in both of them?
[...]
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 01:49 +0100 |
| Message-ID | <118fdf6$3sh4s$1@dont-email.me> |
| In reply to | #402145 |
On 17/09/2026 00:59, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 16/09/2026 16:53, David Brown wrote: >>> On 16/09/2026 16:20, bart wrote: >>>> Another advantage is that the header is a single file that is easy >>>> to use, copy, bundle etc. You don't need - I options. >>> My test file contained a single line : >>> #include <SDL2/SDL.h> >>> and compiled with >>> gcc -c test.c >>> There are no -I options. >> >> Where is your SDL2 folder located relative to the current directory? > > On my system (Ubuntu 24.04), it's "/usr/include/SDL2". David's > system is probably similar. > >> Was there some installation process that put the headers in a place >> where gcc will look for it without being told? Does it involve using >> 'pkg-config'? > > Yes, installing the Ubuntu package "libsdl2-dev" created and > populated the /usr/include/SDL2 directory, among other things. > That's a typical approach for Unix-like systems. > > pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears > to work without invoking pkg-config. There may be more to it than > that, but I don't use SDL so I haven't looked into it. > > I have no idea how you'd set it up on Windows, but ... And I've no idea where gcc would look for its headers, other than where it keeps its system headers, or how to set it up to look permanently in certain places. > >> Mine is in the current directory (that is, ./SDL3 is a folder that >> contains the headers). gcc doesn't work without '-I.' on either OS: > > Did you set that up manually? If you had two projects that use SDL, > would you have to create "./SDL3" folders in both of them? For this test I wanted the simplest possible set up. If using it for real then I'd have to choose a centralised place to them, and impart that info to the compiler. This is where a single compact header can make things very easy: c:\demo>dir 16/09/2026 13:57 304,760 newsdl.h 02/09/2026 17:24 5,380,925 SDL3.dll 08/09/2026 19:25 2,196 test.c test.c is my app; SDL3.dll is the library; and newsdl.h is the compacted interface. I could add one more file (bcc.exe) and I would have everything needed to write some SDL programs. I could copy them to a memory stick for example, whereas a gcc installation is big and messy. This is it in action: c:\demo>bcc test sdl3.dll Compiling test.c to test.exe c:\demo>gcc test.c sdl3.dll -o text c:\demo>tcc test.c sdl3.dll
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-16 19:43 -0700 |
| Message-ID | <118fk43$3u5tl$1@kst.eternal-september.org> |
| In reply to | #402146 |
bart <bc@freeuk.com> writes:
> On 17/09/2026 00:59, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 16/09/2026 16:53, David Brown wrote:
>>>> On 16/09/2026 16:20, bart wrote:
>>>>> Another advantage is that the header is a single file that is easy
>>>>> to use, copy, bundle etc. You don't need - I options.
>>>> My test file contained a single line :
>>>> #include <SDL2/SDL.h>
>>>> and compiled with
>>>> gcc -c test.c
>>>> There are no -I options.
>>>
>>> Where is your SDL2 folder located relative to the current directory?
>> On my system (Ubuntu 24.04), it's "/usr/include/SDL2". David's
>> system is probably similar.
>>
>>> Was there some installation process that put the headers in a place
>>> where gcc will look for it without being told? Does it involve using
>>> 'pkg-config'?
>>
>> Yes, installing the Ubuntu package "libsdl2-dev" created and
>> populated the /usr/include/SDL2 directory, among other things.
>> That's a typical approach for Unix-like systems.
>> pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
>> to work without invoking pkg-config. There may be more to it than
>> that, but I don't use SDL so I haven't looked into it.
>> I have no idea how you'd set it up on Windows, but ...
>
> And I've no idea where gcc would look for its headers, other than
> where it keeps its system headers, or how to set it up to look
> permanently in certain places.
I acknowledge that you don't know. I'm not going to assume that you
want to know. If you do, I suggest asking elsewhere, since it's a
question about gcc on Windows, not about the C language.
As you know, gcc was originally designed to work on Unix-like systems.
Windows support is an afterthought.
>>> Mine is in the current directory (that is, ./SDL3 is a folder that
>>> contains the headers). gcc doesn't work without '-I.' on either OS:
>>
>> Did you set that up manually? If you had two projects that use SDL,
>> would you have to create "./SDL3" folders in both of them?
>
> For this test I wanted the simplest possible set up. If using it for
> real then I'd have to choose a centralised place to them, and impart
> that info to the compiler.
Fair enough.
> This is where a single compact header can make things very easy:
[snip]
In my experience installing and using software, having a single
compact header doesn't make a lot of difference. I follow the
usual conventions for the OS or library I'm using. Typically a
man page will tell me what #include directive(s) I need. I often
don't know or care whether the header includes other headers. YMMV.
[...]
--
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 | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-09-17 09:24 +0200 |
| Message-ID | <118g4it$4hd$1@news.gegeweb.eu> |
| In reply to | #402146 |
On 9/17/26 02:49, bart wrote:
>
> And I've no idea where gcc would look for its headers, other than where
> it keeps its system headers, or how to set it up to look permanently in
> certain places.
You just have to read the fscking manual.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
But as everyone knows, learning new things isn't
part of your philosophy...
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 11:29 +0100 |
| Message-ID | <118gfe8$7bab$1@dont-email.me> |
| In reply to | #402150 |
On 17/09/2026 08:24, tTh wrote:
> On 9/17/26 02:49, bart wrote:
>>
>> And I've no idea where gcc would look for its headers, other than
>> where it keeps its system headers, or how to set it up to look
>> permanently in certain places.
>
> You just have to read the fscking manual.
>
> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more. In any case, none of those
listed are set. So I still don't know how gcc even manages to find its
own system headers. But I don't care.
gcc on Windows is poor at this anyway: if I have two gcc versions
installed, then they clash, and gcc.exe doesn't appear to use paths
relative to itself to find its dependent binaries.
> But as everyone knows, learning new things isn't
> part of your philosophy...
I don't care about individual compilers, especially gcc which is a PITA
in working differently from other C compilers, apart from those which
slavishly copy all it behaviours. Examples:
Compile prog.c to prog.exe:
Produces:
bcc prog prog.exe
tcc prog.c prog.exe
gcc proc.c a.exe
gcc prog.c -o prog prog.exe
Compile prog.c to prog.dll:
bcc -dll prog prog.dll
tcc -shared prog.c prog.dll
gcc -shared proc.c a.exe
gcc -shared prog.c -o prog prog.exe
gcc -shared prog.c -o prog.dll prog.dll
Here it takes 3 goes with gcc to do the right thing! It doesn't help
that it doesn't tell you what file it just wrote.
Oh, I should use '--verbose'? That produces the pile of crap shown
below, which is so helpful! This is bcc in action::
c:\c>bcc -dll prog
Compiling prog.c to prog.dll
As a driver program gcc is a POS. Look above at how far to the right
that output column is in order to accommodate all its options!
Oh, I should put such options into a file? OK, let's try that; here
'input' contains:
.\prog.c
However, it doesn't work:
c:\c>gcc @input
cc1.exe: fatal error: .prog.c: No such file or directory
compilation terminated.
Apparently it doesn't like that '\', although it is a valid Windows path
separator. I have to write '.\\prog.c' instead. Yet both bcc and tcc are
fine with it.
One more thing on that error message: it shows 'cc1.exe' which I don't
see on my console. Apparently, gcc displays that in light grey, which is
the same colour as my background! But for the actual error messages, it
sets the background to black - AND IT DOESN'T RESTORE THE COLOURS
AFTERWARDS.
Bastard. (TBF, Clang is worse: all the errors are shown as light grey,
so I can't see them at all!)
Any more bizarre quirks? Probably loads, and probably because that's how
gcc or its predecessor worked on Unix in 1871 and it was impossible to
ever change it.
So you can keep your stinkin' compiler.
-------------------------------------------------------
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs_staging_msvcrt64/inst_gcc-14.2.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-msvcrt-posix-seh, built by Brecht Sanders, r3'
--with-tune=generic --enable-checking=release --enable-threads=posix
--disable-sjlj-exceptions --disable-libunwind-exceptions
--disable-serial-configure --disable-bootstrap --enable-host-shared
--enable-plugin --disable-default-ssp --disable-rpath
--disable-libstdcxx-debug --disable-version-specific-runtime-libs
--disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++
--disable-gold --disable-nls --disable-stage1-checking
--disable-win32-registry --disable-multilib --enable-ld
--enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx
--enable-lto --enable-fully-dynamic-string --enable-libgomp
--enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time
--enable-libstdcxx-pch
--with-mpc=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--with-mpfr=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--with-gmp=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--with-isl=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--disable-libstdcxx-backtrace --enable-install-libiberty
--enable-__cxa_atexit --without-included-gettext
--with-diagnostics-color=auto --enable-clocale=generic --with-libiconv
--with-system-zlib
--with-build-sysroot=/R/winlibs_staging_msvcrt64/gcc-14.2.0/build_mingw/mingw-w64
CFLAGS='-I/c/Prog/winlibs_staging_msvcrt/custombuilt64/include/libdl-win32
-march=nocona -msahf -mtune=generic -O2 -Wno-error=format'
CXXFLAGS='-Wno-int-conversion -march=nocona -msahf -mtune=generic -O2'
LDFLAGS='-pthread -Wl,--no-insert-timestamp -Wl,--dynamicbase
-Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware'
LD=/c/Prog/winlibs_staging_msvcrt/custombuilt64/share/binutils/bin/ld.exe
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht
Sanders, r3)
COLLECT_GCC_OPTIONS='-shared' '-v' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/cc1.exe -quiet -v
-iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/ -D_REENTRANT
prog.c -quiet -dumpdir a- -dumpbase prog.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -version -o
C:\Users\44775\AppData\Local\Temp\ccpHFYOB.s
GNU C17 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders, r3)
version 14.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 14.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/14.2.0/include"
ignoring nonexistent directory
"R:/winlibs_staging_msvcrt64/inst_gcc-14.2.0/share/gcc/include"
ignoring nonexistent directory
"/R/winlibs_staging_msvcrt64/inst_gcc-14.2.0/share/gcc/include"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/14.2.0/include-fixed"
ignoring duplicate directory
"C:/tdm/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/include
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../include
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/include-fixed
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
Compiler executable checksum: 63b0164ba34d2bddc0314ced79a81f9e
COLLECT_GCC_OPTIONS='-shared' '-v' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/as.exe -v -o C:\Users\44775\AppData\Local\Temp\ccMkclh8.o C:\Users\44775\AppData\Local\Temp\ccpHFYOB.s
GNU assembler version 2.44 (x86_64-w64-mingw32) using BFD version
(Binutils for MinGW-W64 x86_64, built by Brecht Sanders, r3) 2.44
COMPILER_PATH=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/;C:/tdm/bin/../libexec/gcc/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/;C:/tdm/bin/../lib/gcc/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/lib/;C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../
COLLECT_GCC_OPTIONS='-shared' '-v' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a.'
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/collect2.exe
-plugin
C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/liblto_plugin.dll
-plugin-opt=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\44775\AppData\Local\Temp\cctuIjoG.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lkernel32 -m i386pep --shared -Bdynamic -e
DllMainCRTStartup --enable-auto-image-base
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/crtbegin.o
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0
-LC:/tdm/bin/../lib/gcc
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/lib/../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/lib
-LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../..
C:\Users\44775\AppData\Local\Temp\ccMkclh8.o -lmingw32 -lgcc_s -lgcc
-lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32
-lkernel32 -lmingw32 -lgcc_s -lgcc -lmingwex -lmsvcrt -lkernel32
C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/crtend.o
COLLECT_GCC_OPTIONS='-shared' '-v' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a.'
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-17 15:06 -0700 |
| Message-ID | <118hoa1$mqr3$1@kst.eternal-september.org> |
| In reply to | #402156 |
bart <bc@freeuk.com> writes:
> On 17/09/2026 08:24, tTh wrote:
>> On 9/17/26 02:49, bart wrote:
>>> And I've no idea where gcc would look for its headers, other than
>>> where it keeps its system headers, or how to set it up to look
>>> permanently in certain places.
>> You just have to read the fscking manual.
>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
>
> Nobody uses environment variables any more.
Obviously untrue.
> In any case, none of those
> listed are set. So I still don't know how gcc even manages to find its
> own system headers. But I don't care.
If you don't care, please stop talking about it. A lot of people,
myself included, post here because they enjoy helping other people by
answering questions and providing information and advice. If you say
that you don't know something, people are going to waste their time
trying to educate you.
> gcc on Windows is poor at this anyway: if I have two gcc versions
> installed, then they clash, and gcc.exe doesn't appear to use paths
> relative to itself to find its dependent binaries.
I doubt that gcc is at fault for that, assuming it's true.
gcc on Windows is typically installed as part of a larger package
(since a compiler by itself can't generate executables). It's the
responsibility of the gcc+FOO and gcc+BAR installers to arrange
for their respecive gcc's to avoid conflicting with each other.
Packaging gcc for Windows is more difficult than packaging gcc
for Unix-like systems.
>> But as everyone knows, learning new things isn't
>> part of your philosophy...
>
> I don't care about individual compilers, especially gcc which is a
> PITA in working differently from other C compilers, apart from those
> which slavishly copy all it behaviours. Examples:
You say you don't care about gcc. I don't think that's what you mean,
given how much you talk about it.
[57 lines deleted]
> So you can keep your stinkin' compiler.
OK. Are we done?
[116 lines deleted]
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-18 02:04 +0100 |
| Message-ID | <118i2mc$q9l1$1@dont-email.me> |
| In reply to | #402191 |
On 17/09/2026 23:06, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 17/09/2026 08:24, tTh wrote: >>> On 9/17/26 02:49, bart wrote: >>>> And I've no idea where gcc would look for its headers, other than >>>> where it keeps its system headers, or how to set it up to look >>>> permanently in certain places. >>> You just have to read the fscking manual. >>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html >> >> Nobody uses environment variables any more. > > Obviously untrue. Let's say they're out of fashion. >> gcc on Windows is poor at this anyway: if I have two gcc versions >> installed, then they clash, and gcc.exe doesn't appear to use paths >> relative to itself to find its dependent binaries. > > I doubt that gcc is at fault for that, assuming it's true. > gcc on Windows is typically installed as part of a larger package > (since a compiler by itself can't generate executables). I think the problem was that gcc runs support programs such as cc1.exe by relying on Windows to search the default paths. But if you have two versions A and B, and both their paths are listed in the PATH variable, then when B's gcc tries to run cc1.exe, it will be A's version, as A's path is listed first. > It's the> responsibility of the gcc+FOO and gcc+BAR installers to arrange > for their respecive gcc's to avoid conflicting with each other. > Packaging gcc for Windows is more difficult than packaging gcc > for Unix-like systems. It's not hard; it should really have used a path relative to B's gcc.exe. It would still pick A's gcc.exe if typing an unqualified 'gcc' by itself, but how does Linux solve this problem when you have two gcc's to choose from? >>> But as everyone knows, learning new things isn't >>> part of your philosophy... >> >> I don't care about individual compilers, especially gcc which is a >> PITA in working differently from other C compilers, apart from those >> which slavishly copy all it behaviours. Examples: > > You say you don't care about gcc. I don't think that's what you mean, > given how much you talk about it. I don't care about having to give special treatment to different compilers. I only use three now (bcc, tcc, gcc), and gcc is a nuisance because of its stupid defaults. In this case I was investigating the impact of large headers across a codebase. The impact would likely be bigger on gcc because it is slower. I'm not that interested in gcc as a C compiler or in fixing it, but it is fascinating in how bad it is at many things and /that/ is interesting to me to discuss. Every single one of those things (other than build-speed) will have some option to fix it or to work around it if you dig enough, but I have no inclination to do that. I believe such tools should just work with the minimum of fuss. The sweetest of all is my own bcc, but that is the worst at supporting arbitrary C code, so sometimes I have to use another. >> So you can keep your stinkin' compiler. > OK. Are we done? So, no comment on the fact that it can take three goes before gcc gets the DLL extension right? (It fact it never does; you have to specify it in the end. It seems to understand about 'exe' but is too stupid to know that -shared needs 'dll'.) > [116 lines deleted] >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-17 18:19 -0700 |
| Message-ID | <118i3ij$mqr3$6@kst.eternal-september.org> |
| In reply to | #402201 |
bart <bc@freeuk.com> writes:
> On 17/09/2026 23:06, Keith Thompson wrote:
[...]
>> You say you don't care about gcc. I don't think that's what you
>> mean, given how much you talk about it.
>
> I don't care about having to give special treatment to different compilers.
You obviously care very much about that.
I think that when you say "I don't care about ...", you really mean
"I don't like ...". You need to learn to communicate clearly.
[...]
> So, no comment on the fact that it can take three goes before gcc gets
> the DLL extension right?
[...]
Correct. I have no comment on it because (a) it's not about the
C programming language, the topic of this newsgroup, and (b) I do
not care about it.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-18 11:27 +0200 |
| Message-ID | <118j056$14tgj$1@dont-email.me> |
| In reply to | #402201 |
On 18/09/2026 03:04, bart wrote: > On 17/09/2026 23:06, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 17/09/2026 08:24, tTh wrote: >>>> On 9/17/26 02:49, bart wrote: >>>>> And I've no idea where gcc would look for its headers, other than >>>>> where it keeps its system headers, or how to set it up to look >>>>> permanently in certain places. >>>> You just have to read the fscking manual. >>>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html >>> >>> Nobody uses environment variables any more. >> >> Obviously untrue. > > Let's say they're out of fashion. Let's not. Lots of people use them for various purposes. It is fair to say that Windows makes it a lot more of a hassle to make "permanent" changes to environment variables than *nix systems (or things like a "msys2 terminal" on Windows). And it is fair to say that some modern computer users can't cope with actually /typing/ something, rather than clicking on a box somewhere. But other people who like to have their computer and programs work the way they want them to, /do/ set environment variables in various ways and circumstances - "permanent" changes in their .bashrc files (or Windows settings), or local changes in scripts, command aliases, prefixes to commands, makefiles, whatever. For example, I found some of the coloured output of "grep" difficult to read with the background colour I use in my terminals. I considered writing multiple posts in this group about how inconsiderate the "grep" authors are and how their bloated tool doesn't even look nice on my system. But in the end I decided to google for "change grep colours" as a short-cut for looking up the syntax, and a few minutes later I had a line in my .bashrc file with an environment variable to give grep colours that suited me better. > >>> gcc on Windows is poor at this anyway: if I have two gcc versions >>> installed, then they clash, and gcc.exe doesn't appear to use paths >>> relative to itself to find its dependent binaries. >> >> I doubt that gcc is at fault for that, assuming it's true. >> gcc on Windows is typically installed as part of a larger package >> (since a compiler by itself can't generate executables). > > I think the problem was that gcc runs support programs such as cc1.exe > by relying on Windows to search the default paths. > > But if you have two versions A and B, and both their paths are listed in > the PATH variable, then when B's gcc tries to run cc1.exe, it will be > A's version, as A's path is listed first. It is conceivable that the folks behind this "winlib" packaging are idiots. But assuming they are not, then "cc1.exe" will not be in your path. The gcc driver program finds the additional parts in a path dependent on the way it was configured when built. When I type "gcc" on my machine, this finds /usr/bin/gcc. That file is a symbolic link pointing to "gcc-13", thus /usr/bin/gcc-13. That is also a symbolic link, pointing to the real gcc driver program called x86_64-linux-gnu-gcc-13. (The prefix here is a standard gcc name triplet with the target, OS and ABI.) When the program "x86_64-linux-gnu-gcc-13" wants to run "cc1", it finds it in the path ../libexec/gcc/x86_64-linux-gnu-gcc/13/. This way, the four different versions of native gcc that I have all find their own matching sub-programs, libraries, etc. Builds of gcc can have different configurations. Another Linux distro might build their gcc packages so that instead of using just 13 as the version number, they have 13.3.0. That would be useful if you wanted to have more than one gcc version 13.x.y installed at the same time - a level of detail that most users, and most distros, don't bother with. (For embedded cross-compilers, it's a different matter and precise revisions are important.) I don't know how "winlib" does their gcc configuration, or what (if any) path modifications its installer makes. Clearly it can't use exactly the same system as I described for Linux, because Windows doesn't support symbolic links. But if its installer changes your path to add the directory containing "cc1.exe", or puts "cc1.exe" in the same directory as your gcc, then it is doing things wrong and you should file that as a major bug in "winlib". > > > It's the> responsibility of the gcc+FOO and gcc+BAR installers to > arrange >> for their respecive gcc's to avoid conflicting with each other. >> Packaging gcc for Windows is more difficult than packaging gcc >> for Unix-like systems. > > It's not hard; it should really have used a path relative to B's gcc.exe. > That is what gcc does, yes. > It would still pick A's gcc.exe if typing an unqualified 'gcc' by > itself, but how does Linux solve this problem when you have two gcc's to > choose from? If I want gcc version 12, I use "gcc-12". If I want gcc version 14, I use "gcc-14". "gcc-13" is the standard gcc version for the particular version of the particular distro that I have on my work PC at the moment, so that is what I get with "gcc". The process by which the correct "cc1" is found is explained above. For other gcc's that are not native and part of the distro, I have the toolchains installed in individual directories, and refer to them by path, such as : /opt/arm-gnu-toolchain-15.2.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc Of the path is given just once as a variable in my makefiles, so I don't have to specify it when building projects - and each project uses the version of gcc (and libraries) picked for the project.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-18 11:21 +0100 |
| Message-ID | <118j3am$1663s$1@dont-email.me> |
| In reply to | #402215 |
On 18/09/2026 10:27, David Brown wrote: > On 18/09/2026 03:04, bart wrote: >> But if you have two versions A and B, and both their paths are listed >> in the PATH variable, then when B's gcc tries to run cc1.exe, it will >> be A's version, as A's path is listed first. > > It is conceivable that the folks behind this "winlib" packaging are > idiots. But assuming they are not, then "cc1.exe" will not be in your > path. The gcc driver program finds the additional parts in a path > dependent on the way it was configured when built. I've just tried two WINLIBS gcc versions, and now they work fine, if you use an explicit path to their respective gcc.exe files. The issue may have been with TDM distributions that I used to use. But WINLIBS has newer gcc versions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-18 13:17 +0200 |
| Message-ID | <118j6k2$16vae$2@dont-email.me> |
| In reply to | #402221 |
On 18/09/2026 12:21, bart wrote: > On 18/09/2026 10:27, David Brown wrote: >> On 18/09/2026 03:04, bart wrote: > >>> But if you have two versions A and B, and both their paths are listed >>> in the PATH variable, then when B's gcc tries to run cc1.exe, it will >>> be A's version, as A's path is listed first. >> >> It is conceivable that the folks behind this "winlib" packaging are >> idiots. But assuming they are not, then "cc1.exe" will not be in your >> path. The gcc driver program finds the additional parts in a path >> dependent on the way it was configured when built. > > I've just tried two WINLIBS gcc versions, and now they work fine, if you > use an explicit path to their respective gcc.exe files. > > The issue may have been with TDM distributions that I used to use. But > WINLIBS has newer gcc versions. > > That is useful to know if I ever feel the need to have a newer gcc version on Windows. (It's unlikely, as these days I use my sole Windows machine so rarely I don't even have it connected to a screen and keyboard, but it is not impossible.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-18 15:44 +0000 |
| Message-ID | <f%crS.41209$KV1.20877@fx09.iad> |
| In reply to | #402215 |
David Brown <david.brown@hesbynett.no> writes: >On 18/09/2026 03:04, bart wrote: >> On 17/09/2026 23:06, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 17/09/2026 08:24, tTh wrote: >>>>> On 9/17/26 02:49, bart wrote: >>>>>> And I've no idea where gcc would look for its headers, other than >>>>>> where it keeps its system headers, or how to set it up to look >>>>>> permanently in certain places. >>>>> You just have to read the fscking manual. >>>>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html >>>> >>>> Nobody uses environment variables any more. >>> >>> Obviously untrue. >> >> Let's say they're out of fashion. > >Let's not. Lots of people use them for various purposes. Indeed, they're ubiquitous. Cf. $PATH, $HOME, $LANG (and $LC_*), $TERM are used extensively.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-19 09:16 +0200 |
| Message-ID | <118lct0$scqg$1@dont-email.me> |
| In reply to | #402239 |
On 2026-09-18 17:44, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 18/09/2026 03:04, bart wrote: >>> On 17/09/2026 23:06, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 17/09/2026 08:24, tTh wrote: >>>>>> On 9/17/26 02:49, bart wrote: >>>>>>> And I've no idea where gcc would look for its headers, other than >>>>>>> where it keeps its system headers, or how to set it up to look >>>>>>> permanently in certain places. >>>>>> You just have to read the fscking manual. >>>>>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html >>>>> >>>>> Nobody uses environment variables any more. >>>> >>>> Obviously untrue. >>> >>> Let's say they're out of fashion. >> >> Let's not. Lots of people use them for various purposes. > > Indeed, they're ubiquitous. Cf. $PATH, $HOME, $LANG (and $LC_*), $TERM > are used extensively. Yes, these are the typical "standard" ones we use and ever used on Unix (and maybe also elsewhere). But I think the poster may have other environment variables in mind; those that programmers invent and users (system configurators) set. It had been indeed not uncommon - I wouldn't call that "in vogue", though - that environment variables were used to pass arguments to a system. This way of parameterizing is IME very error prone, since you "control" software in an obscure way. (That's why our standards deprecated use of environment variables, or rather, allowed just a single one per (sub-)project (as an entry point to the software configuration). The software configuration was generally all done by transparent and comprehensible parameter files.) Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-09-18 12:55 +0000 |
| Message-ID | <118jcbf$kv9$1@reader1.panix.com> |
| In reply to | #402201 |
In article <118i2mc$q9l1$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 17/09/2026 23:06, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 17/09/2026 08:24, tTh wrote: >>>> On 9/17/26 02:49, bart wrote: >>>>> And I've no idea where gcc would look for its headers, other than >>>>> where it keeps its system headers, or how to set it up to look >>>>> permanently in certain places. >>>> You just have to read the fscking manual. >>>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html >>> >>> Nobody uses environment variables any more. >> >> Obviously untrue. > >Let's say they're out of fashion. Why would you say such a thing? While they may not be the most elegant solution to a number of problems, they're very much in use, and "in fashion", at least on Unix-derived systems. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-18 17:53 +0300 |
| Message-ID | <20260918175317.00002a73@yahoo.com> |
| In reply to | #402224 |
On Fri, 18 Sep 2026 12:55:11 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <118i2mc$q9l1$1@dont-email.me>, bart <bc@freeuk.com> > wrote: > >On 17/09/2026 23:06, Keith Thompson wrote: > >> bart <bc@freeuk.com> writes: > >>> On 17/09/2026 08:24, tTh wrote: > >>>> On 9/17/26 02:49, bart wrote: > >>>>> And I've no idea where gcc would look for its headers, other > >>>>> than where it keeps its system headers, or how to set it up to > >>>>> look permanently in certain places. > >>>> Â Â You just have to read the fscking manual. > >>>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html > >>> > >>> Nobody uses environment variables any more. > >> > >> Obviously untrue. > > > >Let's say they're out of fashion. > > Why would you say such a thing? While they may not be the most > elegant solution to a number of problems, they're very much in > use, and "in fashion", at least on Unix-derived systems. > > - Dan C. > Would you design a new program which behavior can be modified by environment variables? I don't mean standard environment variables, like locale (although that is also less than great) but environment variables specific to your program?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-18 15:47 +0000 |
| Message-ID | <V1drS.41210$KV1.6212@fx09.iad> |
| In reply to | #402227 |
Michael S <already5chosen@yahoo.com> writes: >On Fri, 18 Sep 2026 12:55:11 -0000 (UTC) >cross@spitfire.i.gajendra.net (Dan Cross) wrote: > >> In article <118i2mc$q9l1$1@dont-email.me>, bart <bc@freeuk.com> >> wrote: >> >On 17/09/2026 23:06, Keith Thompson wrote: =20 >> >> bart <bc@freeuk.com> writes: =20 >> >>> On 17/09/2026 08:24, tTh wrote: =20 >> >>>> On 9/17/26 02:49, bart wrote: =20 >> >>>>> And I've no idea where gcc would look for its headers, other >> >>>>> than where it keeps its system headers, or how to set it up to >> >>>>> look permanently in certain places. =20 >> >>>> =C2=A0=C2=A0 You just have to read the fscking manual. >> >>>> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html =20 >> >>> >> >>> Nobody uses environment variables any more. =20 >> >>=20 >> >> Obviously untrue. =20 >> > >> >Let's say they're out of fashion. =20 >>=20 >> Why would you say such a thing? While they may not be the most >> elegant solution to a number of problems, they're very much in >> use, and "in fashion", at least on Unix-derived systems. >>=20 >> - Dan C. >>=20 > >Would you design a new program which behavior can be modified by >environment variables? I don't mean standard environment variables, like >locale (although that is also less than great) but environment >variables specific to your program? > Absolutely. And they would be well documented in the manual page for the program. LD_DEBUG, for example, is quite useful in certain usage cases and effectively impossible to handle with a command line option flag.
[toc] | [prev] | [next] | [standalone]
Page 13 of 25 — ← Prev page 1 … 11 12 [13] 14 15 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web