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 22 of 25 — ← Prev page 1 … 20 21 [22] 23 24 25 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-09-30 13:37 +0000 |
| Message-ID | <119j3ac$9bf$1@reader1.panix.com> |
| In reply to | #402546 |
In article <119inl6$4fd7$1@dont-email.me>, bart <bc@freeuk.com> wrote: >On 30/09/2026 03:02, Lawrence D’Oliveiro wrote: >> On Tue, 29 Sep 2026 14:27:37 +0100, bart wrote: >> >>> On 29/09/2026 01:56, Lawrence D’Oliveiro wrote: >>>> On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: >>>> >>>>> On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: >>>>>> >>>>>> True story: if you read the official OpenGL spec, all the names >>>>>> of functions and constants are defined *without* “gl” or “GL_” >>>>>> prefixes (respectively). >>>>> >>>>> Link? Because here for example: >>>>> >>>>> https://registry.khronos.org/OpenGL-Refpages/gl4/ >>>>> >>>>> the 'gl' is present. All exports from opengl.dll use 'gl' or >>>>> 'wgl', and from glu32.dll they have "glu". It would be confusing >>>>> if several DLLs all exported commonly named functions like >>>>> "Start", "End", "Init", "Error". >>>> >>>> <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf> >>> >>> I can see why the gl (as I can now see that it is) and GL are not >>> shown: they reduce readability. But this is how everyone will be >>> using it. >> >> Only in languages that don’t support proper namespaces, as I pointed >> out. > >You snipped this quote: I'm only responding to point out that this is Lawrence's troll MO: he snips context that doesn't directly support whatever vacuous point he's trying to make. It boggles my mind that people still try to engage with him in good faith, when he so rarely affords the same respect to others. Don't waste your time feeding the troll. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-30 17:17 +0300 |
| Message-ID | <20260930171711.000033cf@yahoo.com> |
| In reply to | #402567 |
On Wed, 30 Sep 2026 13:37:16 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > > It boggles my mind that people still try to engage with him in > good faith, when he so rarely affords the same respect to > others. > Because while there is no doubt that Lawrence is troll, he is not a useless troll.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-09-30 14:39 +0000 |
| Message-ID | <119j6u9$1a$1@reader1.panix.com> |
| In reply to | #402569 |
In article <20260930171711.000033cf@yahoo.com>, Michael S <already5chosen@yahoo.com> wrote: >On Wed, 30 Sep 2026 13:37:16 -0000 (UTC) >cross@spitfire.i.gajendra.net (Dan Cross) wrote: >> >> It boggles my mind that people still try to engage with him in >> good faith, when he so rarely affords the same respect to >> others. >> > >Because while there is no doubt that Lawrence is troll, he is not a >useless troll. I'm afraid we must disagree here. I find his opinions sophomoric, and his technical judgement (and ability) lacking. Further, his website is full of straight up kookiedooks nonsense about mathematics and other things that he clearly has no deep knowledge of. It is best not to encourage him. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-30 22:39 +0000 |
| Message-ID | <119k32j$la7j$3@dont-email.me> |
| In reply to | #402546 |
On Wed, 30 Sep 2026 11:18:15 +0100, bart wrote: > On 30/09/2026 03:02, Lawrence D’Oliveiro wrote: >> >> On Tue, 29 Sep 2026 14:27:37 +0100, bart wrote: >> >>> On 29/09/2026 01:56, Lawrence D’Oliveiro wrote: >>>> >>>> On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: >>>> >>>>> On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: >>>>>> >>>>>> True story: if you read the official OpenGL spec, all the names >>>>>> of functions and constants are defined *without* “gl” or “GL_” >>>>>> prefixes (respectively). >>>>> >>>>> Link? Because here for example: >>>>> >>>>> https://registry.khronos.org/OpenGL-Refpages/gl4/ >>>>> >>>>> the 'gl' is present. All exports from opengl.dll use 'gl' or >>>>> 'wgl', and from glu32.dll they have "glu". It would be confusing >>>>> if several DLLs all exported commonly named functions like >>>>> "Start", "End", "Init", "Error". >>>> >>>> <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf> >>> >>> I can see why the gl (as I can now see that it is) and GL are not >>> shown: they reduce readability. But this is how everyone will be >>> using it. >> >> Only in languages that don’t support proper namespaces, as I pointed >> out. > > So it comes down to the fact that, in practice, you end up using some > sort of prefix anyway. Whether ".", "::", "_" or "" is used as a > separator is a minor detail. In a language that supports namespaces like Python, you have a choice of how to manage the naming. This means being able to choose what prefix you want to use within a given scope to access particular imported names under, or even no prefix at all.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-01 15:23 -0700 |
| Message-ID | <119mmh5$1jj11$1@dont-email.me> |
| In reply to | #402593 |
On 9/30/2026 3:39 PM, Lawrence D’Oliveiro wrote: > On Wed, 30 Sep 2026 11:18:15 +0100, bart wrote: > >> On 30/09/2026 03:02, Lawrence D’Oliveiro wrote: >>> >>> On Tue, 29 Sep 2026 14:27:37 +0100, bart wrote: >>> >>>> On 29/09/2026 01:56, Lawrence D’Oliveiro wrote: >>>>> >>>>> On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: >>>>> >>>>>> On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: >>>>>>> >>>>>>> True story: if you read the official OpenGL spec, all the names >>>>>>> of functions and constants are defined *without* “gl” or “GL_” >>>>>>> prefixes (respectively). >>>>>> >>>>>> Link? Because here for example: >>>>>> >>>>>> https://registry.khronos.org/OpenGL-Refpages/gl4/ >>>>>> >>>>>> the 'gl' is present. All exports from opengl.dll use 'gl' or >>>>>> 'wgl', and from glu32.dll they have "glu". It would be confusing >>>>>> if several DLLs all exported commonly named functions like >>>>>> "Start", "End", "Init", "Error". >>>>> >>>>> <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf> >>>> >>>> I can see why the gl (as I can now see that it is) and GL are not >>>> shown: they reduce readability. But this is how everyone will be >>>> using it. >>> >>> Only in languages that don’t support proper namespaces, as I pointed >>> out. >> >> So it comes down to the fact that, in practice, you end up using some >> sort of prefix anyway. Whether ".", "::", "_" or "" is used as a >> separator is a minor detail. > > In a language that supports namespaces like Python, you have a choice > of how to manage the naming. This means being able to choose what > prefix you want to use within a given scope to access particular > imported names under, or even no prefix at all. Right. The prefix works with namespaces or not. I tended to get a little verbose in C. ct_lib_subsystem_function So like ct_plot_plane_getpixel or something like that. I always found the MS way of postfixing on an Ex or something funny.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-02 02:38 +0000 |
| Message-ID | <119n5f1$1ni9u$3@dont-email.me> |
| In reply to | #402626 |
On Thu, 1 Oct 2026 15:23:30 -0700, Chris M. Thomasson wrote: > The prefix works with namespaces or not. I tended to get a little > verbose in C. > > ct_lib_subsystem_function > > So like ct_plot_plane_getpixel or something like that. Cryptic two-character prefixes only allow for a maximum of, optimistically, about 900 different libraries before name collisions become unavoidable. This is why proper namespace support becomes important. > I always found the MS way of postfixing on an Ex or something funny. Microsoft used to be fond of “Hungarian notation” at one point. I think they’ve stopped embarrassing themselves on that front now ...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-02 09:17 +0200 |
| Message-ID | <119nlq6$1rmn1$2@dont-email.me> |
| In reply to | #402629 |
On 02/10/2026 04:38, Lawrence D’Oliveiro wrote: > On Thu, 1 Oct 2026 15:23:30 -0700, Chris M. Thomasson wrote: > >> The prefix works with namespaces or not. I tended to get a little >> verbose in C. >> >> ct_lib_subsystem_function >> >> So like ct_plot_plane_getpixel or something like that. > > Cryptic two-character prefixes only allow for a maximum of, > optimistically, about 900 different libraries before name collisions > become unavoidable. This is why proper namespace support becomes > important. Usually the prefixing is something for libraries that are going to be re-used on a wide basis. It's not something people generally do for their own code. Perhaps some people are not very good at declaring functions and objects "static", and then they can get conflicts faster. There is a proposal for adding namespaces to C that works with prefixes, since C++ style name mangling is not a serious option for C. > >> I always found the MS way of postfixing on an Ex or something funny. > > Microsoft used to be fond of “Hungarian notation” at one point. I > think they’ve stopped embarrassing themselves on that front now ... The biggest issue with "Hungarian notation" is that some people totally misunderstood the point of it and a very questionable "Systems Hungarian notation" emerged. Originally (as I understand the history), "Hungarian notation" meant you might have two "char *" variables called "usUserInput" and "ssUserInput". The first was for "unsafe string", the second for "sanitised string". The point was for programmers to be able to see critical facts about identifiers in an obvious way, thus avoiding mistakes like getting an input from a web page and passing it on to an SQL query before sanitising it. A better solution would be strong types - make a struct called "Unsafe_string" wrapping the char*, and another called "Sanitised_string", and most mixups will be caught as compiler errors. But this notation was used to improve code written in an older or simpler style with few different types. It worked as intended, and reduced errors. Then somebody thought the important part was the "string" bit, not the "unsafe / sanitised" bit. They started using "i" for int, "c" for char, "p" for pointer, and so on. This is just duplicating information that should be quite clear to the programmer - usually you know the types of the things you are dealing with. And if you have a half-decent IDE or programming editor, the tool can quickly tell you.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-25 12:17 +0300 |
| Message-ID | <20260925121736.000008b3@yahoo.com> |
| In reply to | #402370 |
On Fri, 25 Sep 2026 01:23:30 +0100 bart <bc@freeuk.com> wrote: > On 25/09/2026 00:54, Lawrence D’Oliveiro wrote: > > On Thu, 24 Sep 2026 11:27:21 +0100, bart wrote: > > > >> On 24/09/2026 03:41, Lawrence D’Oliveiro wrote: > > >>> <https://docs.python.org/3/genindex-all.html> > >> > >> You're missing my point: I can use those 2000 names by simpler > >> listing their containing modules /at one place/ in the application. > >> I don't need to list random subsets of those 2000 names at the top > >> of each of the dozens of modules that comprise the project. > > > > You’re missing *my* point: your approach doesn’t scale. > > What doesn't scale: my application, the library, or both? > Avoidance of name clashes. Esp. so in absence of "The World Librarian" authority. But probbly even if it was presenst.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-25 11:31 +0100 |
| Message-ID | <1195ihs$3g9gn$1@dont-email.me> |
| In reply to | #402381 |
On 25/09/2026 10:17, Michael S wrote:
> On Fri, 25 Sep 2026 01:23:30 +0100
> bart <bc@freeuk.com> wrote:
>
>> On 25/09/2026 00:54, Lawrence D’Oliveiro wrote:
>>> On Thu, 24 Sep 2026 11:27:21 +0100, bart wrote:
>>>
>>>> On 24/09/2026 03:41, Lawrence D’Oliveiro wrote:
>>
>>>>> <https://docs.python.org/3/genindex-all.html>
>>>>
>>>> You're missing my point: I can use those 2000 names by simpler
>>>> listing their containing modules /at one place/ in the application.
>>>> I don't need to list random subsets of those 2000 names at the top
>>>> of each of the dozens of modules that comprise the project.
>>>
>>> You’re missing *my* point: your approach doesn’t scale.
>>
>> What doesn't scale: my application, the library, or both?
>>
>
> Avoidance of name clashes.
> Esp. so in absence of "The World Librarian" authority. But probbly even
> if it was presenst.
Clashes (eg. two libraries export the same name) are not a problem. In
my scheme it means having to qualify the name: a.f() or b.f() instead of
just f(). The compiler will report the ambiguity; in Python the second
'f' silently replaces the first.
In Python, you'd have to do the same if using 'from'; you'd have to use
'import' and qualify the names. However, the 'from' mechanism makes it
possible to do, for example:
import a
from b import f
so that you can still use b() for one library but need a.b() for the
other. Or possibly a.f() is not called anyway.
But this is exactly where the problem lies when the libraries may export
thousands of names:
* Having to identify and give special treatment to selected names
* Mixing qualified/unqualified names in the same codebase
* Having to do the same, and with a different set of clashed names, in
every module. But one has clashes with a/b imports; another it's a/c;
another it's a/b/c; another has no clashes because f is not called.
* Having to maintain those special declarations as the call patterns
change.
------------------------
C has its own problems here. Take these two 'libraries' both exporting 'F':
#include <stdio.h> // one.c
void F(){ puts("ONE"); }
#include <stdio.h> // two.c
void F(){ puts("TWO"); }
They are used from this application:
#include <stdio.h> // c.c
void F();
int main() { F(); }
If I try and statically compile these using:
gcc c.c one.c two.c
then it reports that F is multiply defined. So now I try and create a
shared library for each:
gcc -shared one.c -o one.dll
gcc -shared two.c -o two.dll
And try again:
gcc c.c one.dll two.dll
Now it builds, but when run it displays 'TWO'. It arbitrarily uses F
from one of those libraries.
The only solutions in C for the first case is to use different names for
F, but that is hard if those modules come from third parties.
In the DLL case, it might be possible,, if the C app knows which DLL
version it needs, but it depends on the implementation and the tools. Or
an approach using runtime loading of the DLL.
--------------------------------------------
In my languages, the first case is easy: the compiler reports an
ambiguity so I have to write one.F or two.F.
But with DLLs, the systems language has a similar problem. And the
reason is that such imported names are not searched for in a specific
DLL, even though they are defined like this:
importdll one =
proc F
end
I just haven't bothered using this info in the EXE-generating backend.
In my dynamic language, it works fine, although those import blocks have
to be in difference files (F has file-scope), and at least one F has to
be qualified at the call-site.
I've no idea about Python's capabilities here (calling two functions in
two external DLLs both with the same name).
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-26 02:34 +0000 |
| Message-ID | <1197av3$4ikc$1@dont-email.me> |
| In reply to | #402384 |
On Fri, 25 Sep 2026 11:31:23 +0100, bart wrote: > * Having to identify and give special treatment to selected names Also makes it easy to identify when an imported identifier isn’t needed any more and can be removed. Implicit/wildcard import mechanisms don’t easily allow for this.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-24 08:50 +0000 |
| Message-ID | <1192o91$cnuj$1@paganini.bofh.team> |
| In reply to | #402347 |
bart <bc@freeuk.com> wrote:
>
> Perhaps we should also be able to individually enable 'if', 'for'
> 'while' etc as needed!
Sure. In Common Lisp symbols like 'IF' have their builtin meaning
only when they came from "COMMON-LISP" package. Other packages
can import them (it is usual to import all "COMMON-LISP" symbols).
But, if needed, one can also give them another meaning.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-24 11:31 +0200 |
| Message-ID | <1192qm0$2aem3$1@dont-email.me> |
| In reply to | #402352 |
On 2026-09-24 10:50, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> >> Perhaps we should also be able to individually enable 'if', 'for' >> 'while' etc as needed! What a stupid suggestion! Janis > > Sure. In Common Lisp symbols like 'IF' have their builtin meaning > only when they came from "COMMON-LISP" package. Other packages > can import them (it is usual to import all "COMMON-LISP" symbols). > But, if needed, one can also give them another meaning. >
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-24 11:29 +0100 |
| Message-ID | <1192u1k$2ja5g$2@dont-email.me> |
| In reply to | #402353 |
On 24/09/2026 10:31, Janis Papanagnou wrote: > On 2026-09-24 10:50, Waldek Hebisch wrote: >> bart <bc@freeuk.com> wrote: >>> >>> Perhaps we should also be able to individually enable 'if', 'for' >>> 'while' etc as needed! > > What a stupid suggestion! >> >> Sure. In Common Lisp symbols like 'IF' have their builtin meaning >> only when they came from "COMMON-LISP" package. Other packages >> can import them (it is usual to import all "COMMON-LISP" symbols). >> But, if needed, one can also give them another meaning. >> So Common Lisp is stupid? But you also seem to be missing my point.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-25 21:09 +0000 |
| Message-ID | <1196nv5$p698$1@paganini.bofh.team> |
| In reply to | #402355 |
bart <bc@freeuk.com> wrote:
> On 24/09/2026 10:31, Janis Papanagnou wrote:
>> On 2026-09-24 10:50, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>>
>>>> Perhaps we should also be able to individually enable 'if', 'for'
>>>> 'while' etc as needed!
>>
>> What a stupid suggestion!
>
>>>
>>> Sure. In Common Lisp symbols like 'IF' have their builtin meaning
>>> only when they came from "COMMON-LISP" package. Other packages
>>> can import them (it is usual to import all "COMMON-LISP" symbols).
>>> But, if needed, one can also give them another meaning.
>>>
>
>
> So Common Lisp is stupid?
>
> But you also seem to be missing my point.
Common Lisp ability to control visibility of 'IF' comes from general
principles of Lisp. _Not_ having it would require extra effort.
Ability to replace system 'IF' by user provided one has some uses.
Imagine that you want to collect same statistics about runtime
behaviour of your program. User defined 'IF' can update statistics
and after that do the same thing as system 'IF'. In other words
user can add essentially arbitrary instrumentation the program.
In C compiler like gcc you can ask compiler to add instrumentation,
which works for commonly needed things, but AFAICS things get
somewhere between hairy and impossible if you have nostandard
needs (IIUC gcc now supports plugins and they can do amazing
things, so if custom plugin can handle this, then it is just
hairy).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-26 11:59 +0100 |
| Message-ID | <11988i9$dmij$1@dont-email.me> |
| In reply to | #402397 |
On 25/09/2026 22:09, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 24/09/2026 10:31, Janis Papanagnou wrote:
>>> On 2026-09-24 10:50, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
>>>>>
>>>>> Perhaps we should also be able to individually enable 'if', 'for'
>>>>> 'while' etc as needed!
>>>
>>> What a stupid suggestion!
>>
>>>>
>>>> Sure. In Common Lisp symbols like 'IF' have their builtin meaning
>>>> only when they came from "COMMON-LISP" package. Other packages
>>>> can import them (it is usual to import all "COMMON-LISP" symbols).
>>>> But, if needed, one can also give them another meaning.
>>>>
>>
>>
>> So Common Lisp is stupid?
>>
>> But you also seem to be missing my point.
>
> Common Lisp ability to control visibility of 'IF' comes from general
> principles of Lisp. _Not_ having it would require extra effort.
You mean, like having real syntax and proper reserved words?
This is 'extra' effort that even simple BASICs seems to manage!
> Ability to replace system 'IF' by user provided one has some uses.
> Imagine that you want to collect same statistics about runtime
> behaviour of your program. User defined 'IF' can update statistics
> and after that do the same thing as system 'IF'. In other words
> user can add essentially arbitrary instrumentation the program.
> In C compiler like gcc you can ask compiler to add instrumentation,
> which works for commonly needed things, but AFAICS things get
> somewhere between hairy and impossible if you have nostandard
> needs (IIUC gcc now supports plugins and they can do amazing
> things, so if custom plugin can handle this, then it is just
> hairy).
>
If sounds like you are thinking up possible uses to fit around this
peculiar feature.
To me 'instrumentation' like this ('profiling'?) shouldn't impact on the
language design, and should be more up to the implementation to provide.
So a compiler for example can apply it to its ordinary IF statements.
CLisp happens to work like that anyway, but you wouldn't compromise the
design of a more conventional language to make it possible.
For example, implementing IF, FOR etc like user-functions would require
advanced, inefficient features such as closures, and likely need special
syntax.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-29 04:06 +0000 |
| Message-ID | <119fdg2$1t9vh$1@paganini.bofh.team> |
| In reply to | #402405 |
bart <bc@freeuk.com> wrote:
> On 25/09/2026 22:09, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 24/09/2026 10:31, Janis Papanagnou wrote:
>>>> On 2026-09-24 10:50, Waldek Hebisch wrote:
>>>>> bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>> Perhaps we should also be able to individually enable 'if', 'for'
>>>>>> 'while' etc as needed!
>>>>
>>>> What a stupid suggestion!
>>>
>>>>>
>>>>> Sure. In Common Lisp symbols like 'IF' have their builtin meaning
>>>>> only when they came from "COMMON-LISP" package. Other packages
>>>>> can import them (it is usual to import all "COMMON-LISP" symbols).
>>>>> But, if needed, one can also give them another meaning.
>>>>>
>>>
>>>
>>> So Common Lisp is stupid?
>>>
>>> But you also seem to be missing my point.
>>
>> Common Lisp ability to control visibility of 'IF' comes from general
>> principles of Lisp. _Not_ having it would require extra effort.
>
> You mean, like having real syntax and proper reserved words?
>
> This is 'extra' effort that even simple BASICs seems to manage!
Having reserved words is a drawback. Basically reserved words
are tolerated because good alternatives require effort and are
little known (PL/I is known to many folks, but it has its
problems).
Lisp made a tradeof to make some things easy at the cost of
syntax. But alternative approaches are possible. Dylan has
many of Lisp features, but traditional systax. Seed7 also
seem to have capabilities in this direction (but I did not
look deeper, so I may be wrong). Approach below is rather
different from Lisp and Dylan.
>> Ability to replace system 'IF' by user provided one has some uses.
>> Imagine that you want to collect same statistics about runtime
>> behaviour of your program. User defined 'IF' can update statistics
>> and after that do the same thing as system 'IF'. In other words
>> user can add essentially arbitrary instrumentation the program.
>> In C compiler like gcc you can ask compiler to add instrumentation,
>> which works for commonly needed things, but AFAICS things get
>> somewhere between hairy and impossible if you have nostandard
>> needs (IIUC gcc now supports plugins and they can do amazing
>> things, so if custom plugin can handle this, then it is just
>> hairy).
>>
>
> If sounds like you are thinking up possible uses to fit around this
> peculiar feature.
>
> To me 'instrumentation' like this ('profiling'?) shouldn't impact on the
> language design, and should be more up to the implementation to provide.
>
> So a compiler for example can apply it to its ordinary IF statements.
>
> CLisp happens to work like that anyway, but you wouldn't compromise the
> design of a more conventional language to make it possible.
>
> For example, implementing IF, FOR etc like user-functions would require
> advanced, inefficient features such as closures, and likely need special
> syntax.
No. All you need are hooks into compiler. First, silly example
of 'if' (illustrating how builtin 'if' works):
if 1 < 2 then "OK" endif =>
** OK
That is the statement above is compiled and then executed. printing
OK.
Now we do:
vars save_if = valof("if");
syscancel("if");
After that builtin 'if' no longer works, it behaves as undefined
variable. So we provide new definition:
define syntax if;
printf('doing my if\n');
chain(save_if);
enddefine;
Now, we get:
if 1 < 2 then "OK" endif =>
doing my if
** OK
That is compilation of the statement invokes procedure for 'if'
and as first action this procedure prints the message. 'chain'
passes control to procedure stored in 'save_if', which is
procedure associated with buitin 'if'. This is small example
so I used statement that is immediately executed. In more
compilicated example I could define a procedure. Then it would
be clear that message is produced at compile time and at
run time procedure runs the same as using
General picture above is the following. Evaluation uses stack
model. In the first stage compiler turns its input into tokens.
This is done by calling appropriate procedure variable (which is
user assignable, but system provides default value). Next, compiler
looks at first token and determines what it is. Constants and
variables are compiled just to produce values on the stack.
Other items need associated syntax property or procedure. When
syntax procedure is present, then compiler calls it. When
syntax property says the item is an operator, then compiler
compile the second argument (the first should be already
compiled) and then compiles call to associated procedure
(which expects both its arguments on the stack).
There are conventions how various syntax procedures cooperate.
I took a shortcut by reusing system procedure, otherwise I would
have to be careful to stick to compiler conventions.
If you are concerned with overeads, then there are some. First
compiler procedures have to be called via procedure variables,
which adds indirection step to corresponding calls (seem to
be 1 clock on modern machines). Stack model if used naively
would generate a lot of stack accesses, but there is an optimizer
which tries to eliminate stack access and directly provide
arguments to operations. All operations (like '+') officially
execute via function call, but known simple operations
are expanded inline. In effect, code written in low level
style and compiled with safety features turned off can run
reasonably fast (somewhat slower than C, but not too much).
Higher level code is significantly slower, mainly due to
many dynamic checks and doing things via function calls.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-29 04:47 +0000 |
| Message-ID | <119fftd$2v7cp$2@dont-email.me> |
| In reply to | #402490 |
On Tue, 29 Sep 2026 04:06:28 -0000 (UTC), Waldek Hebisch wrote: > Having reserved words is a drawback. Basically reserved words are > tolerated because good alternatives require effort and are little > known (PL/I is known to many folks, but it has its problems). PL/I ostensibly followed in the FORTRAN tradition of having no reserved words at all. And then it introduced those digraph equivalents to the comparison operators -- and those are reserved words. So PL/I actually has 6 reserved words. FORTRAN still keeps the tradition of having no reserved words. But it has now given up the idea of whitespace being insignificant. Algol 68 introduced the concept of a separate “bold” alphabet for expressing reserved words, and type names (“modes”, it calls them). This way it avoids reserved words interfering in any way with identifiers in the non-bold alphabet, at least. Whitespace is also insignificant in the latter, but significant in the former. > Lisp made a tradeof to make some things easy at the cost of syntax. > But alternative approaches are possible. There is a language which actually has even less syntax than Lisp, while still remaining homoiconic, and that is PostScript. Lisp has “special forms”, which in turn lead to the need for a (quite good) comprehensive macro system. PostScript has no “special forms”, so it doesn’t actually need a macro system.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-29 23:49 +0100 |
| Message-ID | <119hf9m$3npnc$1@dont-email.me> |
| In reply to | #402490 |
On 29/09/2026 05:06, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>>> Common Lisp ability to control visibility of 'IF' comes from general
>>> principles of Lisp. _Not_ having it would require extra effort.
>>
>> You mean, like having real syntax and proper reserved words?
>>
>> This is 'extra' effort that even simple BASICs seems to manage!
>
> Having reserved words is a drawback. Basically reserved words
> are tolerated because good alternatives require effort and are
> little known (PL/I is known to many folks, but it has its
> problems).
Why is it a drawback? The reserved words are known so you know to avoid
them.
If porting code form another languages where some identifiers clash with
your keywords (or where it relies on case sensitivity to distinguish
'abc' from 'Abc') then there are workarounds.
> Lisp made a tradeof to make some things easy at the cost of
> syntax. But alternative approaches are possible. Dylan has
> many of Lisp features, but traditional systax. Seed7 also
> seem to have capabilities in this direction (but I did not
> look deeper, so I may be wrong). Approach below is rather
> different from Lisp and Dylan.
>
>>> Ability to replace system 'IF' by user provided one has some uses.
>>> Imagine that you want to collect same statistics about runtime
>>> behaviour of your program. User defined 'IF' can update statistics
>>> and after that do the same thing as system 'IF'. In other words
>>> user can add essentially arbitrary instrumentation the program.
>>> In C compiler like gcc you can ask compiler to add instrumentation,
>>> which works for commonly needed things, but AFAICS things get
>>> somewhere between hairy and impossible if you have nostandard
>>> needs (IIUC gcc now supports plugins and they can do amazing
>>> things, so if custom plugin can handle this, then it is just
>>> hairy).
>>>
>>
>> If sounds like you are thinking up possible uses to fit around this
>> peculiar feature.
>>
>> To me 'instrumentation' like this ('profiling'?) shouldn't impact on the
>> language design, and should be more up to the implementation to provide.
>>
>> So a compiler for example can apply it to its ordinary IF statements.
>>
>> CLisp happens to work like that anyway, but you wouldn't compromise the
>> design of a more conventional language to make it possible.
>>
>> For example, implementing IF, FOR etc like user-functions would require
>> advanced, inefficient features such as closures, and likely need special
>> syntax.
>
> No. All you need are hooks into compiler. First, silly example
> of 'if' (illustrating how builtin 'if' works):
>
> if 1 < 2 then "OK" endif =>
> ** OK
>
> That is the statement above is compiled and then executed. printing
> OK.
>
> Now we do:
>
> vars save_if = valof("if");
> syscancel("if");
>
> After that builtin 'if' no longer works, it behaves as undefined
> variable. So we provide new definition:
>
> define syntax if;
> printf('doing my if\n');
> chain(save_if);
> enddefine;
>
> Now, we get:
>
> if 1 < 2 then "OK" endif =>
> doing my if
> ** OK
Is this some sort of Forth?
And what is this last 'if 1 < 2 then "OK" endif' now equivalent to, is it:
printf('doing my if\n');
if 1 < 2 then "OK" endif # standard meaning of 'if'
or:
F() # does 'printf('doing my if\n'');
if 1 < 2 then "OK" endif # standard meaning of 'if'
(Probably the latter is better as then it is clear when the scope of
that printf line is.)
In either case, this looks more like that something that is the
compiler's job rather than language, with 'define', 'valof' and so on
being directives.
(I had something like this for functions, so that I could log each call.
But it was program-wide and taken care of within the compiler, so source
code of test programs was not affected. The logging code was also within
the compiler source.)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-09-30 12:19 +0000 |
| Message-ID | <119iuo8$28esl$1@paganini.bofh.team> |
| In reply to | #402518 |
bart <bc@freeuk.com> wrote:
> On 29/09/2026 05:06, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
<snip>
>
>> Lisp made a tradeof to make some things easy at the cost of
>> syntax. But alternative approaches are possible. Dylan has
>> many of Lisp features, but traditional systax. Seed7 also
>> seem to have capabilities in this direction (but I did not
>> look deeper, so I may be wrong). Approach below is rather
>> different from Lisp and Dylan.
>>
<snip>
>>> For example, implementing IF, FOR etc like user-functions would require
>>> advanced, inefficient features such as closures, and likely need special
>>> syntax.
>>
>> No. All you need are hooks into compiler. First, silly example
>> of 'if' (illustrating how builtin 'if' works):
>>
>> if 1 < 2 then "OK" endif =>
>> ** OK
>>
>> That is the statement above is compiled and then executed. printing
>> OK.
>>
>> Now we do:
>>
>> vars save_if = valof("if");
>> syscancel("if");
>>
>> After that builtin 'if' no longer works, it behaves as undefined
>> variable. So we provide new definition:
>>
>> define syntax if;
>> printf('doing my if\n');
>> chain(save_if);
>> enddefine;
>>
>> Now, we get:
>>
>> if 1 < 2 then "OK" endif =>
>> doing my if
>> ** OK
>
> Is this some sort of Forth?
Really no.
> And what is this last 'if 1 < 2 then "OK" endif' now equivalent to, is it:
>
> printf('doing my if\n');
> if 1 < 2 then "OK" endif # standard meaning of 'if'
>
> or:
>
> F() # does 'printf('doing my if\n'');
> if 1 < 2 then "OK" endif # standard meaning of 'if'
>
> (Probably the latter is better as then it is clear when the scope of
> that printf line is.)
As I wrote, printout is at compile time, runtime behaviour is
unchanged.
Maybe below is clearer:
define foo(); if 1 < 2 then "OK" endif; enddefine;
produces:
doing my if
Running 'foo' as:
foo() =>
produces
** OK
just as with ordinary 'if'.
> In either case, this looks more like that something that is the
> compiler's job rather than language, with 'define', 'valof' and so on
> being directives.
First, 'define' is part of normal user syntax. Second, once you
can change compiler table of keywords in a library function,
distinction between core language and library becomes rather
fuzzy. Third, to be used such facilites must be official,
that is de facto part of the language.
Anyway, I do not claim that this approach is better than what
Lisp is doing. The point is that there are various possiblities.
Lisp decided to use extremaly simplified mapping from text to
parse trees and allow arbitrary transformation of the parse tree.
Above there is syntax and user can substantially change the syntax
and add extentions. This works reasonably well because in this
language syntax is combination of recursive descent and operator
precedence. Also, core syntax is rather verbose requiring
openers and closers. With denser syntax it may be hard to
find good place for syntax extentions.
Ability to change buit-in constructs is related to ability to
add extentions. Namely, for exentions compiler needs to looks
for meaning in its symbol table. Once you allow special meaning
for user constructs, it is natural to put _all_ language construct
in the symbol table and exclusively depend on this (as opposed
say to attaching compiler actions to productions in the grammar).
> (I had something like this for functions, so that I could log each call.
> But it was program-wide and taken care of within the compiler, so source
> code of test programs was not affected. The logging code was also within
> the compiler source.)
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 10:13 +0200 |
| Message-ID | <117r4ek$3r5qn$4@dont-email.me> |
| In reply to | #401719 |
On 2026-09-08 13:47, bart wrote: > On 08/09/2026 01:02, Waldek Hebisch wrote: >> [...] > [...] > > Still, modern languages tend to have a module scheme, suggesting the > 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough. A necessary consequence of the growing systems and software architectures. But even some legacy languages had already modularization concepts back then! So it's not an excuse to provide only a primitive #include mechanism. But I wouldn't be so critical given the time when "C" had been designed. You should take into account C's design-principles and also when it came out and sort them in, in comparison to other language schools; compare (for example) the release dates of Pascal -> Modula (and what these two provided here). Janis
[toc] | [prev] | [next] | [standalone]
Page 22 of 25 — ← Prev page 1 … 20 21 [22] 23 24 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web