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 15 of 25 — ← Prev page 1 … 13 14 [15] 16 17 … 25 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-17 23:48 +0000 |
| Message-ID | <t%_qS.41250$oan4.36250@fx22.iad> |
| In reply to | #402186 |
bart <bc@freeuk.com> writes: >On 17/09/2026 20:31, tTh wrote: >> On 9/17/26 17:46, bart wrote: >>> >>> Somebody needs some a few lines of info from a program, but the tool >>> buries it in 1000 lines of output, and your suggestion is to just to >>> scroll up and down trying to find it? >>> >>> Anything but fix the problem! >> >> May be you can code a patch who fix the^Wyour problem, and >> send it to the Gcc team ? Any positive contribution is >> benefit to all of us. > >I'm not interested in gcc. I have my own solutions. Then why do you keep harping on its purported defects?
[toc] | [prev] | [next] | [standalone]
| From | "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> |
|---|---|
| Date | 2026-09-18 00:04 +0000 |
| Message-ID | <118hv65$p5d3$1@dont-email.me> |
| In reply to | #402186 |
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
> Most command-line compilers give you version and help info when no
> parameters follow. But at least it says something; try this:
>
> c:\c\as
>
> and it apparently hangs (it's waiting for you type an assembly program
> from the console!)
>
Most people read (or at least skim) the documentation
that comes with the software they use.
% man as
...
If you give 'as' no file names it attempts to read one
input file from the 'as' standard input, which is normally
your terminal. You may have to type ctl-D to tell 'as'
there is no more program to assemble.
HTH
--
steve
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-18 01:34 +0100 |
| Message-ID | <118i0u5$pq3d$1@dont-email.me> |
| In reply to | #402197 |
On 18/09/2026 01:04, Steven G. Kargl wrote:
> On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
>
>> Most command-line compilers give you version and help info when no
>> parameters follow. But at least it says something; try this:
>>
>> c:\c\as
>>
>> and it apparently hangs (it's waiting for you type an assembly program
>> from the console!)
>>
>
> Most people read (or at least skim) the documentation
> that comes with the software they use.
Most people probably don't. They will try running such programs without
input, as often that gives usage info.
'as' is more peculiar than most assemblers:
* It takes input from stdin as default
* The output, even on Windows, is a file called a.out
* If given two or more input files, these are literally concatenated
into one ASM file. More typically there is one object file produced per file
> % man as
'man' doesn't exist on Windows. Using 'as --help' gives lots of
complicated options that will mean little to some who has not used this
before and simply wants to turn file.s into file.o.
This is my assembler for example when I type its name:
c:\c>aa
AA7 Assembler 29-Aug-2026
Usage:
aa filename[.asm] # Assemble filename.asm to filename.exe
aa -help # Show other options
Simple, yes?
> If you give 'as' no file names it attempts to read one
> input file from the 'as' standard input, which is normally
> your terminal. You may have to type ctl-D to tell 'as'
> there is no more program to assemble.
>
> HTH
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-17 17:50 -0700 |
| Message-ID | <118i1th$mqr3$5@kst.eternal-september.org> |
| In reply to | #402199 |
bart <bc@freeuk.com> writes:
> On 18/09/2026 01:04, Steven G. Kargl wrote:
[...]
>> Most people read (or at least skim) the documentation
>> that comes with the software they use.
>
> Most people probably don't. They will try running such programs
> without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves. Your assumptions
about how you think it *should* behave have led you astray.
I suggest that it is your approach, not "as", that needs to change.
Quick summary: You are trying to use tools that were originally
designed to be used in a Unix-like environment, and expecting them
to behave like native Windows tools.
I'll explain further if you ask, but only if you convince me that
you're actually interested in learning.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-18 17:45 +0300 |
| Message-ID | <20260918174509.00003538@yahoo.com> |
| In reply to | #402200 |
On Thu, 17 Sep 2026 17:50:57 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > bart <bc@freeuk.com> writes: > > On 18/09/2026 01:04, Steven G. Kargl wrote: > [...] > >> Most people read (or at least skim) the documentation > >> that comes with the software they use. > > > > Most people probably don't. They will try running such programs > > without input, as often that gives usage info. > > [...] > > You've seen how that approach fails. > > There are valid reasons for the way "as" behaves. Well, if you consider compatibility with weird notion of "user interface" of its original creator as a valid reason, then yes. Even I accept it as valid. Which does not make it less bad in the absolute sense. Desire to give to user an option to accept an input from standard input by itself is not unreasonable, bit it should be an option rather than default. > Your assumptions > about how you think it *should* behave have led you astray. > I suggest that it is your approach, not "as", that needs to change. > > Quick summary: You are trying to use tools that were originally > designed to be used in a Unix-like environment, and expecting them > to behave like native Windows tools. > as default is equelly bad design on both OSes. > I'll explain further if you ask, but only if you convince me that > you're actually interested in learning. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-18 15:28 +0000 |
| Message-ID | <pMcrS.84458$ZAne.6994@fx48.iad> |
| In reply to | #402226 |
Michael S <already5chosen@yahoo.com> writes: >On Thu, 17 Sep 2026 17:50:57 -0700 >Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> bart <bc@freeuk.com> writes: >> > On 18/09/2026 01:04, Steven G. Kargl wrote: >> [...] >> >> Most people read (or at least skim) the documentation >> >> that comes with the software they use. >> > >> > Most people probably don't. They will try running such programs >> > without input, as often that gives usage info. >> >> [...] >> >> You've seen how that approach fails. >> >> There are valid reasons for the way "as" behaves. > >Well, if you consider compatibility with weird notion of "user >interface" of its original creator as a valid reason, then yes. >Even I accept it as valid. >Which does not make it less bad in the absolute sense. >Desire to give to user an option to accept an input from standard >input by itself is not unreasonable, bit it should be an option rather >than default. That's your opinion. That's not the unix philosophy. Many unix commands default to stdin if no file name is specified (specifically to support streaming the output of one command to the input of another). By convention a single dash character may be specified in place of a filename to specify stdin.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-18 18:34 +0300 |
| Message-ID | <20260918183409.000055ce@yahoo.com> |
| In reply to | #402234 |
On Fri, 18 Sep 2026 15:28:21 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Thu, 17 Sep 2026 17:50:57 -0700 > >Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > > >> bart <bc@freeuk.com> writes: > >> > On 18/09/2026 01:04, Steven G. Kargl wrote: > >> [...] > >> >> Most people read (or at least skim) the documentation > >> >> that comes with the software they use. > >> > > >> > Most people probably don't. They will try running such programs > >> > without input, as often that gives usage info. > >> > >> [...] > >> > >> You've seen how that approach fails. > >> > >> There are valid reasons for the way "as" behaves. > > > >Well, if you consider compatibility with weird notion of "user > >interface" of its original creator as a valid reason, then yes. > >Even I accept it as valid. > >Which does not make it less bad in the absolute sense. > >Desire to give to user an option to accept an input from standard > >input by itself is not unreasonable, bit it should be an option > >rather than default. > > That's your opinion. That's not the unix philosophy. Many > unix commands default to stdin if no file name is specified > (specifically to support streaming the output of one command > to the input of another). There is big difference between utilities like grep or sort and something like as. Blindly treating them as the same is wrong. > > By convention a single dash character may be specified > in place of a filename to specify stdin. > The latter is reasonable. What as does is not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-18 18:08 +0200 |
| Message-ID | <118jnm6$1cukm$1@dont-email.me> |
| In reply to | #402237 |
On 18/09/2026 17:34, Michael S wrote: > On Fri, 18 Sep 2026 15:28:21 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >>> On Thu, 17 Sep 2026 17:50:57 -0700 >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> >>>> bart <bc@freeuk.com> writes: >>>>> On 18/09/2026 01:04, Steven G. Kargl wrote: >>>> [...] >>>>>> Most people read (or at least skim) the documentation >>>>>> that comes with the software they use. >>>>> >>>>> Most people probably don't. They will try running such programs >>>>> without input, as often that gives usage info. >>>> >>>> [...] >>>> >>>> You've seen how that approach fails. >>>> >>>> There are valid reasons for the way "as" behaves. >>> >>> Well, if you consider compatibility with weird notion of "user >>> interface" of its original creator as a valid reason, then yes. >>> Even I accept it as valid. >>> Which does not make it less bad in the absolute sense. >>> Desire to give to user an option to accept an input from standard >>> input by itself is not unreasonable, bit it should be an option >>> rather than default. >> >> That's your opinion. That's not the unix philosophy. Many >> unix commands default to stdin if no file name is specified >> (specifically to support streaming the output of one command >> to the input of another). > > There is big difference between utilities like grep or sort and > something like as. Blindly treating them as the same is wrong. > >> >> By convention a single dash character may be specified >> in place of a filename to specify stdin. >> > > The latter is reasonable. What as does is not. > From the manual page of "as" : """ as is primarily intended to assemble the output of the GNU C compiler "gcc" for use by the linker "ld". Nevertheless, we've tried to make as assemble correctly everything that other assemblers for the same machine would assemble. Any exceptions are documented explicitly. This doesn't mean as always uses the same syntax as another assembler for the same architecture; for example, we know of several incompatible versions of 680x0 assembly language syntax. Each time you run as it assembles exactly one source program. The source program is made up of one or more files. (The standard input is also a file.) You give as a command line that has zero or more input file names. The input files are read (from left file name to right). A command-line argument (in any position) that has no special meaning is taken to be an input file name. If you give as no file names it attempts to read one input file from the as standard input, which is normally your terminal. You may have to type ctl-D to tell as there is no more program to assemble. Use -- if you need to explicitly name the standard input file in your command line. """ The primary use of "as" is for assembling the output of "gcc". I think it would have been fine if "as" had required one or two dashes, or another option, to indicated using stdin as the input - but I don't see it as unreasonable that by default it works according to the stated primary use of the program. A common way to handle assembly files on Linux is to use "gcc file.s", with whatever additional options you want, not "as file.s", just as it is common to use "gcc" for linking rather than running "ld" directly. Were I writing a new assembler for Linux, I would probably not make it work as a pipe by default - and require a dash or two, or another command-line option. Running "my-new-assembler" with no options or files would exit immediately, perhaps with a "no input files" error or perhaps with a "use --help for help" message. (Or perhaps with no output at all, which I think would also be a reasonable choice.) So while I think "act as a pipe" is a reasonable choice for "as" with no input files, I think there are other choices that are at least somewhat better. However, where is any of this actually likely to cause an issue in the real world? No one would expect "as" to do anything useful without any input, or an option like "--version" or "--help". The only people likely to be confused are those who have no idea what the program is, and try to figure it out by typing "as". The flaw, IMHO, is not that "as" works as a pipe by default, but its name is too short and generic. "gas" or "gasm" would have been better. On the other hand, I have a number of times run a "grep" command and wondered why it was taking so long - because I'd forgotten to give it the files to search! (That's my fault, not grep's.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-18 11:26 -0700 |
| Message-ID | <118jvog$1grii$2@kst.eternal-september.org> |
| In reply to | #402241 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Were I writing a new assembler for Linux, I would probably not make it
> work as a pipe by default - and require a dash or two, or another
> command-line option. Running "my-new-assembler" with no options or
> files would exit immediately, perhaps with a "no input files" error or
> perhaps with a "use --help for help" message. (Or perhaps with no
> output at all, which I think would also be a reasonable choice.) So
> while I think "act as a pipe" is a reasonable choice for "as" with no
> input files, I think there are other choices that are at least
> somewhat better.
If your new assembler were intended to be a drop-in replacement for
"as", are certain that this behavior would not break existing tools?
How sure are you that gcc, or clang, or some other tool, doesn't send
input to the assembler in a pipe? And why shouldn't they do so?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-09-18 20:39 +0000 |
| Message-ID | <118k7h8$3or$1@news.xmission.com> |
| In reply to | #402244 |
In article <118jvog$1grii$2@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>David Brown <david.brown@hesbynett.no> writes:
>[...]
>> Were I writing a new assembler for Linux, I would probably not make it
>> work as a pipe by default - and require a dash or two, or another
>> command-line option. Running "my-new-assembler" with no options or
>> files would exit immediately, perhaps with a "no input files" error or
>> perhaps with a "use --help for help" message. (Or perhaps with no
>> output at all, which I think would also be a reasonable choice.) So
>> while I think "act as a pipe" is a reasonable choice for "as" with no
>> input files, I think there are other choices that are at least
>> somewhat better.
>
>If your new assembler were intended to be a drop-in replacement for
>"as", are certain that this behavior would not break existing tools?
>How sure are you that gcc, or clang, or some other tool, doesn't send
>input to the assembler in a pipe? And why shouldn't they do so?
It is generally an error condition if both of the following are true:
1) A program (*) is reading from standard input by default - i.e.,
without the user having explicitly requested it (via a command line arg
like "-" or "/dev/stdin").
2) stdin is a tty.
I have gotten in the habit of having my programs check for both of the
above conditions being true (the later using the POSIX "isatty()" function)
and error-aborting if they are. Note that this allows normal operation if
stdin is a pipe or a redirected file (or anything else other than a tty).
Also, another way that I've seen some programs deal with this - that I
think might make Bart happy - is to detect the condition (that stdin is a
tty) and issue a prompt in that case (rather than just aborting).
(*) Meaning, a program that takes command line args, which specify input
files, such as a compiler, or an assembler or something like AWK or Perl.
--
Ted Cruz sounds like every straight man's first wife.
Ted Cruz is such a closet case his first name should have been Tom.
Show some respect! Someday, Ted will have a promising career selling reverse mortgages.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-19 13:10 +0200 |
| Message-ID | <118lqia$2526u$2@dont-email.me> |
| In reply to | #402244 |
On 18/09/2026 20:26, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Were I writing a new assembler for Linux, I would probably not make it >> work as a pipe by default - and require a dash or two, or another >> command-line option. Running "my-new-assembler" with no options or >> files would exit immediately, perhaps with a "no input files" error or >> perhaps with a "use --help for help" message. (Or perhaps with no >> output at all, which I think would also be a reasonable choice.) So >> while I think "act as a pipe" is a reasonable choice for "as" with no >> input files, I think there are other choices that are at least >> somewhat better. > > If your new assembler were intended to be a drop-in replacement for > "as", are certain that this behavior would not break existing tools? No. I had not said my hypothetical new assembler would be a drop-in replacement for "as" - if it were, then obviously I'd follow the behaviour of "as" here. It is unlikely that there is much to be gained in replacing "as" directly - it does all that is needed for a companion to a compiler. The only point, I would say, of writing a new assembler for Linux would be for additional features or capabilities. (Or it could be done for fun!) > How sure are you that gcc, or clang, or some other tool, doesn't send > input to the assembler in a pipe? And why shouldn't they do so? > gcc certainly sends its output to as using a pipe if you specify the "-pipe" option. Otherwise, it uses temporary files (on Linux, this is pretty much the same efficiency as the temporary files are normally never actually saved to the filesystem. Maybe Bart could tell us if giving gcc the "-pipe" option affects the speed on his Windows gcc toolchain).
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-19 13:20 +0100 |
| Message-ID | <118lums$276c8$1@dont-email.me> |
| In reply to | #402273 |
On 19/09/2026 12:10, David Brown wrote: > On 18/09/2026 20:26, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> Were I writing a new assembler for Linux, I would probably not make it >>> work as a pipe by default - and require a dash or two, or another >>> command-line option. Running "my-new-assembler" with no options or >>> files would exit immediately, perhaps with a "no input files" error or >>> perhaps with a "use --help for help" message. (Or perhaps with no >>> output at all, which I think would also be a reasonable choice.) So >>> while I think "act as a pipe" is a reasonable choice for "as" with no >>> input files, I think there are other choices that are at least >>> somewhat better. >> >> If your new assembler were intended to be a drop-in replacement for >> "as", are certain that this behavior would not break existing tools? > > No. I had not said my hypothetical new assembler would be a drop-in > replacement for "as" - if it were, then obviously I'd follow the > behaviour of "as" here. It is unlikely that there is much to be gained > in replacing "as" directly - it does all that is needed for a companion > to a compiler. The only point, I would say, of writing a new assembler > for Linux would be for additional features or capabilities. (Or it > could be done for fun!) > >> How sure are you that gcc, or clang, or some other tool, doesn't send >> input to the assembler in a pipe? And why shouldn't they do so? >> > > gcc certainly sends its output to as using a pipe if you specify the "- > pipe" option. Otherwise, it uses temporary files (on Linux, this is > pretty much the same efficiency as the temporary files are normally > never actually saved to the filesystem. Maybe Bart could tell us if > giving gcc the "-pipe" option affects the speed on his Windows gcc > toolchain). > For building sql.c, then using -pipe consistently gave compile-times of around 7.25 seconds vs 7.5 or so without it. About 4% faster, but this at -O0. Using -O3, then it was 50.1 seconds vs 52.5 seconds (tested once only). I expected the difference to be still around 0.25 seconds (the EXE sizes won't be that different), but then I also forgot to do -s. It needs a better set of tests really. But in general it seems to be insignificant, given that gcc is slow anyway, and even less significant with optimisations on. The same program is built by bcc in 0.23 seconds, direct to EXE. Using a discrete ASM step, then it's 0.53 seconds in all; generating 8MB of ASM is the bottleneck (4.1 seconds from .c to .asm; 0.12 seconds to assemble 270Kloc.) In my original C compiler, it /had/ to go through assembly. But the assembler was built-in, and the intermediate ASM files were kept in memory. This streamlined the process, but ASM still had to be generated. That version compiles this in 0.38 seconds, via that internal ASM. There is a option to turn off that internal ASM, but that seemed to make no difference. Then I looked closer and it was perhaps 0.005 seconds (timings vary by that much anyway), assuming the switch worked.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-19 17:30 +0200 |
| Message-ID | <118m9qv$2cgfb$2@dont-email.me> |
| In reply to | #402276 |
On 19/09/2026 14:20, bart wrote: > On 19/09/2026 12:10, David Brown wrote: >> On 18/09/2026 20:26, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> Were I writing a new assembler for Linux, I would probably not make it >>>> work as a pipe by default - and require a dash or two, or another >>>> command-line option. Running "my-new-assembler" with no options or >>>> files would exit immediately, perhaps with a "no input files" error or >>>> perhaps with a "use --help for help" message. (Or perhaps with no >>>> output at all, which I think would also be a reasonable choice.) So >>>> while I think "act as a pipe" is a reasonable choice for "as" with no >>>> input files, I think there are other choices that are at least >>>> somewhat better. >>> >>> If your new assembler were intended to be a drop-in replacement for >>> "as", are certain that this behavior would not break existing tools? >> >> No. I had not said my hypothetical new assembler would be a drop-in >> replacement for "as" - if it were, then obviously I'd follow the >> behaviour of "as" here. It is unlikely that there is much to be >> gained in replacing "as" directly - it does all that is needed for a >> companion to a compiler. The only point, I would say, of writing a >> new assembler for Linux would be for additional features or >> capabilities. (Or it could be done for fun!) >> >>> How sure are you that gcc, or clang, or some other tool, doesn't send >>> input to the assembler in a pipe? And why shouldn't they do so? >>> >> >> gcc certainly sends its output to as using a pipe if you specify the >> "- pipe" option. Otherwise, it uses temporary files (on Linux, this >> is pretty much the same efficiency as the temporary files are normally >> never actually saved to the filesystem. Maybe Bart could tell us if >> giving gcc the "-pipe" option affects the speed on his Windows gcc >> toolchain). >> > > For building sql.c, then using -pipe consistently gave compile-times of > around 7.25 seconds vs 7.5 or so without it. About 4% faster, but this > at -O0. > > Using -O3, then it was 50.1 seconds vs 52.5 seconds (tested once only). > I expected the difference to be still around 0.25 seconds (the EXE sizes > won't be that different), but then I also forgot to do -s. > Okay, thanks. There's no need for any more tests - it's enough to see that it makes a small but in practice negligible difference.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-19 09:38 +0200 |
| Message-ID | <118le5e$scqh$4@dont-email.me> |
| In reply to | #402241 |
On 2026-09-18 18:08, David Brown wrote: > On 18/09/2026 17:34, Michael S wrote: >> On Fri, 18 Sep 2026 15:28:21 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: [...] >>> >>> By convention a single dash character may be specified >>> in place of a filename to specify stdin. >> >> The latter is reasonable. What as does is not. > > From the manual page of "as" : [snip] > > The primary use of "as" is for assembling the output of "gcc". I think > it would have been fine if "as" had required one or two dashes, or > another option, to indicated using stdin as the input - but I don't see > it as unreasonable that by default it works according to the stated > primary use of the program. > > A common way to handle assembly files on Linux is to use "gcc file.s", > with whatever additional options you want, not "as file.s", just as it > is common to use "gcc" for linking rather than running "ld" directly. > > Were I writing a new assembler for Linux, I would probably not make it > work as a pipe by default - and require a dash or two, or another > command-line option. Running "my-new-assembler" with no options or > files would exit immediately, perhaps with a "no input files" error or > perhaps with a "use --help for help" message. (Or perhaps with no > output at all, which I think would also be a reasonable choice.) So > while I think "act as a pipe" is a reasonable choice for "as" with no > input files, I think there are other choices that are at least somewhat > better. > > However, where is any of this actually likely to cause an issue in the > real world? No one would expect "as" to do anything useful without any > input, or an option like "--version" or "--help". The only people > likely to be confused are those who have no idea what the program is, > and try to figure it out by typing "as". The flaw, IMHO, is not that > "as" works as a pipe by default, but its name is too short and generic. > "gas" or "gasm" would have been better. I agree with all you wrote. - The problem on Unixes is more that there's not exactly a single method used on that interface level that one can rely on. One has to read the diagnostics and/or the man page. And if there's someone coming from another "IT world" he might have issues. (Most folks will learn the concepts while others will complain, and sometimes not stop complaining, instead of just informing themselves about the concepts and concrete use). Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-19 21:00 +0300 |
| Message-ID | <20260919210012.00002ae1@yahoo.com> |
| In reply to | #402241 |
On Fri, 18 Sep 2026 18:08:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 18/09/2026 17:34, Michael S wrote: > > On Fri, 18 Sep 2026 15:28:21 GMT > > scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >>> On Thu, 17 Sep 2026 17:50:57 -0700 > >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >>> > >>>> bart <bc@freeuk.com> writes: > >>>>> On 18/09/2026 01:04, Steven G. Kargl wrote: > >>>> [...] > >>>>>> Most people read (or at least skim) the documentation > >>>>>> that comes with the software they use. > >>>>> > >>>>> Most people probably don't. They will try running such programs > >>>>> without input, as often that gives usage info. > >>>> > >>>> [...] > >>>> > >>>> You've seen how that approach fails. > >>>> > >>>> There are valid reasons for the way "as" behaves. > >>> > >>> Well, if you consider compatibility with weird notion of "user > >>> interface" of its original creator as a valid reason, then yes. > >>> Even I accept it as valid. > >>> Which does not make it less bad in the absolute sense. > >>> Desire to give to user an option to accept an input from standard > >>> input by itself is not unreasonable, bit it should be an option > >>> rather than default. > >> > >> That's your opinion. That's not the unix philosophy. Many > >> unix commands default to stdin if no file name is specified > >> (specifically to support streaming the output of one command > >> to the input of another). > > > > There is big difference between utilities like grep or sort and > > something like as. Blindly treating them as the same is wrong. > > > >> > >> By convention a single dash character may be specified > >> in place of a filename to specify stdin. > >> > > > > The latter is reasonable. What as does is not. > > > > From the manual page of "as" : > > """ > as is primarily intended to assemble the output of the GNU C compiler > "gcc" for use by the linker "ld". Nevertheless, we've tried to make > as assemble correctly everything that other assemblers for the same > machine would assemble. Any exceptions are documented explicitly. > This doesn't mean as always uses the same syntax as another assembler > for the same architecture; for example, we know of several > incompatible versions of 680x0 assembly language syntax. > I don't know when this paragraph was written. Today's gnu as is pretty reasonable tool for assembler develpment. Decent macro capabilities etc... Likely, not on par with macro-assemblers of IBM mainframes or of VAX/VMS, but rather similar in capabilities to Microsoft's Masm or with nasm. Certainly it is far more complete tool than what would be neeaded to process gcc output into objects. > Each time you run as it assembles exactly one source program. The > source program is made up of one or more files. (The standard input > is also a file.) > > You give as a command line that has zero or more input file names. > The input files are read (from left file name to right). A > command-line argument (in any position) that has no special meaning > is taken to be an input file name. > > If you give as no file names it attempts to read one input file from > the as standard input, which is normally your terminal. You may have > to type ctl-D to tell as there is no more program to assemble. > > Use -- if you need to explicitly name the standard input file in your > command line. > """ > > The primary use of "as" is for assembling the output of "gcc". I > think it would have been fine if "as" had required one or two dashes, > or another option, to indicated using stdin as the input - but I > don't see it as unreasonable that by default it works according to > the stated primary use of the program. > > A common way to handle assembly files on Linux is to use "gcc > file.s", with whatever additional options you want, not "as file.s", > just as it is common to use "gcc" for linking rather than running > "ld" directly. > > > Were I writing a new assembler for Linux, I would probably not make > it work as a pipe by default - and require a dash or two, or another > command-line option. Running "my-new-assembler" with no options or > files would exit immediately, perhaps with a "no input files" error > or perhaps with a "use --help for help" message. (Or perhaps with no > output at all, which I think would also be a reasonable choice.) So > while I think "act as a pipe" is a reasonable choice for "as" with no > input files, I think there are other choices that are at least > somewhat better. > > However, where is any of this actually likely to cause an issue in > the real world? No one would expect "as" to do anything useful > without any input, or an option like "--version" or "--help". The > only people likely to be confused are those who have no idea what the > program is, and try to figure it out by typing "as". Those people are commnon. > The flaw, IMHO, > is not that "as" works as a pipe by default, but its name is too > short and generic. "gas" or "gasm" would have been better. > > > On the other hand, I have a number of times run a "grep" command and > wondered why it was taking so long - because I'd forgotten to give it > the files to search! (That's my fault, not grep's.) > If grep required additional option for acception of input from stadard input that would be [mildly] annoying.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-20 10:17 +0200 |
| Message-ID | <118o4r5$2uhm1$2@dont-email.me> |
| In reply to | #402284 |
On 19/09/2026 20:00, Michael S wrote: > On Fri, 18 Sep 2026 18:08:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/09/2026 17:34, Michael S wrote: >>> On Fri, 18 Sep 2026 15:28:21 GMT >>> scott@slp53.sl.home (Scott Lurndal) wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>>> On Thu, 17 Sep 2026 17:50:57 -0700 >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>>> >>>>>> bart <bc@freeuk.com> writes: >>>>>>> On 18/09/2026 01:04, Steven G. Kargl wrote: >>>>>> [...] >>>>>>>> Most people read (or at least skim) the documentation >>>>>>>> that comes with the software they use. >>>>>>> >>>>>>> Most people probably don't. They will try running such programs >>>>>>> without input, as often that gives usage info. >>>>>> >>>>>> [...] >>>>>> >>>>>> You've seen how that approach fails. >>>>>> >>>>>> There are valid reasons for the way "as" behaves. >>>>> >>>>> Well, if you consider compatibility with weird notion of "user >>>>> interface" of its original creator as a valid reason, then yes. >>>>> Even I accept it as valid. >>>>> Which does not make it less bad in the absolute sense. >>>>> Desire to give to user an option to accept an input from standard >>>>> input by itself is not unreasonable, bit it should be an option >>>>> rather than default. >>>> >>>> That's your opinion. That's not the unix philosophy. Many >>>> unix commands default to stdin if no file name is specified >>>> (specifically to support streaming the output of one command >>>> to the input of another). >>> >>> There is big difference between utilities like grep or sort and >>> something like as. Blindly treating them as the same is wrong. >>> >>>> >>>> By convention a single dash character may be specified >>>> in place of a filename to specify stdin. >>>> >>> >>> The latter is reasonable. What as does is not. >>> >> >> From the manual page of "as" : >> >> """ >> as is primarily intended to assemble the output of the GNU C compiler >> "gcc" for use by the linker "ld". Nevertheless, we've tried to make >> as assemble correctly everything that other assemblers for the same >> machine would assemble. Any exceptions are documented explicitly. >> This doesn't mean as always uses the same syntax as another assembler >> for the same architecture; for example, we know of several >> incompatible versions of 680x0 assembly language syntax. >> > > I don't know when this paragraph was written. > Today's gnu as is pretty reasonable tool for assembler develpment. > Decent macro capabilities etc... Likely, not on par with > macro-assemblers of IBM mainframes or of VAX/VMS, but rather similar in > capabilities to Microsoft's Masm or with nasm. > Certainly it is far more complete tool than what would be neeaded to > process gcc output into objects. I also have no idea when it was written, but nothing you wrote contradicts it. As I understand it, "as" was originally intended to work as the assembler for a compiler, but the developers also saw that it could be made useful as a general-purpose stand-alone assembler. It may even be the case that they put more effort into coding that aspect of its use than handling compiler output. Nonetheless, handling compiler output is their stated primary use-case. (I've used a lot of different assemblers for microcontrollers through the years, but have not used "as" directly in real projects. All my targets that have had "as" have also had gcc, and so I programmed in C or C++ instead - handling any assembly as inline assembly in C.) >> >> >> On the other hand, I have a number of times run a "grep" command and >> wondered why it was taking so long - because I'd forgotten to give it >> the files to search! (That's my fault, not grep's.) >> > > If grep required additional option for acception of input from stadard > input that would be [mildly] annoying. > Agreed. I'd rather occasionally be surprised when I forgot the filename than have to add an additional argument when I want to use it as a pipe.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-20 11:29 +0100 |
| Message-ID | <118ocih$31cmo$1@dont-email.me> |
| In reply to | #402291 |
On 20/09/2026 09:17, David Brown wrote:
> On 19/09/2026 20:00, Michael S wrote:
>> I don't know when this paragraph was written.
>> Today's gnu as is pretty reasonable tool for assembler develpment.
>> Decent macro capabilities etc... Likely, not on par with
>> macro-assemblers of IBM mainframes or of VAX/VMS, but rather similar in
>> capabilities to Microsoft's Masm or with nasm.
>> Certainly it is far more complete tool than what would be neeaded to
>> process gcc output into objects.
>
> I also have no idea when it was written, but nothing you wrote
> contradicts it. As I understand it, "as" was originally intended to
> work as the assembler for a compiler, but the developers also saw that
> it could be made useful as a general-purpose stand-alone assembler. It
> may even be the case that they put more effort into coding that aspect
> of its use than handling compiler output. Nonetheless, handling
> compiler output is their stated primary use-case.
Most of my language projects use this module-naming scheme:
xx Lead module that contains project info
xx_cli The CLI-based front-end
xx_* The rest of the modules
With some of them, I can use a version without that CLI module, when
embedded into another app for example, or building into a DLL where the
xx_* stuff is accessed via an API.
The point is, I treat the two cases separately:
* Use a dedicate CLI front-end for a decent interactive version
* Have a separate interface for use as embedded, or via API
The latter need not rule out taking input from stdin, but it's not
something I do. If you have an API, then you can either pass it the name
of a file, or an in-memory string.
The choice is also always there to invoke the CLI version
programmatically; having sensible CLI is not a hindrance! It's just cruder.
> (I've used a lot of different assemblers for microcontrollers
I've /written/ a few including for an Intel microcontroller, almost most
assembly has written inline within my HLL.
>> If grep required additional option for acception of input from stadard
>> input that would be [mildly] annoying.
>>
>
> Agreed. I'd rather occasionally be surprised when I forgot the filename
> than have to add an additional argument when I want to use it as a pipe.
I suppose it would be out of the question to give it a different name
for those two purposes? I thought Linux was great at the sort of thing.
It can either be two separate executables, or the same one (via an
alias) and it uses the name of the invoked executable to determine
behaviour.
One major program (can't remember if Rust or LLVM) worked like that:
multiple executables of the exact same size, and the exact same contents.
I sometimes do that too, but I just use a copy:
c:\mx>copy mm.exe ms.exe
1 file(s) copied.
c:\mx>mm hello
Compiling hello.m to hello.exe
c:\mx>ms hello
Hello, World
So, with the 'ms' name, the compiler applies the -r and -q options to
run a program like a script (the -q makes it quiet).
It is not rocket-science. So I don't know what phenomenon this is, where
millions of people are stuck with the same quirky utilities for decades,
when such solutions exist.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-20 12:52 +0100 |
| Message-ID | <118ohdl$334k9$1@dont-email.me> |
| In reply to | #402293 |
On 20/09/2026 11:29, bart wrote:
> I suppose it would be out of the question to give it a different name
> for those two purposes? I thought Linux was great at the sort of thing.
> I sometimes do that too, but I just use a copy:
>
> c:\mx>copy mm.exe ms.exe
> 1 file(s) copied.
>
> c:\mx>mm hello
> Compiling hello.m to hello.exe
>
> c:\mx>ms hello
> Hello, World
I forgot my C compiler has the feature too. So since this is a C forum:
c:\cx>copy cc.exe ci.exe
1 file(s) copied.
c:\cx>copy cc.exe cs.exe
1 file(s) copied.
c:\cx>ci hello
Hello, World!
c:\cx>cs hello
Hello, World!
'ci' interprets the code, but it runs slower. 'cs' runs native code. But
'ci' can give a shorter compile-time for bigger programs.
The point is that program options can effectively be encoded into the
name of an executable, /without changing anything inside it/.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-06 01:06 +0000 |
| Message-ID | <11a1hhv$3u6ge$3@paganini.bofh.team> |
| In reply to | #402293 |
bart <bc@freeuk.com> wrote:
>
> It is not rocket-science. So I don't know what phenomenon this is, where
> millions of people are stuck with the same quirky utilities for decades,
> when such solutions exist.
I think it is not that "people are stuck or decades". Rather, you
are trying to keep good aspects of the past alive. AFAICS around
1990 there were plenty of language tools working the way you want.
But now only handful (like 'gcc') survive and remain reasonably
popular. It is for you to decide if there is a conspiracy to
deprive programmers of good tools. Or maybe there are deeper reasons
for thing to be the way they are.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-09-20 15:58 -0700 |
| Message-ID | <118poeb$3hhhe$1@dont-email.me> |
| In reply to | #402291 |
On 9/20/2026 1:17 AM, David Brown wrote: [...] as is very useful. Well it was for me back in the day. Well, I mean GAS. https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html https://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html GAS was kind to me. # Copyright 2005 Chris Thomasson .align 16 .globl np_ac_i686_atomic_dwcas_fence np_ac_i686_atomic_dwcas_fence: pushl %esi pushl %ebx movl 16(%esp), %esi movl (%esi), %eax movl 4(%esi), %edx movl 20(%esp), %esi movl (%esi), %ebx movl 4(%esi), %ecx movl 12(%esp), %esi lock cmpxchg8b (%esi) jne np_ac_i686_atomic_dwcas_fence_fail xorl %eax, %eax popl %ebx popl %esi ret np_ac_i686_atomic_dwcas_fence_fail: movl 16(%esp), %esi movl %eax, (%esi) movl %edx, 4(%esi) movl $1, %eax popl %ebx popl %esi ret .align 16 .globl ac_i686_stack_mpmc_push_cas ac_i686_stack_mpmc_push_cas: movl 4(%esp), %edx movl (%edx), %eax movl 8(%esp), %ecx ac_i686_stack_mpmc_push_cas_retry: movl %eax, (%ecx) lock cmpxchgl %ecx, (%edx) jne ac_i686_stack_mpmc_push_cas_retry ret .align 16 .globl np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas: pushl %esi pushl %ebx np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas_reload: movl 12(%esp), %esi movl 4(%esi), %edx movl (%esi), %eax np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas_retry: movl 16(%esp), %ebx movl %eax, (%ebx) mfence cmpl (%esi), %eax jne np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas_reload test %eax, %eax je np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas_fail movl (%eax), %ebx leal 1(%edx), %ecx lock cmpxchg8b (%esi) jne np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas_retry np_ac_i686_lfgc_smr_stack_mpmc_pop_dwcas_fail: movl 16(%esp), %esi xorl %ebx, %ebx movl %ebx, (%esi) popl %ebx popl %esi ret .align 16 .globl np_ac_i686_stack_mpmc_pop_dwcas np_ac_i686_stack_mpmc_pop_dwcas: pushl %esi pushl %ebx movl 12(%esp), %esi movl 4(%esi), %edx movl (%esi), %eax np_ac_i686_stack_mpmc_pop_dwcas_retry: test %eax, %eax je np_ac_i686_stack_mpmc_pop_dwcas_fail movl (%eax), %ebx leal 1(%edx), %ecx lock cmpxchg8b (%esi) jne np_ac_i686_stack_mpmc_pop_dwcas_retry np_ac_i686_stack_mpmc_pop_dwcas_fail: popl %ebx popl %esi ret .align 16 .globl ac_i686_lfgc_smr_activate ac_i686_lfgc_smr_activate: movl 4(%esp), %edx movl 8(%esp), %ecx ac_i686_lfgc_smr_activate_reload: movl (%ecx), %eax movl %eax, (%edx) mfence cmpl (%ecx), %eax jne ac_i686_lfgc_smr_activate_reload ret .align 16 .globl ac_i686_lfgc_smr_deactivate ac_i686_lfgc_smr_deactivate: movl 4(%esp), %ecx xorl %eax, %eax movl %eax, (%ecx) ret .align 16 .globl ac_i686_queue_spsc_push ac_i686_queue_spsc_push: movl 4(%esp), %eax movl 8(%esp), %ecx movl 4(%eax), %edx # sfence may be needed here for future x86 movl %ecx, (%edx) movl %ecx, 4(%eax) ret .align 16 .globl ac_i686_queue_spsc_pop ac_i686_queue_spsc_pop: pushl %ebx movl 8(%esp), %ecx movl (%ecx), %eax cmpl 4(%ecx), %eax je ac_i686_queue_spsc_pop_failed movl (%eax), %edx # lfence may be needed here for future x86 movl 12(%edx), %ebx movl %edx, (%ecx) movl %ebx, 12(%eax) popl %ebx ret ac_i686_queue_spsc_pop_failed: xorl %eax, %eax popl %ebx ret .align 16 .globl ac_i686_mb_fence ac_i686_mb_fence: mfence ret .align 16 .globl ac_i686_mb_naked ac_i686_mb_naked: ret .align 16 .globl ac_i686_mb_store_fence ac_i686_mb_store_fence: movl 4(%esp), %ecx movl 8(%esp), %eax mfence movl %eax, (%ecx) ret .align 16 .globl ac_i686_mb_store_naked ac_i686_mb_store_naked: movl 4(%esp), %ecx movl 8(%esp), %eax movl %eax, (%ecx) ret .align 16 .globl ac_i686_mb_load_fence ac_i686_mb_load_fence: movl 4(%esp), %ecx movl (%ecx), %eax mfence ret .align 16 .globl ac_i686_mb_load_naked ac_i686_mb_load_naked: movl 4(%esp), %ecx movl (%ecx), %eax ret .align 16 .globl ac_i686_atomic_xchg_fence ac_i686_atomic_xchg_fence: movl 4(%esp), %ecx movl 8(%esp), %eax xchgl %eax, (%ecx) ret .align 16 .globl ac_i686_atomic_xadd_fence ac_i686_atomic_xadd_fence: movl 4(%esp), %ecx movl 8(%esp), %eax lock xaddl %eax, (%ecx) ret .align 16 .globl ac_i686_atomic_inc_fence ac_i686_atomic_inc_fence: movl 4(%esp), %ecx movl $1, %eax lock xaddl %eax, (%ecx) incl %eax ret .align 16 .globl ac_i686_atomic_dec_fence ac_i686_atomic_dec_fence: movl 4(%esp), %ecx movl $-1, %eax lock xaddl %eax, (%ecx) decl %eax ret .align 16 .globl ac_i686_atomic_cas_fence ac_i686_atomic_cas_fence: movl 4(%esp), %ecx movl 8(%esp), %eax movl 12(%esp), %edx lock cmpxchgl %edx, (%ecx) ret
[toc] | [prev] | [next] | [standalone]
Page 15 of 25 — ← Prev page 1 … 13 14 [15] 16 17 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web