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 14 of 25 — ← Prev page 1 … 12 13 [14] 15 16 … 25 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-19 21:22 +0300 |
| Message-ID | <20260919212251.00003f93@yahoo.com> |
| In reply to | #402240 |
On Fri, 18 Sep 2026 15:47:01 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > 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. Why impossible? Because devs of gnu ld.so were inconsistent or for other reasons?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-20 15:58 +0000 |
| Message-ID | <DoTrS.40144$iUXd.26369@fx04.iad> |
| In reply to | #402285 |
Michael S <already5chosen@yahoo.com> writes: >On Fri, 18 Sep 2026 15:47:01 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> LD_DEBUG, for example, is quite useful in certain usage cases and >> effectively impossible to handle with a command line option flag. > >Why impossible? >Because devs of gnu ld.so were inconsistent or for other reasons? Because to do so, you would need to modify and rebuild your application. Exporting LD_DEBUG before you start the application requires no changes to the application - and given the RTLD isn't technically part of the application and most developers don't build their own RTLD, it doesn't make sense to include run-time loader debugging capabilities in applications.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-21 21:06 +0300 |
| Message-ID | <20260921210626.00001074@yahoo.com> |
| In reply to | #402308 |
On Sun, 20 Sep 2026 15:58:27 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Fri, 18 Sep 2026 15:47:01 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > > >> LD_DEBUG, for example, is quite useful in certain usage cases and > >> effectively impossible to handle with a command line option flag. > > > >Why impossible? > >Because devs of gnu ld.so were inconsistent or for other reasons? > > Because to do so, you would need to modify and rebuild your > application. > > Exporting LD_DEBUG before you start the application requires no > changes to the application - and given the RTLD isn't technically > part of the application and most developers don't build their > own RTLD, it doesn't make sense to include run-time loader debugging > capabilities in applications. The question was about possibilty to call your app via "ld.so myapp -relevant-flags". Or, may be, via gdb. Or some other utility of that sort. The field is completely alien to me, so I can easily miss something.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-22 15:04 +0000 |
| Message-ID | <GNwsS.87969$5X3.74718@fx12.iad> |
| In reply to | #402326 |
Michael S <already5chosen@yahoo.com> writes: >On Sun, 20 Sep 2026 15:58:27 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >On Fri, 18 Sep 2026 15:47:01 GMT >> >scott@slp53.sl.home (Scott Lurndal) wrote: >> > >> >> >> LD_DEBUG, for example, is quite useful in certain usage cases and >> >> effectively impossible to handle with a command line option flag. >> > >> >Why impossible? >> >Because devs of gnu ld.so were inconsistent or for other reasons? >> >> Because to do so, you would need to modify and rebuild your >> application. >> >> Exporting LD_DEBUG before you start the application requires no >> changes to the application - and given the RTLD isn't technically >> part of the application and most developers don't build their >> own RTLD, it doesn't make sense to include run-time loader debugging >> capabilities in applications. > >The question was about possibilty to call your app via "ld.so myapp >-relevant-flags". Why? Leaving aside the difficulty of disambiguating flags for the app from flags for ld.so before starting the app, LD_DEBUG works great and there is no reason to change it.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-22 21:07 +0300 |
| Message-ID | <20260922210704.0000390a@yahoo.com> |
| In reply to | #402337 |
On Tue, 22 Sep 2026 15:04:06 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Sun, 20 Sep 2026 15:58:27 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> >On Fri, 18 Sep 2026 15:47:01 GMT > >> >scott@slp53.sl.home (Scott Lurndal) wrote: > >> > > >> > >> >> LD_DEBUG, for example, is quite useful in certain usage cases > >> >> and effectively impossible to handle with a command line option > >> >> flag. > >> > > >> >Why impossible? > >> >Because devs of gnu ld.so were inconsistent or for other reasons? > >> > > >> > >> Because to do so, you would need to modify and rebuild your > >> application. > >> > >> Exporting LD_DEBUG before you start the application requires no > >> changes to the application - and given the RTLD isn't technically > >> part of the application and most developers don't build their > >> own RTLD, it doesn't make sense to include run-time loader > >> debugging capabilities in applications. > > > >The question was about possibilty to call your app via "ld.so myapp > >-relevant-flags". > > Why? Leaving aside the difficulty of disambiguating flags for > the app from flags for ld.so before starting the app, LD_DEBUG > works great and there is no reason to change it. > > Out of prnciples like: - when you do something atomically it is less likely to bite your a*s then the same thing done via several steps. - stateless preferable over stateful. Yes, both reasons are too abstract, I know.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-18 15:41 +0000 |
| Message-ID | <TYcrS.41208$KV1.27461@fx09.iad> |
| In reply to | #402201 |
bart <bc@freeuk.com> writes: >On 17/09/2026 23:06, Keith Thompson 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'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? One can use modules: $ type gcc gcc is a tracked alias for /usr/bin/gcc $ gcc --version gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ module use --append /nfs/Software/module/my-common/modulefiles $ module load gcc/11.3 $ gcc --version gcc (GCC) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ type gcc gcc is a tracked alias for /nfs/asim/Software/bin/gcc-11.3.0/bin/gcc Generally when supporting multiple gcc releases, you'll also need multiple binutils releases (in case the compiler generates newer assembler instructions that aren't supported in older versions of as(1)). > >So, no comment on the fact that it can take three goes before gcc gets >the DLL extension right? Keith has explained many times that the GNU Compiler development team develops for Unix, not Windows. Unix doesnt have DLLs (it does have shared objects, which IMO are superior to windows DLLs).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-18 11:34 -0700 |
| Message-ID | <118k08j$1grii$4@kst.eternal-september.org> |
| In reply to | #402238 |
scott@slp53.sl.home (Scott Lurndal) writes:
> bart <bc@freeuk.com> writes:
>>On 17/09/2026 23:06, Keith Thompson 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'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?
>
> One can use modules:
[...]
> $ module use --append /nfs/Software/module/my-common/modulefiles
> $ module load gcc/11.3
[...]
On Ubuntu, the "module" command isn't installed by default. You can
install it via the "environment-modules" package. (I've used it
on SGI and Cray systems, where it originated, but not on Ubuntu,
and not in the last couple of decades or so.)
[...]
--
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-17 12:52 +0200 |
| Message-ID | <118ggp7$7jhf$1@dont-email.me> |
| In reply to | #402146 |
On 17/09/2026 02:49, bart wrote: > 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. touch empty.c gcc -E -v empty.c That will show you, amongst other things, the default include paths. On my system, it shows : #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/13/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include End of search list. > >> >>> 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 It is also where using a decent OS appropriate for the task is even easier. > > 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. > I copy gcc setups between systems (albeit cross-compilation toolchains). It's easy with scp, sshfs, rsync, network shares, or a USB stick. The cheapest USB drives I can find from my usual IT supplier are 32 GB - the biggest toolchain I have is about 1.2 GB for everything. The same applies to Linux and Windows. Sure, the process would be faster if the toolchain directories were smaller, but I only need to do it once or twice a year for new versions. The only time things are difficult is when some idiot device manufacturer thinks their Windows version should use an installer program that screws with the registry, environment variables or system paths.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 13:15 +0100 |
| Message-ID | <118glk6$9n8h$1@dont-email.me> |
| In reply to | #402160 |
On 17/09/2026 11:52, David Brown wrote: > On 17/09/2026 02:49, bart wrote: >>>> 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. > > touch empty.c > gcc -E -v empty.c > > That will show you, amongst other things, the default include paths. On > my system, it shows : > > #include "..." search starts here: > #include <...> search starts here: > /usr/lib/gcc/x86_64-linux-gnu/13/include > /usr/local/include > /usr/include/x86_64-linux-gnu > /usr/include > End of search list. I got a lot more output than that. Then I noticed you said 'amongst other things'. So -v does not produce less output than --verbose! On my C compiler I used to have an option -paths which listed all the include paths it would use. I'm surprised that gcc, amongst it 1000s of options, doesn't have a dedicated one for this. > >> >>> >>>> 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 > > It is also where using a decent OS appropriate for the task is even easier. Seem my remark about managing complexity below. >> >> 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. >> > > I copy gcc setups between systems (albeit cross-compilation toolchains). > It's easy with scp, sshfs, rsync, network shares, or a USB stick. The > cheapest USB drives I can find from my usual IT supplier are 32 GB - the > biggest toolchain I have is about 1.2 GB for everything. The same > applies to Linux and Windows. Amazingly, my own tools would still fit on one 1.44MB floppy - uncompressed. I think the approach you and others use now is to manage bloat and complexity, or somehow hide it away under additional layers, rather than do anything about it. And the approach to keep things moving is to add extra hardware. If that doesn't work then avoid recompiling anything if at all possible! Mine are to actually keep things simple, and to keep on top of raw speed. The problem with not doing anything about complexity is that probably no one knows how it all works. So when it goes wrong...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-17 15:16 +0200 |
| Message-ID | <118gp86$aa36$2@dont-email.me> |
| In reply to | #402167 |
On 17/09/2026 14:15, bart wrote:
> On 17/09/2026 11:52, David Brown wrote:
>> On 17/09/2026 02:49, bart wrote:
>>>>> 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.
>>
>> touch empty.c
>> gcc -E -v empty.c
>>
>> That will show you, amongst other things, the default include paths.
>> On my system, it shows :
>>
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/lib/gcc/x86_64-linux-gnu/13/include
>> /usr/local/include
>> /usr/include/x86_64-linux-gnu
>> /usr/include
>> End of search list.
>
> I got a lot more output than that. Then I noticed you said 'amongst
> other things'. So -v does not produce less output than --verbose!
>
Yes. You might think it strange, but I only posted the relevant lines
here. There were a total of 31 lines from that command - it was not
difficult to spot the ones relevant to the include paths.
> On my C compiler I used to have an option -paths which listed all the
> include paths it would use.
>
> I'm surprised that gcc, amongst it 1000s of options, doesn't have a
> dedicated one for this.
>
I've never needed to see the list of paths before - they are all
entirely obvious and standard, and "just work". Why would a compiler
need to add a specific option for something that is rarely required and
where there is a simple and fairly obvious common option ("-v", or
"--verbose") to get the information?
> I think the approach you and others use now is to manage bloat and
> complexity, or somehow hide it away under additional layers, rather than
> do anything about it.
>
My approach is to care about things that are worth caring about, and not
bother about things that are not worth bothering about.
I need tools that do the job I need them to do.
I don't need "as small as possible" - I need "small enough that their
size is not an inconvenience". I don't need "as fast as possible" - I
need "fast enough that their speed is not an inconvenience". Small
enough is small enough. Fast enough is fast enough. After that,
smaller or faster is irrelevant and not part of the consideration for
picking a tool.
On the other hand, slightly better code optimisation can mean longer
battery life, smaller and cheaper hardware, or more functionality in my
program. A bit more static error checking can mean bugs caught during
development and building, rather than during testing or after
deployment. Better standards conformance can mean more portable code
and easier testing, support for newer standards and useful extensions
means more expressive, re-usable or maintainable source code, better
optimisation, and more static error checking.
I do software development. I don't spend my days copying compilers to
floppy disks or trying to run tools on systems from last century. I am
not interested in how quickly a compiler can compile an almost-empty
test file, 50 times sequentially. I don't care if "bcc test.c" runs
faster than "gcc test.c" when "bcc test.c" is no more use to me than
"cat test.c > /dev/null".
By all means, play with your "benchmarks" if you enjoy doing so. But
stop expecting anyone else to care.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 15:25 +0100 |
| Message-ID | <118gt99$cmmv$1@dont-email.me> |
| In reply to | #402172 |
On 17/09/2026 14:16, David Brown wrote:
> On 17/09/2026 14:15, bart wrote:
>> On 17/09/2026 11:52, David Brown wrote:
>>> On 17/09/2026 02:49, bart wrote:
>>>>>> 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.
>>>
>>> touch empty.c
>>> gcc -E -v empty.c
>>>
>>> That will show you, amongst other things, the default include paths.
>>> On my system, it shows :
>>>
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>> /usr/lib/gcc/x86_64-linux-gnu/13/include
>>> /usr/local/include
>>> /usr/include/x86_64-linux-gnu
>>> /usr/include
>>> End of search list.
>>
>> I got a lot more output than that. Then I noticed you said 'amongst
>> other things'. So -v does not produce less output than --verbose!
>>
>
> Yes. You might think it strange, but I only posted the relevant lines
> here. There were a total of 31 lines from that command - it was not
> difficult to spot the ones relevant to the include paths.
Always making excuses for gcc! I get 37 lines from it, but because many
are long and wrap, my screen shows over 85 lines, with 25 of them
scrolling off the top of the window. It looks a mess.
>> On my C compiler I used to have an option -paths which listed all the
>> include paths it would use.
>>
>> I'm surprised that gcc, amongst it 1000s of options, doesn't have a
>> dedicated one for this.
>>
>
> I've never needed to see the list of paths before - they are all
> entirely obvious and standard, and "just work".
Yeah, everything 'just works' for you. But if ever it reports it can't
find some header, you will want to know:
(1) The list of locations that it will be looking
(2) All the locations it's checked (this is not necessarily the
same list; see my last post)
> Why would a compiler
> need to add a specific option for something that is rarely required and
> where there is a simple and fairly obvious common option ("-v", or "--
> verbose") to get the information?
That option is next to useless because it buries what you need in a
mountain of junk.
> On the other hand, slightly better code optimisation can mean longer
> battery life, smaller and cheaper hardware, or more functionality in my
> program.
Maybe you do get it after all. Using smaller, simpler, faster tools
gives all those advantages too.
It's a shame you don't see language tools in the same light as some of
your applications.
> A bit more static error checking can mean bugs caught during
> development and building, rather than during testing or after
> deployment.
A better language can also do that!
> Better standards conformance can mean more portable code
> and easier testing, support for newer standards and useful extensions
> means more expressive, re-usable or maintainable source code, better
> optimisation, and more static error checking.
> I do software development.
So do I, but I develop experimental language tools. You want to get your
applications (it will be more embedded systems stuff I expect) as small
and efficient as possible.
I do too.
> I don't spend my days copying compilers to
> floppy disks or trying to run tools on systems from last century. I am
> not interested in how quickly a compiler can compile an almost-empty
> test file, 50 times sequentially.
Come on, I sure you know what is involved in benchmarking. You often
have to isolate some part if looking for a the bottleneck.
But in this case the point of the test was to measure the impact of a
large header used across a sizeable number of modules.
This is the RAW impact. All that YOU can do, and are interested in, is
in mitigating that (more cores, avoid recompiling etc).
But I am interested in reducing that raw overhead.
> I don't care if "bcc test.c" runs
> faster than "gcc test.c" when "bcc test.c" is no more use to me than
> "cat test.c > /dev/null".
This is the funny thing I've discovered when discussing compilers elsewhere:
* When a compiler builds an app then the speed of that app is the most
important thing in the world, no matter what the app is ...
* ... unless the app is a compiler. Then its speed is the least
important thing in the world!
So, you care about your apps being fast; I care about /my/ apps being
fast. Even for language tools, as they open up interesting new ways of
working as well as being an interesting endeavour in itself.Now, it
could be that there is some gross inefficiency in your tools that no one
spotted, if everyone is as incurious and as tolerant as you.
One way of telling is if there was an alternative product that does the
same thing faster.
Before you tell me that your prefered tool does that much more, remember
the examples I gave of assemblers with a 10:1 disparity between fastest
and slowest. There is no deep analysis or opimisation there. Some tools
are just Slow.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-17 17:05 +0200 |
| Message-ID | <118gvk5$d1i7$1@dont-email.me> |
| In reply to | #402175 |
On 17/09/2026 16:25, bart wrote:
> On 17/09/2026 14:16, David Brown wrote:
>> On 17/09/2026 14:15, bart wrote:
>>> On 17/09/2026 11:52, David Brown wrote:
>>>> On 17/09/2026 02:49, bart wrote:
>>>>>>> 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.
>>>>
>>>> touch empty.c
>>>> gcc -E -v empty.c
>>>>
>>>> That will show you, amongst other things, the default include paths.
>>>> On my system, it shows :
>>>>
>>>> #include "..." search starts here:
>>>> #include <...> search starts here:
>>>> /usr/lib/gcc/x86_64-linux-gnu/13/include
>>>> /usr/local/include
>>>> /usr/include/x86_64-linux-gnu
>>>> /usr/include
>>>> End of search list.
>>>
>>> I got a lot more output than that. Then I noticed you said 'amongst
>>> other things'. So -v does not produce less output than --verbose!
>>>
>>
>> Yes. You might think it strange, but I only posted the relevant lines
>> here. There were a total of 31 lines from that command - it was not
>> difficult to spot the ones relevant to the include paths.
>
> Always making excuses for gcc! I get 37 lines from it, but because many
> are long and wrap, my screen shows over 85 lines, with 25 of them
> scrolling off the top of the window. It looks a mess.
If gcc had a flag to show the include paths, and nothing but the include
paths, you'd complain that you had to read through piles of
documentation to find it. It does not seem to matter what inane,
pointless task you and you alone think is vital, your life seems to
revolve around saying that gcc is bad in every way. So what's next?
gcc is a terrible tool because you find it harder to type "gcc" than "bcc" ?
Sometimes you have sane points about weaknesses in C, or things that
could be improved in gcc, clang, and other tools - or at least, they
were sane points the first time you raised them rather than the
hundredth time. But this moan is pathetic even by your standards.
Oh, and does your fantastic OS not have scrollbars to see more lines of
output? Are you stuck with terminal windows limited to 80 characters
wide, just like we all used last century? Do you not know how to use
the "less" command? (Oh, wait, "less" is only 42 years old - we could
not expect Windows to have caught up with such basic tools in that time.
But you can use "more".)
>
>>> On my C compiler I used to have an option -paths which listed all the
>>> include paths it would use.
>>>
>>> I'm surprised that gcc, amongst it 1000s of options, doesn't have a
>>> dedicated one for this.
>>>
>>
>> I've never needed to see the list of paths before - they are all
>> entirely obvious and standard, and "just work".
>
> Yeah, everything 'just works' for you. But if ever it reports it can't
> find some header, you will want to know:
>
> (1) The list of locations that it will be looking
>
> (2) All the locations it's checked (this is not necessarily the
> same list; see my last post)
>
Learn to use a computer for software development, and stop bleating when
you actually have to lift a finger! Of course I have occasionally had a
compile fail because my code references a missing header. When it
happens I either find the header, or fix the typo in my code. We are
not doing brain surgery here.
If you can't program in C, and can't use normal C compilers, that's
/your/ problem. Millions of others manage to use gcc for C programming.
Start facing the reality that it is /you/ who is doing something
wrong, not the rest of the world.
>
>> Why would a compiler need to add a specific option for something
>> that is rarely required and where there is a simple and fairly obvious
>> common option ("-v", or "-- verbose") to get the information?
>
> That option is next to useless because it buries what you need in a
> mountain of junk.
Not that you are exaggerating at all.
>
>> On the other hand, slightly better code optimisation can mean longer
>> battery life, smaller and cheaper hardware, or more functionality in
>> my program.
>
> Maybe you do get it after all. Using smaller, simpler, faster tools
> gives all those advantages too.
>
> It's a shame you don't see language tools in the same light as some of
> your applications.
>
And /why/ is it a shame? In all your endless posts, you have never
given a reason why it should matter to me.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 16:46 +0100 |
| Message-ID | <118h208$eic5$1@dont-email.me> |
| In reply to | #402177 |
On 17/09/2026 16:05, David Brown wrote:
> On 17/09/2026 16:25, bart wrote:
>> On 17/09/2026 14:16, David Brown wrote:
>>> On 17/09/2026 14:15, bart wrote:
>>>> On 17/09/2026 11:52, David Brown wrote:
>>>>> On 17/09/2026 02:49, bart wrote:
>>>>>>>> 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.
>>>>>
>>>>> touch empty.c
>>>>> gcc -E -v empty.c
>>>>>
>>>>> That will show you, amongst other things, the default include
>>>>> paths. On my system, it shows :
>>>>>
>>>>> #include "..." search starts here:
>>>>> #include <...> search starts here:
>>>>> /usr/lib/gcc/x86_64-linux-gnu/13/include
>>>>> /usr/local/include
>>>>> /usr/include/x86_64-linux-gnu
>>>>> /usr/include
>>>>> End of search list.
>>>>
>>>> I got a lot more output than that. Then I noticed you said 'amongst
>>>> other things'. So -v does not produce less output than --verbose!
>>>>
>>>
>>> Yes. You might think it strange, but I only posted the relevant
>>> lines here. There were a total of 31 lines from that command - it
>>> was not difficult to spot the ones relevant to the include paths.
>>
>> Always making excuses for gcc! I get 37 lines from it, but because
>> many are long and wrap, my screen shows over 85 lines, with 25 of them
>> scrolling off the top of the window. It looks a mess.
>
> If gcc had a flag to show the include paths, and nothing but the include
> paths, you'd complain that you had to read through piles of
> documentation to find it. It does not seem to matter what inane,
> pointless task you and you alone think is vital, your life seems to
> revolve around saying that gcc is bad in every way. So what's next? gcc
> is a terrible tool because you find it harder to type "gcc" than "bcc" ?
>
> Sometimes you have sane points about weaknesses in C, or things that
> could be improved in gcc, clang, and other tools - or at least, they
> were sane points the first time you raised them rather than the
> hundredth time.
Because I get bitten for the hundredth time.
> Oh, and does your fantastic OS not have scrollbars to see more lines of
> output?
More mitigation. Do you ever stop giving excuses for poor software?
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
> Are you stuck with terminal windows limited to 80 characters
> wide, just like we all used last century? Do you not know how to use
> the "less" command? (Oh, wait, "less" is only 42 years old - we could
> not expect Windows to have caught up with such basic tools in that time.
> But you can use "more".)
I mentioned in another post about Clang choosing to write error messages
/in the same colour/ as my console background.
It also likes to generate LOTS of messages. So scrolling here wouldn't help.
gcc has its own problems: only the name of failing program is invisible,
but for the rest, it annoying changes my background colour to black and
does not restore it.
You'd think major tools like these wouldn't be so brain-dead.
It's not hard to do these checks and to restore original settings.
>> (1) The list of locations that it will be looking
>>
>> (2) All the locations it's checked (this is not necessarily the
>> same list; see my last post)
>>
>
> Learn to use a computer for software development, and stop bleating when
> you actually have to lift a finger! Of course I have occasionally had a
> compile fail because my code references a missing header. When it
> happens I either find the header, or fix the typo in my code. We are
> not doing brain surgery here.
But if it there was a dedication option for it, you'd use it? Maybe that
info can be listed at the same time it reports the missing header.
See, creating a more friendly compiler is easy! But, no, it's better
that a million programmers have to mess around even if it's not brain
surgery.
> If you can't program in C, and can't use normal C compilers, that's /
> your/ problem. Millions of others manage to use gcc for C programming.
> Start facing the reality that it is /you/ who is doing something
> wrong, not the rest of the world.
>
>>
>>> Why would a compiler need to add a specific option for something
>>> that is rarely required and where there is a simple and fairly
>>> obvious common option ("-v", or "-- verbose") to get the information?
>>
>> That option is next to useless because it buries what you need in a
>> mountain of junk.
>
> Not that you are exaggerating at all.
If I do 'gcc -v hello.c' it produces 6724 bytes of output (remember this
is a mess of wrapped lines).
The relevant info is 367 bytes of that, so about 95% of the output was
irrelevant junk.
Hardly exaggerating.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-17 20:22 +0200 |
| Message-ID | <118hb5l$htbg$1@dont-email.me> |
| In reply to | #402179 |
On 17/09/2026 17:46, bart wrote: > On 17/09/2026 16:05, David Brown wrote: >> On 17/09/2026 16:25, bart wrote: >>> On 17/09/2026 14:16, David Brown wrote: >>>> On 17/09/2026 14:15, bart wrote: >>>>> On 17/09/2026 11:52, David Brown wrote: >>>>>> On 17/09/2026 02:49, bart wrote: >>>>>>>>> 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. >>>>>> >>>>>> touch empty.c >>>>>> gcc -E -v empty.c >>>>>> >>>>>> That will show you, amongst other things, the default include >>>>>> paths. On my system, it shows : >>>>>> >>>>>> #include "..." search starts here: >>>>>> #include <...> search starts here: >>>>>> /usr/lib/gcc/x86_64-linux-gnu/13/include >>>>>> /usr/local/include >>>>>> /usr/include/x86_64-linux-gnu >>>>>> /usr/include >>>>>> End of search list. >>>>> >>>>> I got a lot more output than that. Then I noticed you said 'amongst >>>>> other things'. So -v does not produce less output than --verbose! >>>>> >>>> >>>> Yes. You might think it strange, but I only posted the relevant >>>> lines here. There were a total of 31 lines from that command - it >>>> was not difficult to spot the ones relevant to the include paths. >>> >>> Always making excuses for gcc! I get 37 lines from it, but because >>> many are long and wrap, my screen shows over 85 lines, with 25 of >>> them scrolling off the top of the window. It looks a mess. >> >> If gcc had a flag to show the include paths, and nothing but the >> include paths, you'd complain that you had to read through piles of >> documentation to find it. It does not seem to matter what inane, >> pointless task you and you alone think is vital, your life seems to >> revolve around saying that gcc is bad in every way. So what's next? >> gcc is a terrible tool because you find it harder to type "gcc" than >> "bcc" ? >> >> Sometimes you have sane points about weaknesses in C, or things that >> could be improved in gcc, clang, and other tools - or at least, they >> were sane points the first time you raised them rather than the >> hundredth time. > > Because I get bitten for the hundredth time. > >> Oh, and does your fantastic OS not have scrollbars to see more lines >> of output? > > > More mitigation. Do you ever stop giving excuses for poor software? > > Somebody needs some a few lines of info from a program, but the tool > buries it in 1000 lines of output, and your suggestion is to just to > scroll up and down trying to find it? > > Anything but fix the problem! What ****ing problem? You are talking about something that virtually no C programmer ever bothers doing, and anyone who needs to ask their compiler about the include paths only ever needs to do so /once/. There were 31 lines - not a 1000 - and the relevant lines are blindingly obvious in the output. If it took you more than a second or two to spot them, you should get a better screen or a better pair of glasses. Get over your paranoia and your egoism - compiler vendors (and compiler users) are not all dedicated to causing you trouble, and they don't all have to revolve around trying to support whatever daft uses and misuses you want to make of their tools. > >> Are you stuck with terminal windows limited to 80 characters wide, >> just like we all used last century? Do you not know how to use the >> "less" command? (Oh, wait, "less" is only 42 years old - we could not >> expect Windows to have caught up with such basic tools in that time. >> But you can use "more".) > > I mentioned in another post about Clang choosing to write error > messages /in the same colour/ as my console background. If only there were a simple way to change these for people who don't like the defaults (which were probably picked to fit the extremely common choice of black background in terminal windows). If only there were a simple way to change the background colour of your console. If only there were a simple website that could help you find out how to change these colours by typing in a question, and copying out the answers it gives you. But no, you don't want answers, or help - you want to cry about how tools that are fine for countless other developers are not fine-tuned exactly to your personal preferences. And yes, I am being patronising - stop acting like a spoiled child, and I will stop being patronising.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 20:19 +0100 |
| Message-ID | <118hefb$jkc3$1@dont-email.me> |
| In reply to | #402181 |
On 17/09/2026 19:22, David Brown wrote: > On 17/09/2026 17:46, bart wrote: >> On 17/09/2026 16:05, David Brown wrote: >>> On 17/09/2026 16:25, bart wrote: >>>> On 17/09/2026 14:16, David Brown wrote: >>>>> On 17/09/2026 14:15, bart wrote: >>>>>> On 17/09/2026 11:52, David Brown wrote: >>>>>>> On 17/09/2026 02:49, bart wrote: >>>>>>>>>> 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. >>>>>>> >>>>>>> touch empty.c >>>>>>> gcc -E -v empty.c >>>>>>> >>>>>>> That will show you, amongst other things, the default include >>>>>>> paths. On my system, it shows : >>>>>>> >>>>>>> #include "..." search starts here: >>>>>>> #include <...> search starts here: >>>>>>> /usr/lib/gcc/x86_64-linux-gnu/13/include >>>>>>> /usr/local/include >>>>>>> /usr/include/x86_64-linux-gnu >>>>>>> /usr/include >>>>>>> End of search list. >>>>>> >>>>>> I got a lot more output than that. Then I noticed you said >>>>>> 'amongst other things'. So -v does not produce less output than -- >>>>>> verbose! >>>>>> >>>>> >>>>> Yes. You might think it strange, but I only posted the relevant >>>>> lines here. There were a total of 31 lines from that command - it >>>>> was not difficult to spot the ones relevant to the include paths. >>>> >>>> Always making excuses for gcc! I get 37 lines from it, but because >>>> many are long and wrap, my screen shows over 85 lines, with 25 of >>>> them scrolling off the top of the window. It looks a mess. >>> >>> If gcc had a flag to show the include paths, and nothing but the >>> include paths, you'd complain that you had to read through piles of >>> documentation to find it. It does not seem to matter what inane, >>> pointless task you and you alone think is vital, your life seems to >>> revolve around saying that gcc is bad in every way. So what's next? >>> gcc is a terrible tool because you find it harder to type "gcc" than >>> "bcc" ? >>> >>> Sometimes you have sane points about weaknesses in C, or things that >>> could be improved in gcc, clang, and other tools - or at least, they >>> were sane points the first time you raised them rather than the >>> hundredth time. >> >> Because I get bitten for the hundredth time. >> >>> Oh, and does your fantastic OS not have scrollbars to see more lines >>> of output? >> >> >> More mitigation. Do you ever stop giving excuses for poor software? >> >> Somebody needs some a few lines of info from a program, but the tool >> buries it in 1000 lines of output, and your suggestion is to just to >> scroll up and down trying to find it? >> >> Anything but fix the problem! > > What ****ing problem? You are talking about something that virtually no > C programmer ever bothers doing, and anyone who needs to ask their > compiler about the include paths only ever needs to do so /once/. There > were 31 lines - not a 1000 There were 85 lines that scrolled up the screen. But if it was 1000, then so what: your suggestion to use the scrollbar would still work, yes? > - and the relevant lines are blindingly > obvious in the output. If it took you more than a second or two to spot > them, you should get a better screen or a better pair of glasses. That info is also presented appallingly. What's wrong with blank lines to separate the different sections? And what's with the super-long lines that are guaranteed to wrap? The two longest lines are 1700-1800 characters. It's a joke, seriously. My own diagnostics are better, but they would not be good enough for a professional product. >> >>> Are you stuck with terminal windows limited to 80 characters wide, >>> just like we all used last century? Do you not know how to use the >>> "less" command? (Oh, wait, "less" is only 42 years old - we could not >>> expect Windows to have caught up with such basic tools in that time. >>> But you can use "more".) >> I mentioned in another post about Clang choosing to write error >> messages /in the same colour/ as my console background. > > If only there were a simple way to change these for people who don't > like the defaults (which were probably picked to fit the extremely > common choice of black background in terminal windows). If only there > were a simple way to change the background colour of your console. If > only there were a simple website that could help you find out how to > change these colours by typing in a question, and copying out the > answers it gives you. But no, you don't want answers, or help - you > want to cry about how tools that are fine for countless other developers > are not fine-tuned exactly to your personal preferences. > > And yes, I am being patronising - stop acting like a spoiled child, and > I will stop being patronising. > And you continue making excuses for poor software. Are you seriously suggesting that, each time I run some console program, I should change my screen background colour in order to be able to see its messages? Each program make might choose a different colour! Or even that I have to investigate every such program to change its default colours? They should Just Work. It's a bug; not a serious one, it's more amusing/incredulous, but still a bug. > If only there were a simple way to change the background colour If only there was a way of avoiding text that would inadvertently clashes with the screen background. > want to cry about how tools that are fine for countless other developers By luck apparently; presumably they manage to avoid colour 0xC0C0C0 or something near for their background. People here are always on about making assumptions, so why assume a black background /in a system where the background colour can be chosen by the user/? The choice of light grey isn't that great for a white background either.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-09-17 21:55 +0200 |
| Message-ID | <118hgim$12av$4@news.gegeweb.eu> |
| In reply to | #402183 |
On 9/17/26 21:19, bart wrote:
> And what's with the super-long lines that are guaranteed to wrap? The
> two longest lines are 1700-1800 characters.
$ some_command_who_make_long_lines | fmt
problem solved.
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-17 23:47 +0000 |
| Message-ID | <q__qS.41249$oan4.3128@fx22.iad> |
| In reply to | #402183 |
bart <bc@freeuk.com> writes: >On 17/09/2026 19:22, David Brown wrote: >> On 17/09/2026 17:46, bart wrote: >>> On 17/09/2026 16:05, David Brown wrote: >>>> On 17/09/2026 16:25, bart wrote: >>>>> On 17/09/2026 14:16, David Brown wrote: >>>>>> On 17/09/2026 14:15, bart wrote: >>>>>>> On 17/09/2026 11:52, David Brown wrote: >>>>>>>> On 17/09/2026 02:49, bart wrote: >>>>>>>>>>> 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. >>>>>>>> >>>>>>>> touch empty.c >>>>>>>> gcc -E -v empty.c >>>>>>>> >>>>>>>> That will show you, amongst other things, the default include >>>>>>>> paths. On my system, it shows : >>>>>>>> >>>>>>>> #include "..." search starts here: >>>>>>>> #include <...> search starts here: >>>>>>>> /usr/lib/gcc/x86_64-linux-gnu/13/include >>>>>>>> /usr/local/include >>>>>>>> /usr/include/x86_64-linux-gnu >>>>>>>> /usr/include >>>>>>>> End of search list. >>>>>>> >>>>>>> I got a lot more output than that. Then I noticed you said >>>>>>> 'amongst other things'. So -v does not produce less output than -- >>>>>>> verbose! >>>>>>> >>>>>> >>>>>> Yes. You might think it strange, but I only posted the relevant >>>>>> lines here. There were a total of 31 lines from that command - it >>>>>> was not difficult to spot the ones relevant to the include paths. >>>>> >>>>> Always making excuses for gcc! I get 37 lines from it, but because >>>>> many are long and wrap, my screen shows over 85 lines, with 25 of >>>>> them scrolling off the top of the window. It looks a mess. >>>> >>>> If gcc had a flag to show the include paths, and nothing but the >>>> include paths, you'd complain that you had to read through piles of >>>> documentation to find it. It does not seem to matter what inane, >>>> pointless task you and you alone think is vital, your life seems to >>>> revolve around saying that gcc is bad in every way. So what's next? >>>> gcc is a terrible tool because you find it harder to type "gcc" than >>>> "bcc" ? >>>> >>>> Sometimes you have sane points about weaknesses in C, or things that >>>> could be improved in gcc, clang, and other tools - or at least, they >>>> were sane points the first time you raised them rather than the >>>> hundredth time. >>> >>> Because I get bitten for the hundredth time. >>> >>>> Oh, and does your fantastic OS not have scrollbars to see more lines >>>> of output? >>> >>> >>> More mitigation. Do you ever stop giving excuses for poor software? >>> >>> Somebody needs some a few lines of info from a program, but the tool >>> buries it in 1000 lines of output, and your suggestion is to just to >>> scroll up and down trying to find it? >>> >>> Anything but fix the problem! >> >> What ****ing problem? You are talking about something that virtually no >> C programmer ever bothers doing, and anyone who needs to ask their >> compiler about the include paths only ever needs to do so /once/. There >> were 31 lines - not a 1000 > >There were 85 lines that scrolled up the screen. > >But if it was 1000, then so what: your suggestion to use the scrollbar >would still work, yes? $ gcc -v -I. -I/root -E /tmp/e.c 2>&1 | grep "^ " /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1 -E -quiet -v -I . -I /root /tmp/e.c -mtune=generic -march=x86-64 . /root /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include /usr/local/include /usr/include
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-09-17 21:31 +0200 |
| Message-ID | <118hf72$12av$1@news.gegeweb.eu> |
| In reply to | #402179 |
On 9/17/26 17:46, bart wrote:
>
> Somebody needs some a few lines of info from a program, but the tool
> buries it in 1000 lines of output, and your suggestion is to just to
> scroll up and down trying to find it?
>
> Anything but fix the problem!
May be you can code a patch who fix the^Wyour problem, and
send it to the Gcc team ? Any positive contribution is
benefit to all of us.
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-17 20:54 +0100 |
| Message-ID | <118hghr$kdkh$1@dont-email.me> |
| In reply to | #402184 |
On 17/09/2026 20:31, tTh wrote: > On 9/17/26 17:46, bart wrote: >> >> Somebody needs some a few lines of info from a program, but the tool >> buries it in 1000 lines of output, and your suggestion is to just to >> scroll up and down trying to find it? >> >> Anything but fix the problem! > > May be you can code a patch who fix the^Wyour problem, and > send it to the Gcc team ? Any positive contribution is > benefit to all of us. I'm not interested in gcc. I have my own solutions. This is just one more annoying thing about that program. The issue here is that nobody is daring to criticise its crass behaviours, while trying to deflect issues onto users. Its crassness starts here: c:\c>gcc gcc: fatal error: no input files compilation terminated. Most command-line compilers give you version and help info when no parameters follow. But at least it says something; try this: c:\c\as and it apparently hangs (it's waiting for you type an assembly program from the console!) How did programs which work like some student's crude first console app ever make it into the wild?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-17 15:44 -0700 |
| Message-ID | <118hqh0$mqr3$4@kst.eternal-september.org> |
| In reply to | #402186 |
bart <bc@freeuk.com> writes:
[...]
> I'm not interested in gcc.
Yes, you are.
There are plenty of things I'm not interested in. I express my
lack of interest by not talking about them. You talk about gcc a
lot more than I do.
Can you explain to us what you actually mean when you say you're
"not interested in gcc"? And when you decide what you mean, can
you start saying that rather than saying you're "not interested"?
[...]
--
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]
Page 14 of 25 — ← Prev page 1 … 12 13 [14] 15 16 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web