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 18 of 25 — ← Prev page 1 … 16 17 [18] 19 20 … 25 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-18 22:57 +0100 |
| Message-ID | <118kc47$1mrsv$1@dont-email.me> |
| In reply to | #402249 |
On 18/09/2026 20:26, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> But if either seriously expect source code to be entered 'live', then >> they should show a prompt; how hard would that be? > > There is no serious expectation that "as" will be read its input > from a keyboard. Not intentionally perhaps. But it will happen every time a newcomer to it, or someone who has mercifully forgotten the last time they used it, runs 'as' with no inputs. > You are complaining about things you clearly do > not understand and do not want to understand. WTH is there to understand about it? 'as' (even the choice of name is terrible as it needs quotes to distinguish it from the word) just works poorly. Maybe that was by design at the time, but apparently such things are impossible to fix so it has to work that way for eternity. (Of course, creating 'as2' would be out of the question.) Is 'as' even intended to be used in an interactive console session? I don't mean typing in code to stdin, but invoking it as a program via live typing. It sounds like many here do not do that; it is only invoked from scripts or via other tools. If that is the case, then they are in no position to criticise my comments about it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-19 17:27 +0200 |
| Message-ID | <118m9kt$2cgfb$1@dont-email.me> |
| In reply to | #402247 |
On 18/09/2026 21:07, bart wrote:
> On 18/09/2026 16:24, David Brown wrote:
>> On 18/09/2026 15:03, bart wrote:
>
> So "gcc" and "as" are wildly different tools that are used in wildly
>> different ways, written by completely separate groups of people. The
>> fact that they have different defaults is hardly surprising - a
>> compiler will rarely be used with piped input from outside, whereas
>> for "as", that is by far the most common mode of operation.
>
> Actually, gcc on Windows seems to generate temporary .s files that are
> submitted to 'as'. Piping isn't used.
Piping is an option that is used on some systems, and not on others, and
it can be enabled with "gcc -pipe". Whether you are using a pipe or a
temporary file, the prime use of "as" is not as a program run by a user,
but as a program run by "gcc".
>
> Both gcc and 'as' take inputs which are one or more files (sequences of
> bytes) and write outputs that are one or more files.
>
> You probably can't get any simpler than that in a computer program.
>
So now gcc is a simple program?
> Neither of them are really intended for interactive use either: that is,
> interaction while they run, beyond invoking them.
True.
>
> But if either seriously expect source code to be entered 'live', then
> they should show a prompt; how hard would that be?
That's a meaningless question, as the pre-condition is clearly false.
I accept that it is fine for a program to print a quick help message
when run with incomplete or incorrect arguments. But it is also fine
for it to give an error message. And for some programs, it can be
appropriate to show nothing when given no arguments, or to wait for
input from stdin. All options are reasonable for some kinds of
programs. In some programs you wrote, you picked one method, in some
programs other people have written, they picked a different solution.
Your personal opinions do not form the requirements for all the world's
software.
>>> - Given two files, gcc compiles them independently; as assembles them
>>> after effectively combining them (imagine if gcc concatenated all the
>>> .c files you give it; it would be ludicrous).
>>
>> They are different kinds of programs, doing different things.
>> Assembly files can reasonably be concatenated, C files cannot.
>
> That is nonsense. ASM can contain local, non-exported symbols just like
> HLLs. For example two people might be writing two ASM files and they
> shouldn't need to ensure that their choices of labels do not clash.
>
Sometimes assembly files can be concatenated - it depends on how they
are written. People often use local symbols and labels (numerical
labels, or .L labels). But at other times, you are entirely correct
that there may be clashes if you concatenate two random assembly files.
So let me be more nuanced - /sometimes/ it is reasonable to concatenate
assembly files, and assembly files may be written with that in mind. It
is almost never reasonable to concatenate C source files.
For an assembler designed with direct use as a primary aim, you could
reasonably pick a different handling of multiple source files - maybe
they would be assembled independently to generate multiple object files,
or maybe they would be rejected as invalid use of the assembler (with a
nice, friendly help message if you don't like error messages). For an
assembler designed primarily to be called from a compiler driver
program, it doesn't much matter as the compiler takes the responsibility
of getting the command line arguments right, or of making sure that if
it sends multiple source files, they can and should be concatenated.
>
>> "gcc" is a driver program, not a C compiler - it also deals with lots
>> of different file types.
>
> So what's the name of the actual C compiler then, cc1.exe? That doesn't
> appear usable by itself:
No, it is probably not of much use by itself - it is intended solely to
be run from gcc (or g++, or other gcc frontend driver programs).
>
> So what's the name of the assembler proper? It seems everything comes
> under the 'gcc' umbrella, out of necessity rather than convenience,
> since the different components - cc1, as, ld - are pretty much unusable
> by themselves.
"as" is the name of the assembler "proper". It is not part of gcc, and
nor is "ld". ("ld" and "as" are both part of the "binutils" project.)
And no one else has suggested that "as" is not usable by itself - merely
that this is not the /primary/ use-case. This is different for "cc1",
which is absolutely intended only as an internal program called from
"gcc", and there is not likely to be any reason to run it directly.
Note that failing to print a help message when you run "as" without
parameters does not make it "pretty much unusable".
Also note that in the *nix world, the behaviour of gcc, cc1, as, ld and
other related programs here are quite normal. They follow conventions
used by other toolchains found in the *nix world, and people can and do
mix and match to a certain extent. I think that's less common now that
the *nix world has pretty much settled on Linux and BSD, with the
commercial unix systems and their dedicated toolchains no longer as popular.
>
>> to work. But we have already established that your opinions on such
>> matters do not often match those of many others.
>
> OK. For some irrational reason, you are defending some behaviours
> determined decades ago, which were clearly wrong, ludicrous, unsafe, or
> inconsistent.
>
Many people here have put quite a bit of time and effort into explaining
things to you - why things are the way they are, what advantages they
have, what disadvantages they have. We also explain how to use the
tools the way they are, and why your various complaints are generally
not actually problems in practice.
None of us here wrote any of the tools under discussion. Thus we are
not "defending" anything. We are /explaining/. We might also offer
opinions about whether we like something or not, or find it useful -
those are subjective opinions.
> You know, it would cost you nothing to say, Bart, you're right. But for
> historical and other reasons we're stuck with them and need to make the
> best of a bad job.
When I agree with you, I am happy to say so. You would know that if you
ever read what others wrote.
>
>>> I mean, is it unreasonable to expect '-shared' on Windows to result
>>> in a file ending with .dll rather than .exe?
>>>
>>
>> As I understand it, the format for dll and exe files is the same on
>> Windows (as is the format for various other files), and both can
>> contain directly executable code and resources that can be used by
>> other programs.
>
> They have the same format, but files used as DLLs have extra stuff:
>
> * Base relocation tables
> * Must have relocatable code
> * I think there is an extra segment
> * An export table
> * Different flags are set in the header
>
> The .dll extension is normally used for these. Experiments trying to
> load a DLL via LoadLibrary (ie. dlopen on Linux) suggest that an
> extension other than .dll would be troublesome.
>
> LoadLibrary Arg lib.dll lib.exe (actual name of DLL)
>
> "lib" Yes No
> "lib.dll" Yes No
> "lib.exe" No Yes
>
> So it makes sense to use "lib" or "lib.dll" as the argument, and for
> DLLs to use ".dll".
>
> In any case, using .exe for DLLs would be confusing.
Having different file extensions can be very helpful, particularly on
Windows where they are integral to the system. (I find it infuriating
that the Windows gui hides file extensions by default - it's the first
thing I turn off when I have to use a Windows machine.)
There are reasonable uses of files as both executables and libraries.
Very often in my Python coding, I will have a Python file that is
intended for use as a "library" (i.e., to be imported from other
modules, scripts or Python shells) but which can also be run directly
for test purposes or as simple command-line programs. For large enough
programs, it is normal to separate the dll's from the exe's, but
combining them in one file would surely suit your preference for minimum
number of files.
>
>> Still, it is unreasonable to expect people to specify the name they
>> want for a program or shared library?
>
> I was mildly surprised that gcc on Windows allows "-o prog" and gcc will
> generate the file "prog.exe" without needing the extension.
>
This may be a configurable option for building gcc. It may also be a
feature of "ld", or whatever linker is used in your Winlibs installation.
> This could reasonably lead people to think that with "-shared", it would
> write a .dll file. They would be wrong.
So they have to learn how to use their tools. In the days before
google, that might have been inconvenient. First, of course, they
should learn that they are not using "gcc on Windows" - they are using
the "Winlibs" toolchain, or whatever.
>
>> It is normal for a program (or shared library) to consist of
>> multiple files - I think it would be highly unusual to want to turn a
>> single "x.c" file into a dll "x.dll".
>
> C compilers that don't follow gcc (clang follows gcc, and tcc follows it
> on Linux only), tend to take the name of the first submitted C file as
> the default name of the output, when there is one output.
>
That seems reasonable for compilation - compiling "file.c" to "file.o".
gcc does that - "gcc -c file.c" produces "file.o". (It does not bother
me one way or the other - in real use, I always give gcc a specific
output file because I don't mix my generated object files and my source
code in the same directories.)
Generating an exe file, or a shared library, is very likely to involve
more than one file. Naming the output after one file is therefore not
helpful. Naming it "a.out" is not particularly helpful either, but
that's the tradition.
> (-c -S options generate multiple files.)
>
>> I am sure that it makes sense that "gcc -shared x.c" could generate
>> "x.dll" on Windows. I am far from sure that failing to use "x.dll" as
>> the default name is a bother to anyone else. Other than a quick test
>> of how gcc works, it's hard to imagine a use-case.
>
> It's just wrong. A million people will use gcc and some of those will
> encounter some issue like this which at best wastes their time.
>
None of this has even crossed my mind until you brought it up. I'm sure
you are right that it will waste some time for some people, and I don't
disagree that sometimes the default behaviour could have been better -
but I simply cannot see it as being a matter worth fussing about.
(In posts where you have pointed out that gcc, without additional
arguments, accepts code that your compiler has treated as an error, I
have often agreed - or at least said a warning would be better than
silent acceptance.)
>> And of course, remember that gcc (and as) are native to an OS where
>> the type of a file is determined by the file, not by part of its name.
>
> Fine. In that case don't bother with the extension if the extension is a
> lie.
>
> But for DLLs, the extensions is important to make it visible, and there
> will of course be further checks that are done.
>
I don't disagree that it makes sense for a program generating a dll on
Windows to give the result a .dll extension by default (though that
extension is not necessarily correct - .oxc, .cpl, .drv, .fon, .icl are
apparently all dll files). I just disagree that it matters very much,
or that it is going to cause anyone confusion, mistakes, or wasted time.
It would, at most, only be relevant to people writing the command line
by hand for each build - and they are already wasting their own time by
not using at least some kind of build automation or script (or at least
a simple bat file!).
>
>>> I mean, you do 'gcc prog1.c', wait some time for it to produce
>>> 'a.exe'. Now you do 'gcc prog2.c', and it promptly overwrites the
>>> 'a.exe' from the last compile! That is quite laughable.
>>>
>
>> So don't do that.
>
> Something else which is just plain wrong, and can waste a lot of time.
> When you have to do twice the work of specifying an input, or you may
> have to repeat a lengthy compile if you need to run an earlier, now
> overwritten, a.exe again.
>
Again, when you see this as an issue, it is because you are doing things
wrong.
Remember, you are not doing software development here, or doing any
programming. You are not writing code and producing executables or
libraries. People who do that use the best tools they can get to make
their job easier and give better results - they use proper editors or
ides, and proper build tools. No sane developer wants to type in a
compile command line for every compilation, with all the flags and
options that suit their own particular needs (which vary enormously from
developer to developer) - they have it typed in already in a makefile or
a batch file, or generated with cmake, or whatever floats their boat.
One little extra argument to give the required output filename is an
irrelevant detail.
Now, I realise that the way I use my tools and the setups I have is not
necessarily typical of anyone else. But a quick check of the command
line used for each individual compile in my current project shows 111
arguments ( over about 2300 characters. That includes all the include
directory flags (blame idiot microcontroller manufacturer SDKs for their
necessity, not me or gcc), a couple of dozen specifically chosen
optimisation flags, a dozen flags for details of the exact target
processor features, lots and lots of warning flags, and one argument
specifying the output file name and directory. For the linking call to
gcc - the one you are most upset about - there are about 760 arguments
over 60,000 characters due to the 729 object file names and their
directories. (These are all automatically generated by my makefiles.)
That's a /real/ project for a /real/ program. Do you honestly think
that having a better (IYHO) default choice of output filename would make
a difference?
All you are doing is faffing around with meaningless tests on the
command-line. It bears no relationship to actual software development.
>> If you don't like the way gcc (or any other tools) work, and you feel
>> that your own tools are better for your uses, then use your own tools.
>
> That's exactly what I do. But gcc came up in this thread.
>> Or if you feel that you /have/ to use gcc, and that you can't cope
>> with writing all these nasty, awkward switches and arguments, and
>> think that build tools are just crutches for those that don't want to
>> spend all day doing manual project management, then write a batch file:
>>
>> gcc-dll.bat :
>> @echo off
>> gcc -shared -s %1.c -o %1.dll
>>
>>
>> gcc-exe.bat :
>> @echo off
>> gcc %1.c -o %1.exe
>>
>>
>> There.
>
> I do that too. It is a small C program called gc used like this:
>
> gc prog
> gc prog opt
>
> It generates prog.exe and also adds the long-winded options needed for
> my generated C code.
So if even /you/ - renowned failure at build automation and sceptic to
anything that might make your life easier - don't actually have any
problems from gcc's choices of default, then why are you fussing about
it? Do you imagine there are C programmers out there who are less
competent than you at making batch files or using other appropriate tools?
>
> But it's not flexible enough for ad hoc needs. Then I have to use gcc
> and it's a nuisance because of its quirks.
>
>> After decades of gnashing your teeth and pulling out your hair, I've
>> given you the solution. I can't imagine you will use it, but there it
>> is.
>
> It's a workaround. gcc is what, 85,000 source files, but I still have to
> write scripts to make it usable?!
>
My car is built from 85,000 pieces - it still needs a driver to make it
usable.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-19 20:09 +0100 |
| Message-ID | <118mmlm$2hem9$1@dont-email.me> |
| In reply to | #402282 |
On 19/09/2026 16:27, David Brown wrote:
> On 18/09/2026 21:07, bart wrote:
>> On 18/09/2026 16:24, David Brown wrote:
>>> On 18/09/2026 15:03, bart wrote:
>>
>> So "gcc" and "as" are wildly different tools that are used in wildly
>>> different ways, written by completely separate groups of people. The
>>> fact that they have different defaults is hardly surprising - a
>>> compiler will rarely be used with piped input from outside, whereas
>>> for "as", that is by far the most common mode of operation.
>>
>> Actually, gcc on Windows seems to generate temporary .s files that are
>> submitted to 'as'. Piping isn't used.
>
> Piping is an option that is used on some systems, and not on others, and
> it can be enabled with "gcc -pipe". Whether you are using a pipe or a
> temporary file, the prime use of "as" is not as a program run by a user,
> but as a program run by "gcc".
>
>>
>> Both gcc and 'as' take inputs which are one or more files (sequences
>> of bytes) and write outputs that are one or more files.
>>
>> You probably can't get any simpler than that in a computer program.
>>
>
> So now gcc is a simple program?
It's simple in that its job is to convert file A to file B for example.
>> But if either seriously expect source code to be entered 'live', then
>> they should show a prompt; how hard would that be?
>
> That's a meaningless question, as the pre-condition is clearly false.
Steven GK's opening post contained just such an example. I guess as an
example of how 'useful' the feature is.
> I accept that it is fine for a program to print a quick help message
> when run with incomplete or incorrect arguments. But it is also fine
> for it to give an error message. And for some programs, it can be
> appropriate to show nothing when given no arguments, or to wait for
> input from stdin. All options are reasonable for some kinds of
> programs. In some programs you wrote, you picked one method, in some
> programs other people have written, they picked a different solution.
> Your personal opinions do not form the requirements for all the world's
> software.
My experience of my developing such tools plus 50 years' experience of
using tools from non-Unix-like systems.
> So let me be more nuanced - /sometimes/ it is reasonable to concatenate
> assembly files, and assembly files may be written with that in mind. It
> is almost never reasonable to concatenate C source files.
>
> For an assembler designed with direct use as a primary aim, you could
> reasonably pick a different handling of multiple source files - maybe
> they would be assembled independently to generate multiple object files,
> or maybe they would be rejected as invalid use of the assembler (with a
> nice, friendly help message if you don't like error messages).
I have two assemblers, AA6 and AA7. Both are designed to process
machine-generated inputs, so have no fancy features. Both have a decent
UI and can be used as command line tools.
AA6 can take multiple, independent files in any order (but which
comprise the same program) and produces always one output file (EXE,
DLL, OBJ etc).
AA7 takes one input file only (used for whole-program compilers).
So, these are unusual in integrating 'linking', but the OBJ options
enables the use of an external linker, while both can be invoked
per-file generating OBJ format for more conventional use.
> For an
> assembler designed primarily to be called from a compiler driver
> program,
If such programs cannot be easily used from a console, then why even
bother? Just have them as dynamic libraries with an API. The inputs and
outputs can be strings instead of files, so you get the advantages of
piping.
> None of us here wrote any of the tools under discussion.
Well that is one big difference then because I also write CLI tools.
> There are reasonable uses of files as both executables and libraries.
> Very often in my Python coding, I will have a Python file that is
> intended for use as a "library" (i.e., to be imported from other
> modules, scripts or Python shells) but which can also be run directly
> for test purposes or as simple command-line programs.
Scripting languages are different: eg. in mine each module can have a
'main' function that is run if this is the lead module, or ignored
otherwise.
(Python will have some means to do that via __main__ etc.)
Actually I have a similar feature in my systems lang: a subprogram can
contain its own main() routine which is ignored when it is imported into
the main app.
For example, I've given my 'bignum' library a main() routine. I can
compile and run it by itself:
c:\mx>mm -r bignum
Bignum Main # it doesn't do much
But I can still use it like this within another app:
import bignum
The library is still compiled into the EXE (it's not a DLL). However, I
can't now use:
module bignum
since the compiler reports two main() functions.
> For large enough
> programs, it is normal to separate the dll's from the exe's, but
> combining them in one file would surely suit your preference for minimum
> number of files.
The largest DLL on my machine is chrome.dll at about 300MB. It exports
just 6 functions, to do with starting or restarting Chrome.
>> This could reasonably lead people to think that with "-shared", it
>> would write a .dll file. They would be wrong.
>
> So they have to learn how to use their tools.
They have to learn this dangerous QUIRK. And the people responsible for
the compiler might think about fixing that quirk.
(I have much experience of customer support and would see what things
caused problems. If I just told them to go and read the effing manual as
many here are keen on, I wouldn't have had many customers left.
Basically, someone has a task that involves in getting from A to B. They
don't care how they get there within reason, but which of these is more
desirable:
* Having 6 fiddly, error prone steps together with unfriendly
advice to RTFM if anyone complains
* Having only 3 simpler steps and a sympathetic vendor who is willing
to consider suggestions for further improvement
Difficult one isn't it? Yet everyone here seems to consider the first
option is acceptable.)
>> C compilers that don't follow gcc (clang follows gcc, and tcc follows
>> it on Linux only), tend to take the name of the first submitted C file
>> as the default name of the output, when there is one output.
>>
>
> That seems reasonable for compilation - compiling "file.c" to "file.o".
> gcc does that - "gcc -c file.c" produces "file.o".
It has to. If:
gcc -c one.c two.c three.c
were all written to the same a.out, with each overwriting the last, then
even gcc knows that would be utterly stupid as well as pointless.
> Generating an exe file, or a shared library, is very likely to involve
> more than one file. Naming the output after one file is therefore not
> helpful. Naming it "a.out" is not particularly helpful either, but
> that's the tradition.
Naming it after the first or only file is a more reasonable default than
a.out. Since this sequence:
gcc -shared one.c
gcc -shared two.c
gcc -shared three.c
when you have three libraries would be as nonsensical as the above example.
>> Something else which is just plain wrong, and can waste a lot of time.
>> When you have to do twice the work of specifying an input, or you may
>> have to repeat a lengthy compile if you need to run an earlier, now
>> overwritten, a.exe again.
>>
>
> Again, when you see this as an issue, it is because you are doing things
> wrong.
>
> Remember, you are not doing software development here, or doing any
> programming. You are not writing code and producing executables or
> libraries.
Most of my involvement with gcc and 'as' is ad hoc. This is stuff
outside of a formal project which my IDE would take care of.
> Now, I realise that the way I use my tools and the setups I have is not
> necessarily typical of anyone else. But a quick check of the command
> line used for each individual compile in my current project shows 111
> arguments ( over about 2300 characters. That includes all the include
> directory flags (blame idiot microcontroller manufacturer SDKs for their
> necessity, not me or gcc),
This is another bugbear which you dismissed the other day: the
desirability of providing compact, production header files that exist in
one place.
a couple of dozen specifically chosen
> optimisation flags, a dozen flags for details of the exact target
> processor features, lots and lots of warning flags, and one argument
> specifying the output file name and directory. For the linking call to
> gcc - the one you are most upset about - there are about 760 arguments
> over 60,000 characters due to the 729 object file names and their
> directories.
And this is where my language system has eliminated traditional linking
completely.
> (These are all automatically generated by my makefiles.)
> That's a /real/ project for a /real/ program.
It sounds like some people over the last few decades should have been
working on the same lines I have - to simplify all this stuff, rather
than manage it via extra layers and extra options.
You know, the sort of thing you describe as 'faffing around'. But
clearly you don't consider devising and refining language tools to be
software development.
> Do you honestly think
> that having a better (IYHO) default choice of output filename would make
> a difference?
Not everyone works at this level. Lot of people - beginners, hobbyists,
experimenters who are not using a fancy IDE will be using the command line.
And there these quirks can be a very big annoyance. A piece of software
made a questionable choice in its UI and it would nice if it was fixed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-20 12:31 +0200 |
| Message-ID | <118oclk$31ee7$1@dont-email.me> |
| In reply to | #402287 |
On 19/09/2026 21:09, bart wrote: > On 19/09/2026 16:27, David Brown wrote: >> On 18/09/2026 21:07, bart wrote: >>> On 18/09/2026 16:24, David Brown wrote: >>>> On 18/09/2026 15:03, bart wrote: >>> >>> So "gcc" and "as" are wildly different tools that are used in wildly >>>> different ways, written by completely separate groups of people. >>>> The fact that they have different defaults is hardly surprising - a >>>> compiler will rarely be used with piped input from outside, whereas >>>> for "as", that is by far the most common mode of operation. >>> >>> Actually, gcc on Windows seems to generate temporary .s files that >>> are submitted to 'as'. Piping isn't used. >> >> Piping is an option that is used on some systems, and not on others, >> and it can be enabled with "gcc -pipe". Whether you are using a pipe >> or a temporary file, the prime use of "as" is not as a program run by >> a user, but as a program run by "gcc". >> >>> >>> Both gcc and 'as' take inputs which are one or more files (sequences >>> of bytes) and write outputs that are one or more files. >>> >>> You probably can't get any simpler than that in a computer program. >>> >> >> So now gcc is a simple program? > > It's simple in that its job is to convert file A to file B for example. OK. > >>> But if either seriously expect source code to be entered 'live', then >>> they should show a prompt; how hard would that be? >> >> That's a meaningless question, as the pre-condition is clearly false. > > Steven GK's opening post contained just such an example. I guess as an > example of how 'useful' the feature is. Don't pretend to be so naïve. You know fine that neither Steven nor anyone else actively types assembly files like that in real life. >> I accept that it is fine for a program to print a quick help message >> when run with incomplete or incorrect arguments. But it is also fine >> for it to give an error message. And for some programs, it can be >> appropriate to show nothing when given no arguments, or to wait for >> input from stdin. All options are reasonable for some kinds of >> programs. In some programs you wrote, you picked one method, in some >> programs other people have written, they picked a different solution. >> Your personal opinions do not form the requirements for all the >> world's software. > > My experience of my developing such tools plus 50 years' experience of > using tools from non-Unix-like systems. You are still talking about your own personal opinions, and your experience is in a small (indeed, mostly single-person) part of the software world. As you reject and dismiss out of hand every tool, language, program or OS you come across that you have not written yourself, you give up any expectations you have that people will take your opinions and thoughts seriously. (You are, of course, fully entitled to your preferences and opinions.) >> For an assembler designed primarily to be called from a compiler >> driver program, > > If such programs cannot be easily used from a console, then why even > bother? Just have them as dynamic libraries with an API. The inputs and > outputs can be strings instead of files, so you get the advantages of > piping. > You have a /very/ weird idea about what is "easy" or "hard" to use. > >> None of us here wrote any of the tools under discussion. > > Well that is one big difference then because I also write CLI tools. So if someone says you have picked a bad set of arguments for your programs, you can "defend" your decisions and explain why they are the way they are. As far as I have noticed, no one has suggested that you made bad choices for /your/ tools. It does not give the slightest additional weight to any thoughts you have on /other/ tools that you barely touch. > >> There are reasonable uses of files as both executables and libraries. >> Very often in my Python coding, I will have a Python file that is >> intended for use as a "library" (i.e., to be imported from other >> modules, scripts or Python shells) but which can also be run directly >> for test purposes or as simple command-line programs. > > Scripting languages are different: eg. in mine each module can have a > 'main' function that is run if this is the lead module, or ignored > otherwise. Python is not a scripting language - it is a programming language that can also be used for scripts. But it is not a compiled language. I can't say how useful it might be in practice to have a single executable that is also a library, or even if it is actually supported in existing systems - it's not something that would affect my work (other than in the Python case). > > (Python will have some means to do that via __main__ etc.) > > Actually I have a similar feature in my systems lang: a subprogram can > contain its own main() routine which is ignored when it is imported into > the main app. > > For example, I've given my 'bignum' library a main() routine. I can > compile and run it by itself: > > c:\mx>mm -r bignum > Bignum Main # it doesn't do much > > But I can still use it like this within another app: > > import bignum > > The library is still compiled into the EXE (it's not a DLL). However, I > can't now use: > > module bignum > > since the compiler reports two main() functions. > So you have partial support for this feature. Do you find it useful? > >> For large enough programs, it is normal to separate the dll's from >> the exe's, but combining them in one file would surely suit your >> preference for minimum number of files. > > The largest DLL on my machine is chrome.dll at about 300MB. It exports > just 6 functions, to do with starting or restarting Chrome. > >>> This could reasonably lead people to think that with "-shared", it >>> would write a .dll file. They would be wrong. >> >> So they have to learn how to use their tools. > > They have to learn this dangerous QUIRK. And the people responsible for > the compiler might think about fixing that quirk. As with your ideas about what makes a program "hard" or "easy", you have a very, very strange idea about what makes a program "dangerous". We are still talking about adding "-o file.dll" as a command line argument. Someone who doesn't know they need to give the output filename, and fails to get the file they wanted after their first attempt, will immediately discover what their are missing and are unlikely to be bothered by it again. It is not "dangerous" in any remotely reasonable interpretation of the word. Nor is it "complicated", "difficult", "hard", "fiddly", "error-prone", or any other term you have used. At a long stretch, it is conceivably "unfriendly" or "quirky", but even that is an exaggeration. <snipping more repetition>
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-20 12:42 +0100 |
| Message-ID | <118ogrv$32u8a$1@dont-email.me> |
| In reply to | #402294 |
On 20/09/2026 11:31, David Brown wrote: > On 19/09/2026 21:09, bart wrote: >> On 19/09/2026 16:27, David Brown wrote: >>> On 18/09/2026 21:07, bart wrote: >>>> On 18/09/2026 16:24, David Brown wrote: >>>>> On 18/09/2026 15:03, bart wrote: >>>> >>>> So "gcc" and "as" are wildly different tools that are used in wildly >>>>> different ways, written by completely separate groups of people. >>>>> The fact that they have different defaults is hardly surprising - a >>>>> compiler will rarely be used with piped input from outside, whereas >>>>> for "as", that is by far the most common mode of operation. >>>> >>>> Actually, gcc on Windows seems to generate temporary .s files that >>>> are submitted to 'as'. Piping isn't used. >>> >>> Piping is an option that is used on some systems, and not on others, >>> and it can be enabled with "gcc -pipe". Whether you are using a pipe >>> or a temporary file, the prime use of "as" is not as a program run by >>> a user, but as a program run by "gcc". >>> >>>> >>>> Both gcc and 'as' take inputs which are one or more files (sequences >>>> of bytes) and write outputs that are one or more files. >>>> >>>> You probably can't get any simpler than that in a computer program. >>>> >>> >>> So now gcc is a simple program? >> >> It's simple in that its job is to convert file A to file B for example. > > OK. > >> >>>> But if either seriously expect source code to be entered 'live', >>>> then they should show a prompt; how hard would that be? >>> >>> That's a meaningless question, as the pre-condition is clearly false. >> >> Steven GK's opening post contained just such an example. I guess as an >> example of how 'useful' the feature is. > > Don't pretend to be so naïve. You know fine that neither Steven nor > anyone else actively types assembly files like that in real life. > >>> I accept that it is fine for a program to print a quick help message >>> when run with incomplete or incorrect arguments. But it is also fine >>> for it to give an error message. And for some programs, it can be >>> appropriate to show nothing when given no arguments, or to wait for >>> input from stdin. All options are reasonable for some kinds of >>> programs. In some programs you wrote, you picked one method, in some >>> programs other people have written, they picked a different solution. >>> Your personal opinions do not form the requirements for all the >>> world's software. >> >> My experience of my developing such tools plus 50 years' experience of >> using tools from non-Unix-like systems. > > You are still talking about your own personal opinions, and your > experience is in a small (indeed, mostly single-person) part of the > software world. As you reject and dismiss out of hand every tool, > language, program or OS you come across that you have not written > yourself, you give up any expectations you have that people will take > your opinions and thoughts seriously. (You are, of course, fully > entitled to your preferences and opinions.) > >>> For an assembler designed primarily to be called from a compiler >>> driver program, >> >> If such programs cannot be easily used from a console, then why even >> bother? Just have them as dynamic libraries with an API. The inputs >> and outputs can be strings instead of files, so you get the advantages >> of piping. >> > > You have a /very/ weird idea about what is "easy" or "hard" to use. Unix has some weird idea of its own. It likes to use shells, scripts and text for its workings. So is that text actually meant to be for humans too? Yes it is human readable if you delve into it (just about) but it is not optimised for direct human use. However here people like to pretend they are fine for direct human use too if they only read all the manuals. Yes, APIs are a more sophisticated approach. But if you're going to use textually-driven utilities, then let's have ones that are a better fit for humans. >> Scripting languages are different: eg. in mine each module can have a >> 'main' function that is run if this is the lead module, or ignored >> otherwise. > > Python is not a scripting language - it is a programming language that > can also be used for scripts. But it is not a compiled language. It is common to describe a dynamic, interpreted language as 'scripting'. Wikipedia's list of scripting languages includes Python among many others. OS shell languages are a subscript. >> Actually I have a similar feature in my systems lang: a subprogram can >> contain its own main() routine which is ignored when it is imported >> into the main app. >> >> For example, I've given my 'bignum' library a main() routine. I can >> compile and run it by itself: >> >> c:\mx>mm -r bignum >> Bignum Main # it doesn't do much >> >> But I can still use it like this within another app: >> >> import bignum >> >> The library is still compiled into the EXE (it's not a DLL). However, >> I can't now use: >> >> module bignum >> >> since the compiler reports two main() functions. >> > > So you have partial support for this feature. Do you find it useful? I use it most often in the dynamic language. Not so much in the static one; I just found it interesting that it was supported. But now that I've discovered it, I moved a demo/benchmark for above library into the library itself. I can also use it to report config settings of the library, or for testing etc as you mentioned. >> They have to learn this dangerous QUIRK. And the people responsible >> for the compiler might think about fixing that quirk. > > As with your ideas about what makes a program "hard" or "easy", you have > a very, very strange idea about what makes a program "dangerous". We > are still talking about adding "-o file.dll" as a command line argument. Yes, and it is someone using "-o file" expecting it to default to ".dll" instead of ".exe" that is the problem. As for dangerous, think of it as UB in C; anything could happen. Maybe they are replacing an existing file.dll that has a dangerous bug. They do a fix, but it silently writes file.exe leaving the bad file.dll in place. You don't see that as an issue? OK. But it is purely because you think nobody should directly use such tools anyway. > Someone who doesn't know they need to give the output filename, You say that as though HAVING to give an output file name is perfectly normal! Imagine invoking an editor on file.txt but also having to do -o file.text to stop it saving the result to a.txt! All C compilers for Windows other than gcc and clang will compile file.c into file.exe without being told. WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD? So they can be a 'drop-in' for gcc? Then nothing would ever changes. Besides, didn't you say all invocations of gcc ought to specify the output file? Then under what possible circumstance would writing 'a.exe' ever make sense!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-20 15:08 +0200 |
| Message-ID | <118olrk$34fbg$1@dont-email.me> |
| In reply to | #402295 |
On 20/09/2026 13:42, bart wrote: > On 20/09/2026 11:31, David Brown wrote: >> On 19/09/2026 21:09, bart wrote: >>> On 19/09/2026 16:27, David Brown wrote: >>>> On 18/09/2026 21:07, bart wrote: >>>>> On 18/09/2026 16:24, David Brown wrote: >>>>>> On 18/09/2026 15:03, bart wrote: >>>> For an assembler designed primarily to be called from a compiler >>>> driver program, >>> >>> If such programs cannot be easily used from a console, then why even >>> bother? Just have them as dynamic libraries with an API. The inputs >>> and outputs can be strings instead of files, so you get the >>> advantages of piping. >>> >> >> You have a /very/ weird idea about what is "easy" or "hard" to use. > > Unix has some weird idea of its own. It likes to use shells, scripts and > text for its workings. When something has been common practice across a large proportion of the computing world for half a century, it is not "weird". It is "common practice". > >>> They have to learn this dangerous QUIRK. And the people responsible >>> for the compiler might think about fixing that quirk. >> >> As with your ideas about what makes a program "hard" or "easy", you >> have a very, very strange idea about what makes a program >> "dangerous". We are still talking about adding "-o file.dll" as a >> command line argument. > > Yes, and it is someone using "-o file" expecting it to default to ".dll" > instead of ".exe" that is the problem. > > As for dangerous, think of it as UB in C; anything could happen. Maybe > they are replacing an existing file.dll that has a dangerous bug. They > do a fix, but it silently writes file.exe leaving the bad file.dll in > place. There is no "undefined behaviour" here - there is simple, obvious, consistent and easily learned behaviour which differs slightly from what you personally would prefer. That's all. > > You don't see that as an issue? OK. But it is purely because you think > nobody should directly use such tools anyway. > Yet again - stop believing you know what other people think, or inventing things you think they say. Try /reading/ posts instead, and try to understand what they actually wrote. > > >> Someone who doesn't know they need to give the output filename, > > You say that as though HAVING to give an output file name is perfectly > normal! > > Imagine invoking an editor on file.txt but also having to do -o > file.text to stop it saving the result to a.txt! > > All C compilers for Windows other than gcc and clang will compile file.c > into file.exe without being told. > > WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD? > > So they can be a 'drop-in' for gcc? Then nothing would ever changes. > > Besides, didn't you say all invocations of gcc ought to specify the > output file? > > Then under what possible circumstance would writing 'a.exe' ever make > sense! > Google for the answer. You won't listen if anyone tells you.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-20 14:22 +0100 |
| Message-ID | <118omm3$34vo7$1@dont-email.me> |
| In reply to | #402298 |
On 20/09/2026 14:08, David Brown wrote: > On 20/09/2026 13:42, bart wrote: >> You don't see that as an issue? OK. But it is purely because you think >> nobody should directly use such tools anyway. > > Yet again - stop believing you know what other people think, or > inventing things you think they say. Try /reading/ posts instead, and > try to understand what they actually wrote. I read this: DB: "You are not writing code and producing executables or libraries. People who do that use the best tools they can get to make their job easier and give better results - they use proper editors or ides, and proper build tools. No sane developer wants to type in a compile command line for every compilation, ..." >> WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD? >> Then under what possible circumstance would writing 'a.exe' ever make >> sense! > Google for the answer. You won't listen if anyone tells you. So you don't have an answer and there is no advantage. It is just pointless and annoying ancient baggage which makes the tools a pain to use directly from the command line. The sad thing is that newer tools strive to replicate that same behaviour.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-20 14:54 +0100 |
| Message-ID | <118ooj7$35l1o$1@dont-email.me> |
| In reply to | #402299 |
On 20/09/2026 14:22, bart wrote: > On 20/09/2026 14:08, David Brown wrote: >> On 20/09/2026 13:42, bart wrote: > >>> You don't see that as an issue? OK. But it is purely because you >>> think nobody should directly use such tools anyway. > >> >> Yet again - stop believing you know what other people think, or >> inventing things you think they say. Try /reading/ posts instead, and >> try to understand what they actually wrote. > > I read this: > > DB: > "You are not writing code and producing executables or libraries. People > who do that use the best tools they can get to make their job easier and > give better results - they use proper editors or ides, and proper build > tools. No sane developer wants to type in a compile command line for > every compilation, ..." One thing puzzles me: if you are correct, then why is it that newer compilers such as for Go, Rust and Zig display a gorgeous set of usage instructions when invoked by their name? Further, all of them will compile hello.go etc to hello.exe without being told. Why don't they write 'a.exe' by default and force users to have to specify the output file every time? Because that's better, right?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-20 23:24 +0200 |
| Message-ID | <118piud$3fl8p$1@dont-email.me> |
| In reply to | #402302 |
On 20/09/2026 15:54, bart wrote: > On 20/09/2026 14:22, bart wrote: >> On 20/09/2026 14:08, David Brown wrote: >>> On 20/09/2026 13:42, bart wrote: >> >>>> You don't see that as an issue? OK. But it is purely because you >>>> think nobody should directly use such tools anyway. >> >>> >>> Yet again - stop believing you know what other people think, or >>> inventing things you think they say. Try /reading/ posts instead, >>> and try to understand what they actually wrote. >> >> I read this: >> >> DB: >> "You are not writing code and producing executables or libraries. >> People who do that use the best tools they can get to make their job >> easier and give better results - they use proper editors or ides, and >> proper build tools. No sane developer wants to type in a compile >> command line for every compilation, ..." > > > One thing puzzles me: if you are correct, then why is it that newer > compilers such as for Go, Rust and Zig display a gorgeous set of usage > instructions when invoked by their name? > That is a non-sequitur. I said that people normally use build tools or other conveniences when doing serious development, and avoid repetitively typing long command lines with lots of options. That does not mean they /never/ run the compiler command directly. They might do so for quick tests, or to show version information, or perhaps to show some hints about arguments. gcc shows usage instructions if you use the obvious option, "--help". Other tools may show such information with no arguments - that's their choice. > Further, all of them will compile hello.go etc to hello.exe without > being told. > Sure. They have no history or compatibility to consider. > Why don't they write 'a.exe' by default and force users to have to > specify the output file every time? Because that's better, right? It is better if people expect it to be that way. Don't change things that are fine the way they are, and that people might be relying on (however strange that may be to you).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-21 15:06 +0000 |
| Message-ID | <2KbsS.67264$k62.61661@fx14.iad> |
| In reply to | #402309 |
David Brown <david.brown@hesbynett.no> writes: >On 20/09/2026 15:54, bart wrote: >> On 20/09/2026 14:22, bart wrote: >>> On 20/09/2026 14:08, David Brown wrote: >>>> On 20/09/2026 13:42, bart wrote: >> One thing puzzles me: if you are correct, then why is it that newer >> compilers such as for Go, Rust and Zig display a gorgeous set of usage >> instructions when invoked by their name? >> > >That is a non-sequitur. Indeed. I actually find such things annoying[*]. If I want usage instructions, I'll read the corresponding manual pages. A single line should be sufficient, if they must be printed. $ fred usage: fred -lt -c <count> <filename> [*] Such instructions just add useless cruft to the terminal scroll buffer replacing useful history with useless verbiage.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-21 16:36 +0100 |
| Message-ID | <118riuc$3n4v$1@dont-email.me> |
| In reply to | #402318 |
On 21/09/2026 16:06, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 20/09/2026 15:54, bart wrote: >>> On 20/09/2026 14:22, bart wrote: >>>> On 20/09/2026 14:08, David Brown wrote: >>>>> On 20/09/2026 13:42, bart wrote: > >>> One thing puzzles me: if you are correct, then why is it that newer >>> compilers such as for Go, Rust and Zig display a gorgeous set of usage >>> instructions when invoked by their name? >>> >> >> That is a non-sequitur. > > Indeed. > > I actually find such things annoying[*]. If I want usage instructions, > I'll read the corresponding manual pages. 'man' doesn't exist on Windows. If I type 'man go' online, I get links to fashion retailers. In this case the usage summary was enough for me to build hello.go so it did the job. > A single line should > be sufficient, if they must be printed. > > $ fred > usage: fred -lt -c <count> <filename> > > > [*] Such instructions just add useless cruft to the terminal scroll > buffer replacing useful history with useless verbiage. * Hundreds of compiler warning messages can also fill up the buffer. Even once consumed, they are still there * 'as --help', which is surely meant to be used interactively, shows 175 lines of output * 'ld --help' shows 371 lines * cat sql.c (for example) shows 235,000 lines
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-21 17:45 +0200 |
| Message-ID | <118rjeb$2pbc4$1@dont-email.me> |
| In reply to | #402318 |
On 2026-09-21 17:06, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 20/09/2026 15:54, bart wrote: >>> >>> One thing puzzles me: if you are correct, then why is it that newer >>> compilers such as for Go, Rust and Zig display a gorgeous set of usage >>> instructions when invoked by their name? >> >> That is a non-sequitur. > > Indeed. > > I actually find such things annoying[*]. If I want usage instructions, > I'll read the corresponding manual pages. A single line should > be sufficient, if they must be printed. My experience differs; I think whether, what, and which amount of information is necessary and useful generally depends on the respective tool. Sometimes even more than one interactive format is advisable, a usage, and a verbose info with some (but terse) explanations of the options, and the manual as another level of verbosity. Janis BTW; Kornshell's built-in getopts supports that as well; every shell program that uses getopts for its parameter definition and parsing will have the inherent option to print usage and verbose information (along with other fancy stuff, like the verbose info as html or nroff source). See -?, --??, --??html, etc. (There's a reason why that feature is there.) > > $ fred > usage: fred -lt -c <count> <filename> > > > [*] Such instructions just add useless cruft to the terminal scroll > buffer replacing useful history with useless verbiage.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-21 20:54 +0300 |
| Message-ID | <20260921205434.000037cf@yahoo.com> |
| In reply to | #402309 |
On Sun, 20 Sep 2026 23:24:29 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 20/09/2026 15:54, bart wrote: > > On 20/09/2026 14:22, bart wrote: > >> On 20/09/2026 14:08, David Brown wrote: > >>> On 20/09/2026 13:42, bart wrote: > >> > >>>> You don't see that as an issue? OK. But it is purely because you > >>>> think nobody should directly use such tools anyway. > >> > >>> > >>> Yet again - stop believing you know what other people think, or > >>> inventing things you think they say. Try /reading/ posts > >>> instead, and try to understand what they actually wrote. > >> > >> I read this: > >> > >> DB: > >> "You are not writing code and producing executables or libraries. > >> People who do that use the best tools they can get to make their > >> job easier and give better results - they use proper editors or > >> ides, and proper build tools. No sane developer wants to type in > >> a compile command line for every compilation, ..." > > > > > > One thing puzzles me: if you are correct, then why is it that newer > > compilers such as for Go, Rust and Zig display a gorgeous set of > > usage instructions when invoked by their name? > > > > That is a non-sequitur. I said that people normally use build tools > or other conveniences when doing serious development, and avoid > repetitively typing long command lines with lots of options. That > does not mean they /never/ run the compiler command directly. They > might do so for quick tests, or to show version information, or > perhaps to show some hints about arguments. gcc shows usage > instructions if you use the obvious option, "--help". Other tools > may show such information with no arguments - that's their choice. > > > Further, all of them will compile hello.go etc to hello.exe without > > being told. > > > > Sure. They have no history or compatibility to consider. > gcc is relatively new tool. When it was created a.out was already anachronism. Why did they replicate an old behavior? They had an option to preserve an old behavior for backward compatibility when called as cc, but to do whatever they find reasonable when called as gcc. They decided otherwise. Methinks, they were afraid of being accused of heresy. On the other hand, creators of go were immune to such concerns. After all they had the Pope himself in their ranks. > > Why don't they write 'a.exe' by default and force users to have to > > specify the output file every time? Because that's better, right? > > It is better if people expect it to be that way. Don't change things > that are fine the way they are, and that people might be relying on > (however strange that may be to you). > >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-22 15:02 +0000 |
| Message-ID | <cMwsS.87968$5X3.36937@fx12.iad> |
| In reply to | #402325 |
Michael S <already5chosen@yahoo.com> writes: >On Sun, 20 Sep 2026 23:24:29 +0200 >David Brown <david.brown@hesbynett.no> wrote: >> > Further, all of them will compile hello.go etc to hello.exe without=20 >> > being told. >> > =20 >>=20 >> Sure. They have no history or compatibility to consider. >>=20 > >gcc is relatively new tool. For some value of 'new' that includes 39 years?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-22 21:02 +0300 |
| Message-ID | <20260922210201.0000717e@yahoo.com> |
| In reply to | #402336 |
On Tue, 22 Sep 2026 15:02:32 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Sun, 20 Sep 2026 23:24:29 +0200 > >David Brown <david.brown@hesbynett.no> wrote: > > >> > Further, all of them will compile hello.go etc to hello.exe > >> > without=20 being told. > >> > =20 > >>=20 > >> Sure. They have no history or compatibility to consider. > >>=20 > > > >gcc is relatively new tool. > > For some value of 'new' that includes 39 years? > > For a value of "new" as "several years after default a.out became anachronism".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-20 15:58 +0200 |
| Message-ID | <118ooqj$34fbg$2@dont-email.me> |
| In reply to | #402299 |
On 20/09/2026 15:22, bart wrote:
> On 20/09/2026 14:08, David Brown wrote:
>> On 20/09/2026 13:42, bart wrote:
>
>>> You don't see that as an issue? OK. But it is purely because you
>>> think nobody should directly use such tools anyway.
>
>>
>> Yet again - stop believing you know what other people think, or
>> inventing things you think they say. Try /reading/ posts instead, and
>> try to understand what they actually wrote.
>
> I read this:
>
> DB:
> "You are not writing code and producing executables or libraries. People
> who do that use the best tools they can get to make their job easier and
> give better results - they use proper editors or ides, and proper build
> tools. No sane developer wants to type in a compile command line for
> every compilation, ..."
>
Maybe we have different ideas about what "using the tools directly"
means. People doing serious software development will normally use
build tools of some sort rather than typing long command lines manually
for every compilation. But I still count that as using the compiler
directly - indirect usage is when you are not in charge of the source
code. Thus when gcc uses "as" to assemble its output, you are not using
"as" directly. Or when a programming language generates C code and
pushes it through gcc, you are not using gcc directly.
In regard to typing compiler command lines at all, I don't see much use
in doing so except for small and simple test cases - when you are
expecting to repeat the commands and there are a significant number of
arguments, you find a better way. Software developers are, IME, a lazy
bunch - they are not going to repeat the same task if it can be
automated or there are short-cuts.
But I can see how you have used or interpreted terms a little
differently here.
>
>>> WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD?
>
>>> Then under what possible circumstance would writing 'a.exe' ever make
>>> sense!
>
>> Google for the answer. You won't listen if anyone tells you.
> So you don't have an answer and there is no advantage. It is just
> pointless and annoying ancient baggage which makes the tools a pain to
> use directly from the command line.
>
> The sad thing is that newer tools strive to replicate that same behaviour.
>
Does this mean you want me to tell you where "a.out" and "a.exe" comes from?
As you thought, it is historical. It was "assembler output" from an
earlier assembler which had a fixed output filename. It has its roots
back in early computing when the concept of "one tool does one job"
started, with tools working together to give the user flexibility. The
assembler didn't need to handle different file names - that kept it
simpler and smaller (you should appreciate that). Renaming of files was
already handled by the "mv" program.
"One tool, one job" is not always the most convenient for users, and
later assemblers supported arguments for the filename. But "a.out"
remained the default, because that means existing scripts did not need
to be changed. Nothing has changed since then, because nothing needed
to be changed ("a.out" may be considered a quirk, but it is in no sense
a problem), while changing it would break things. It's a no-brainer -
if it ain't broke, don't fix it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-20 15:19 -0700 |
| Message-ID | <118pm5k$3g72a$2@kst.eternal-september.org> |
| In reply to | #402303 |
David Brown <david.brown@hesbynett.no> writes:
> On 20/09/2026 15:22, bart wrote:
[...]
> Does this mean you want me to tell you where "a.out" and "a.exe" comes
> from?
No, bart didn't ask you to tell him where "a.out" and "a.exe" come
from. If he had wanted to know, he could have asked -- or, better,
he could have looked it up somewhere. He obviously doesn't want to
learn anything, he just wants to complain. You are wasting your time
by explaining it to him. Worse, you're wasting everyone else's time.
David, this pointless off-topic argument will continue until
*you* stop posting on it. bart will never stop complaining and
nitpicking every explanation you offer. You can indirectly improve
the signal-to-noise ratio of this newsgroup by not engaging with
bart in off-topic complaints. (And yes, I've certainly been guilty
of this myself.)
If bart really wanted to discuss this (why "a.out", why "as"
reads from stdin), there are places where it would be topical.
If someone wanted to discuss all this in, say, comp.unix.programmer,
I'd likely participate. Do you think that's what bart wants?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-20 23:49 +0100 |
| Message-ID | <118pntr$3hcnp$1@dont-email.me> |
| In reply to | #402311 |
On 20/09/2026 23:19, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 20/09/2026 15:22, bart wrote: > [...] >> Does this mean you want me to tell you where "a.out" and "a.exe" comes >> from? > > No, bart didn't ask you to tell him where "a.out" and "a.exe" come > from. I asked this: "WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD? So they can be a 'drop-in' for gcc? Then nothing would ever changes. Besides, didn't you say all invocations of gcc ought to specify the output file? Then under what possible circumstance would writing 'a.exe' ever make sense!"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-20 16:17 -0700 |
| Message-ID | <118ppi1$3hofj$1@kst.eternal-september.org> |
| In reply to | #402312 |
bart <bc@freeuk.com> writes:
> On 20/09/2026 23:19, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 20/09/2026 15:22, bart wrote:
>> [...]
>>> Does this mean you want me to tell you where "a.out" and "a.exe" comes
>>> from?
>>
>> No, bart didn't ask you to tell him where "a.out" and "a.exe" come
>> from.
>
> I asked this:
>
> "WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD?
Yes, you asked about the possible advantage, not about where they
come from. Those are two distinct questions -- and to be clear
I'm not going to answer either of them here.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-20 15:49 +0000 |
| Message-ID | <pgTrS.40142$iUXd.22047@fx04.iad> |
| In reply to | #402299 |
bart <bc@freeuk.com> writes: >On 20/09/2026 14:08, David Brown wrote: <snip> > >>> WHAT IS THE POSSIBLE ADVANTAGE OF THEM WRITING A.EXE INSTEAD? > >>> Then under what possible circumstance would writing 'a.exe' ever make >>> sense! > >> Google for the answer. You won't listen if anyone tells you. >So you don't have an answer and there is no advantage. The proper object file from a C compiler when no explicit object file has been specified is a.out[*]. That Window implementations of GCC changes that to .exe is erroneous, as the output of the compile need not be an executable file; it may be an intermediate object file or a shared object. [*] As originally designed. It is what it is and cannot be changed. The fact that you don't like either is slightly amusing but primarily foolish.
[toc] | [prev] | [next] | [standalone]
Page 18 of 25 — ← Prev page 1 … 16 17 [18] 19 20 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web