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 3 of 25 — ← Prev page 1 2 [3] 4 5 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-10 09:07 +0200 |
| Message-ID | <117tkvc$1o1jf$2@dont-email.me> |
| In reply to | #401839 |
On 09/09/2026 22:39, bart wrote: > On 09/09/2026 20:39, David Brown wrote: >> On 09/09/2026 19:34, bart wrote: > >>> You see the same thing [with] assemblers. There, there is no backend >>> optimising of the kind that compilers do. Assembling is a simple, >>> linear process. >>> >>> And yet, you can see 10:1 difference in assembling the same program. >>> What on earth are those slow ones up to? >>> >> >> It's not hard to make programs that are slow for a particular task. >> Once you have reached a certain point, however, it's far harder to >> make them much faster. I believe there was a mainstream assembler >> that had a particularly poor algorithm somewhere, resulting in >> surprisingly long run times once input was over a certain size. I >> don't imagine it is a general problem, however. > > NASM, MASM, or both? > Having never had use for any assembler on x86, I don't know - it's just something I remember hearing about. From your numbers, it's probably the nasm bug. > I know there is a long standing bug in NASM which leads to result like > these, for this 270Kloc input (actually, an SQL test compiled into three > different x64 ASM formats): > > nasm -O0 -fwin64 250 seconds (to .obj) > yasm -fwin64 1.06 seconds (to .obj) > as 0.65 seconds (to .o) > aa 0.10 seconds (to .exe) > > Obviously, 'aa' is my product. And clearly, NASM has something wrong. > (Without -O0, it would be 60% slower!) > > MASM (as 'ml64.exe') had its own bug to do with using RESB in a .DATA > segment; it got exponentially slower with the size of the block. (I no > longer have it to test.) > > For whole-program compilers that generate a single ASM file, assembly > speed is critical. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-09 14:41 -0700 |
| Message-ID | <117sjr3$1g635$1@kst.eternal-september.org> |
| In reply to | #401827 |
bart <bc@freeuk.com> writes:
[...]
> Tiny C *does* seem to do the same task (parse huge amounts of
> declarations) at least a magnitude faster than TCC. TCC wouldn't need
> those extra cores. Maybe gcc wouldn't either.
[...]
Aren't Tiny C and TCC the same thing? Did you mean "at least a
magnitude faster than gcc"?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-09 23:31 +0100 |
| Message-ID | <117smnt$1hgkq$2@dont-email.me> |
| In reply to | #401844 |
On 09/09/2026 22:41, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> Tiny C *does* seem to do the same task (parse huge amounts of >> declarations) at least a magnitude faster than TCC. TCC wouldn't need >> those extra cores. Maybe gcc wouldn't either. > [...] > > Aren't Tiny C and TCC the same thing? Did you mean "at least a > magnitude faster than gcc"? > Yes.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-09 15:10 +0000 |
| Message-ID | <OFeoS.17$hJp8.5@fx41.iad> |
| In reply to | #401763 |
David Brown <david.brown@hesbynett.no> writes: >On 08/09/2026 21:08, bart wrote: >> On 08/09/2026 17:40, Scott Lurndal wrote: >4. Modern development is done with build systems - make, cmake, ninja, >bazel, whatever. The real work is done in parallel, making good use of >the multi-core machine. This also exasperates OS limitations - now >instead of dealing with a thousand file reads and a dozen processes for >one compilation, you are doing that twenty times in parallel. On *nix >systems, that's effortless - Windows has far more bottlenecks. And if >you have some kind of on-access anti-virus software running on the >Windows system, that can cripple performance. Indeed. Using a parallel make (-j 96), I can clone the repo and build it in only 8 minutes. A sequential make takes over three hours. Modifying and changing a single source file recompiles and links in few seconds (with a couple outliers, one that takes 6 minutes with -O3 vs. 15 seconds without optimization). <snip>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-08 09:25 +0200 |
| Message-ID | <117od92$3ui33$1@dont-email.me> |
| In reply to | #401697 |
On 08/09/2026 00:50, Janis Papanagnou wrote:
>
> It's even worse; given - as mentioned in another part of the thread -
> that #includes are costly we often find some means to avoid not only
> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
> in the header files but also to prevent accessing the header file in
> the first place (by #ifndef LABEL, #include <label.h>, #endif). That
> makes such C/C++ code rather messy, IMO. (And makes one appreciate
> languages with an inherent good modularization method yet more.)
>
It is almost universal practice to have such include guards in header
files. ("#pragma once" is also often used, but while most compilers
support it, it is not standard and it can be problematic in some
circumstances.) The norm is to have the include guard cover everything
except perhaps some comments at the head of the file, and compilers have
fast paths to handle such discarded includes very efficiently.
So I would not count include guards as a problem in C - think of it more
as a quirky syntax for how header files are written. Where other
languages might have "interface module XXX;", C has "#ifndef __XXX__".
Still, there can be problems when someone does not follow the common
practice here.
It is also inconvenient when a programmer fails to include sub-includes
that are needed, so that the person using the header has to figure out a
correct order and manually add any required include files.
C's include system is not hard to use well, but it is certainly possible
to use it badly and cause inconvenience to others.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 09:59 +0200 |
| Message-ID | <117r3k7$3r5qo$4@dont-email.me> |
| In reply to | #401709 |
On 2026-09-08 09:25, David Brown wrote:
> On 08/09/2026 00:50, Janis Papanagnou wrote:
>>
>> It's even worse; given - as mentioned in another part of the thread -
>> that #includes are costly we often find some means to avoid not only
>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
>> in the header files but also to prevent accessing the header file in
>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That
>> makes such C/C++ code rather messy, IMO. (And makes one appreciate
>> languages with an inherent good modularization method yet more.)
>>
> It is almost universal practice to have such include guards in header
> files.
Yeah, that was also my suspicion. (Though I'm not any more practically
involved in professional C/C++ development so I'm not really up to date
what additional options we nowadays have.)
> ("#pragma once" is also often used, but while most compilers
> support it, it is not standard and it can be problematic in some
> circumstances.) The norm is to have the include guard cover everything
> except perhaps some comments at the head of the file, and compilers have
> fast paths to handle such discarded includes very efficiently.
>
> So I would not count include guards as a problem in C - think of it more
> as a quirky syntax for how header files are written.
Well, I wouldn't actually call it a "problem". - I mean, it's "C" we're
talking about. :-)
Yes, the syntax (and all the overhead) is what I find annoying. (But
I'm used to it, and it's also not worth complaining. It's effective.)
> Where other
> languages might have "interface module XXX;", C has "#ifndef __XXX__".
I'm not feeling competent enough concerning "the best" module interface
methods and their discussion, but I've met a handful languages/methods
during my IT life and the C/C++ "model" is rather at the low end. (But
I've also programmed in languages that didn't have any module-concept
at all. - We've to use what we are supposed to work with.)
>
> Still, there can be problems when someone does not follow the common
> practice here.
We defined our company (coding-)standards to cover that. (And had our
technical mechanisms to alleviate the burden of the textual overhead.)
>
> It is also inconvenient when a programmer fails to include sub-includes
> that are needed, so that the person using the header has to figure out a
> correct order and manually add any required include files.
Hmm.. - I'm not sure I can follow you here. - If some of our headers
had its own dependencies it was the responsibility of that header to
satisfy them. - I recall there were occasionally issues with lacking
consistency, but that was in our project contexts considered a bug.
>
> C's include system is not hard to use well, but it is certainly possible
> to use it badly and cause inconvenience to others.
Yes. It's primitive. It does its job. And you should accompany their
use by standards and conventions.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 10:35 +0200 |
| Message-ID | <117r5p8$s9ir$2@dont-email.me> |
| In reply to | #401761 |
On 09/09/2026 09:59, Janis Papanagnou wrote:
> On 2026-09-08 09:25, David Brown wrote:
>> On 08/09/2026 00:50, Janis Papanagnou wrote:
>>>
>>> It's even worse; given - as mentioned in another part of the thread -
>>> that #includes are costly we often find some means to avoid not only
>>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
>>> in the header files but also to prevent accessing the header file in
>>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That
>>> makes such C/C++ code rather messy, IMO. (And makes one appreciate
>>> languages with an inherent good modularization method yet more.)
>>>
>> It is almost universal practice to have such include guards in header
>> files.
>
> Yeah, that was also my suspicion. (Though I'm not any more practically
> involved in professional C/C++ development so I'm not really up to date
> what additional options we nowadays have.)
>
>> ("#pragma once" is also often used, but while most compilers support
>> it, it is not standard and it can be problematic in some
>> circumstances.) The norm is to have the include guard cover
>> everything except perhaps some comments at the head of the file, and
>> compilers have fast paths to handle such discarded includes very
>> efficiently.
>>
>> So I would not count include guards as a problem in C - think of it
>> more as a quirky syntax for how header files are written.
>
> Well, I wouldn't actually call it a "problem". - I mean, it's "C" we're
> talking about. :-)
>
> Yes, the syntax (and all the overhead) is what I find annoying. (But
> I'm used to it, and it's also not worth complaining. It's effective.)
>
>> Where other languages might have "interface module XXX;", C has
>> "#ifndef __XXX__".
>
> I'm not feeling competent enough concerning "the best" module interface
> methods and their discussion, but I've met a handful languages/methods
> during my IT life and the C/C++ "model" is rather at the low end. (But
> I've also programmed in languages that didn't have any module-concept
> at all. - We've to use what we are supposed to work with.)
>
There's no doubt that the C and C++ (prior to modules in C++20) headers
are quite a primitive, low-level mechanism. They are very flexible, and
can be used for much more than a clear, rigid module system - but with
that flexibility to do weird and wonderful things comes the flexibility
to do strange, confusing, inefficient or simple incorrect things. The
same principle applies to the text-based macros of the C pre-processor.
It requires discipline and convention to use well.
And that flexibility also leads to disadvantages when trying to change
or improve things - any new solution still has to work with code that
includes the same file multiple times intentionally (such as for
so-called "x-macros"), or has headers whose functionality depends on
macro definitions before inclusion, and so on.
Basically, if you are making a new language, you should include some
kind of module system that is better than C has - but it is impractical
to try to change C now. (Maybe C could later copy modules from C++,
once there has been enough practical experience built up around them.
But it would first have to copy namespaces.)
>>
>> Still, there can be problems when someone does not follow the common
>> practice here.
>
> We defined our company (coding-)standards to cover that. (And had our
> technical mechanisms to alleviate the burden of the textual overhead.)
>
Most serious developers use some kind of IDE or advanced editor, and
most such tools can generate include guards automatically when you
create a new header file.
>>
>> It is also inconvenient when a programmer fails to include sub-
>> includes that are needed, so that the person using the header has to
>> figure out a correct order and manually add any required include files.
>
> Hmm.. - I'm not sure I can follow you here. - If some of our headers
> had its own dependencies it was the responsibility of that header to
> satisfy them. - I recall there were occasionally issues with lacking
> consistency, but that was in our project contexts considered a bug.
>
I follow that principle too. But not everyone does. So I would have :
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
#include <stdint.h>
extern uint64_t make_a_big_number(void);
#endif // #ifndef __NUMBER_GENERATOR_H__
But some people would omit the "#include <stdint.h>" line, and leave
that as the responsibility of the person writing the C file. The same
applies to dependencies on local header files.
>>
>> C's include system is not hard to use well, but it is certainly
>> possible to use it badly and cause inconvenience to others.
>
> Yes. It's primitive. It does its job. And you should accompany their
> use by standards and conventions.
>
Agreed.
(Of course that applies to a lot of aspects of C. It's a language that
requires more programmer responsibility than some other languages where
the tools can do more checks at compile-time, or you have more checks at
run-time.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-09 11:35 +0200 |
| Message-ID | <117r98e$3r5qn$6@dont-email.me> |
| In reply to | #401766 |
On 2026-09-09 10:35, David Brown wrote: > On 09/09/2026 09:59, Janis Papanagnou wrote: >> >> We defined our company (coding-)standards to cover that. (And had our >> technical mechanisms to alleviate the burden of the textual overhead.) > > Most serious developers use some kind of IDE or advanced editor, and > most such tools can generate include guards automatically when you > create a new header file. Yes, that was what I've meant and what we've done. In addition we provided templates, and there were external (non-editor-dependent) generators to quickly create source frames for .h and .cc files; specifically for C++ that was very useful and saved a lot of time since we also generated standard class contents, standard headers, comment frames, c'tors, d'tors, copy-c'tors, =ops, and maybe some more things. >> [...] > > I follow that principle too. But not everyone does. So I would have : > > #ifndef __NUMBER_GENERATOR_H__ > #define __NUMBER_GENERATOR_H__ 1 BTW, since I'm seeing that... I recall we've had defined these without value assignment just as #define __NUMBER_GENERATOR_H__ and I seem to recall we've determined that this would suffice and verified to create no problems. - Is that still valid? (And if so, what's the purpose of the value then?) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 14:43 +0200 |
| Message-ID | <117rk9n$s9ir$8@dont-email.me> |
| In reply to | #401772 |
On 09/09/2026 11:35, Janis Papanagnou wrote: > On 2026-09-09 10:35, David Brown wrote: >> On 09/09/2026 09:59, Janis Papanagnou wrote: >>> >>> We defined our company (coding-)standards to cover that. (And had our >>> technical mechanisms to alleviate the burden of the textual overhead.) >> >> Most serious developers use some kind of IDE or advanced editor, and >> most such tools can generate include guards automatically when you >> create a new header file. > > Yes, that was what I've meant and what we've done. In addition we > provided templates, and there were external (non-editor-dependent) > generators to quickly create source frames for .h and .cc files; > specifically for C++ that was very useful and saved a lot of time > since we also generated standard class contents, standard headers, > comment frames, c'tors, d'tors, copy-c'tors, =ops, and maybe some > more things. > >>> [...] >> >> I follow that principle too. But not everyone does. So I would have : >> >> #ifndef __NUMBER_GENERATOR_H__ >> #define __NUMBER_GENERATOR_H__ 1 > > BTW, since I'm seeing that... > > I recall we've had defined these without value assignment just as > > #define __NUMBER_GENERATOR_H__ > > and I seem to recall we've determined that this would suffice and > verified to create no problems. - Is that still valid? (And if so, > what's the purpose of the value then?) > > Janis > Just defining the symbol is fine - for use as a pure header guard, where the check is with "#ifndef" or "#ifdef", defining it to a value has no added value. Adding the "1" in that example was done without thinking.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-09-10 14:08 -0700 |
| Message-ID | <117v67i$2b9nt$1@dont-email.me> |
| In reply to | #401790 |
On 9/9/2026 5:43 AM, David Brown wrote: [...] > Just defining the symbol is fine - for use as a pure header guard, where > the check is with "#ifndef" or "#ifdef", defining it to a value has no > added value. Adding the "1" in that example was done without thinking. > ________ #ifndef __NUMBER_GENERATOR_H__ #define __NUMBER_GENERATOR_H__ 1 ________ Is that __* non conformant? Does it breach the impl name prefix space?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-09-10 14:14 -0700 |
| Message-ID | <117v6k4$2bl1q$1@dont-email.me> |
| In reply to | #401913 |
On 9/10/2026 2:08 PM, Chris M. Thomasson wrote:
> On 9/9/2026 5:43 AM, David Brown wrote:
> [...]
>> Just defining the symbol is fine - for use as a pure header guard,
>> where the check is with "#ifndef" or "#ifdef", defining it to a value
>> has no added value. Adding the "1" in that example was done without
>> thinking.
>>
> ________
> #ifndef __NUMBER_GENERATOR_H__
> #define __NUMBER_GENERATOR_H__ 1
> ________
>
>
> Is that __* non conformant? Does it breach the impl name prefix space?
Fwiw, my old code before I got hooked on #pragma once basically followed
this pattern:
/* Copyright 2005 Chris Thomasson */
#ifndef AC_BASE_H
#define AC_BASE_H
#ifdef __cplusplus
extern "C"
{
#endif
/* attempt to determine the os type */
#if defined ( linux ) || \
defined ( __linux ) || \
defined ( AC_BUILD_OS_FORCE_LINUX32 )
#define AC_BUILD_OS_PTHREADS
#define AC_BUILD_OS_LINUX
#elif defined ( _WIN32 ) || \
defined ( __TOS_WIN__ ) || \
defined ( __WIN32__ ) || \
defined ( WIN32 ) || \
defined ( WIN64 ) || \
defined ( _WIN32_WCE ) || \
defined ( AC_BUILD_OS_FORCE_WIN32 ) || \
defined ( AC_BUILD_OS_FORCE_WINCE )
#if defined ( _WIN32_WCE ) || \
defined ( AC_BUILD_OS_FORCE_WINCE )
#define AC_BUILD_OS_WINDOWS_CE
#endif
#define AC_BUILD_OS_WINDOWS
#ifdef WIN64
#define AC_BUILD_OS_64_BIT
#endif
#elif defined ( AC_BUILD_OS_FORCE_PTHREAD )
#define AC_BUILD_OS_PTHREADS
#else
#error AC_BUILD_OS - Windows or PThreads OS required!
#endif
/* attempt to determine the cpu type */
#if defined ( _M_IX86 ) || \
defined ( i386 ) || \
defined ( __i386__ ) || \
defined ( _X86_ ) || \
defined ( AC_BUILD_CPU_FORCE_I686 )
# define AC_CPU_X86
# define AC_BUILD_32BIT
# if defined ( AC_BUILD_OS_WINDOWS_CE ) || \
defined ( AC_BUILD_CPU_FORCE_WINDOWS )
# define AC_BUILD_CPU_WINDOWS
#else
# define AC_BUILD_CPU_I686
#endif
#elif defined ( _WIN32_WCE ) || \
defined ( AC_BUILD_CPU_FORCE_WINDOWS )
# define AC_BUILD_32BIT
# define AC_BUILD_CPU_WINDOWS
#else
# error AC_BUILD_CPU - x86-32 or Windows required!
#endif
/***** Simple Compiler Abstraction *****/
#ifdef _MSC_VER
/* 4514: unreferenced inline function has been removed
4710: function 'whatever' not inlined */
# pragma warning ( disable : 4514 4710 )
# define AC_INLINE_FORCE __forceinline
# define AC_INLINE __inline
# define AC_DECLSPEC_CALL_CDECL __cdecl
# define AC_DECLSPEC_CALL_FAST_CALL __fastcall
# define AC_DECLSPEC_CALL_STDCALL __stdcall
# define AC_DECLSPEC_ALIGN( a ) __declspec ( align( a ) )
# define AC_DECLSPEC_PACKED
# define AC_DECLSPEC_MALLOC
# define AC_DECLSPEC_UNUSED
# define AC_DECLSPEC_NORET
# if defined ( AC_BUILD_OS_UNDER_WINDOWS ) || \
defined ( AC_BUILD_OS_WINDOWS )
# define AC_DECLSPEC_API_IMPORT __declspec ( dllimport )
# define AC_DECLSPEC_API_EXPORT __declspec ( dllexport )
# endif
#elif defined ( __GNUC__ )
# define AC_INLINE_FORCE __attribute__ ( (always_inline) )
# define AC_INLINE __inline__
# ifdef AC_BUILD_CPU_I686
# if defined ( AC_BUILD_OS_UNDER_WINDOWS ) || \
defined ( AC_BUILD_OS_WINDOWS ) \
# define AC_DECLSPEC_CALL_CDECL __attribute__ ( (cdecl) )
# define AC_DECLSPEC_CALL_FAST_CALL __attribute__ ( (fastcall) )
# define AC_DECLSPEC_CALL_STDCALL __attribute__ ( (stdcall) )
# else
# define AC_DECLSPEC_CALL_CDECL
# define AC_DECLSPEC_CALL_FAST_CALL
# define AC_DECLSPEC_CALL_STDCALL
# endif
# endif
# define AC_DECLSPEC_ALIGN( a ) __attribute__ ( (aligned( a )) )
# define AC_DECLSPEC_PACKED __attribute__ ( (packed) )
# define AC_DECLSPEC_MALLOC __attribute__ ( (malloc) )
# define AC_DECLSPEC_UNUSED __attribute__ ( (unused) )
# define AC_DECLSPEC_NORET __attribute__ ( (noreturn) )
# if defined ( AC_BUILD_OS_UNDER_WINDOWS ) || \
defined ( AC_BUILD_OS_WINDOWS )\
# define AC_DECLSPEC_API_IMPORT __attribute__ ( (dllimport) )
# define AC_DECLSPEC_API_EXPORT __attribute__ ( (dllexport) )
# else
# define AC_DECLSPEC_CTOR __attribute__ ( (constructor) )
# define AC_DECLSPEC_DTOR __attribute__ ( (destructor) )
# endif
#else
# error AC_BUILD: MSVC++(6.0+) or GCC required!
#endif
#ifndef AC_DECLSPEC_API_IMPORT
#define AC_DECLSPEC_API_IMPORT extern
#endif
#ifndef AC_DECLSPEC_API_EXPORT
#define AC_DECLSPEC_API_EXPORT extern
#endif
#ifndef AC_DECLSPEC_CTOR
#define AC_DECLSPEC_CTOR
#endif
#ifndef AC_DECLSPEC_DTOR
#define AC_DECLSPEC_DTOR
#endif
#ifndef AC_UNUSED
#define AC_UNUSED( ac_macro_state ) (void)ac_macro_state
#endif
#ifndef AC_DECLSPEC_INLINE
#define AC_DECLSPEC_INLINE static AC_INLINE
#endif
#define AC_DECLSPEC_PACKED_ALIGN( ac_macro_align ) \
AC_DECLSPEC_PACKED AC_DECLSPEC_ALIGN( ac_macro_align )
#define AC_DECLSPEC_PACKED_ALIGN_CACHE_LINE \
AC_DECLSPEC_PACKED AC_DECLSPEC_ALIGN_CACHE_LINE
#define AC_BUILD_DBG_ASSERT( ac_macro_name, ac_macro_exp ) \
struct AC_DECLSPEC_UNUSED \
ac_build_dbg_## ac_macro_name ##_ \
{ \
int test[( (ac_macro_exp) ) ? 1 : -1]; \
}
#ifdef __cplusplus
}
#endif
#endif
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-11 09:16 +0200 |
| Message-ID | <11809ss$2l1ub$1@dont-email.me> |
| In reply to | #401913 |
On 10/09/2026 23:08, Chris M. Thomasson wrote: > On 9/9/2026 5:43 AM, David Brown wrote: > [...] >> Just defining the symbol is fine - for use as a pure header guard, >> where the check is with "#ifndef" or "#ifdef", defining it to a value >> has no added value. Adding the "1" in that example was done without >> thinking. >> > ________ > #ifndef __NUMBER_GENERATOR_H__ > #define __NUMBER_GENERATOR_H__ 1 > ________ > > > Is that __* non conformant? Does it breach the impl name prefix space? Yes. As Keith pointed out, using "H_NUMBER_GENERATOR_" or similar is better. Various conventions are used, and usually the risk of collisions with implementations is entirely negligible. But there is no cost in avoiding reserved prefixes, so you might as well do so.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-09-14 19:14 +0000 |
| Message-ID | <20260914111759.911@kylheku.com> |
| In reply to | #401913 |
On 2026-09-10, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 9/9/2026 5:43 AM, David Brown wrote: > [...] >> Just defining the symbol is fine - for use as a pure header guard, where >> the check is with "#ifndef" or "#ifdef", defining it to a value has no >> added value. Adding the "1" in that example was done without thinking. >> > ________ > #ifndef __NUMBER_GENERATOR_H__ > #define __NUMBER_GENERATOR_H__ 1 > ________ > > > Is that __* non conformant? Does it breach the impl name prefix space? No matter what you name anything in C, you are playing roulette. Vendor extensions and new standard features introduce identifiers into namespaces that have not been hitherto reserved. It's like a traffic code. If you intrude into a namespace, it's like running a stop sign. Nothing bad might happen, but if it does, it is on you. However, C naming is like a residential neighborhood full of unguarded intersections, with only a few stop signs. There isn't anything reasonable you can do to 100% ensure you will never have a clash with anything in your C programming. (By "reasonable", I do not intend to introduce moving goalposts: specifically, I mean, not subjecting yourself to some horribly inconvenient naming scheme in every single namespace which makes it vanishingly improbable of ever seeing a clash).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-18 08:29 -0700 |
| Message-ID | <86qziqtw5s.fsf@linuxsc.com> |
| In reply to | #402067 |
Kaz Kylheku <046-301-5902@kylheku.com> writes: > On 2026-09-10, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > >> On 9/9/2026 5:43 AM, David Brown wrote: >> [...] >> >>> Just defining the symbol is fine - for use as a pure header guard, >>> where the check is with "#ifndef" or "#ifdef", defining it to a >>> value has no added value. Adding the "1" in that example was done >>> without thinking. >> >> ________ >> #ifndef __NUMBER_GENERATOR_H__ >> #define __NUMBER_GENERATOR_H__ 1 >> ________ >> >> >> Is that __* non conformant? Does it breach the impl name prefix >> space? > > No matter what you name anything in C, you are playing roulette. > Vendor extensions and new standard features introduce identifiers > into namespaces that have not been hitherto reserved. > > It's like a traffic code. If you intrude into a namespace, it's > like running a stop sign. Nothing bad might happen, but if it > does, it is on you. > > However, C naming is like a residential neighborhood full of > unguarded intersections, with only a few stop signs. > > There isn't anything reasonable you can do to 100% ensure you will > never have a clash with anything in your C programming. (By > "reasonable", I do not intend to introduce moving goalposts: > specifically, I mean, not subjecting yourself to some horribly > inconvenient naming scheme in every single namespace which makes > it vanishingly improbable of ever seeing a clash). This picture is a lot more bleak than it needs to be. In practice dealing with possible naming conflicts is really not that hard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-09 02:45 -0700 |
| Message-ID | <117r9s9$10k4l$1@kst.eternal-september.org> |
| In reply to | #401766 |
David Brown <david.brown@hesbynett.no> writes:
> On 09/09/2026 09:59, Janis Papanagnou wrote:
[...]
>> Hmm.. - I'm not sure I can follow you here. - If some of our headers
>> had its own dependencies it was the responsibility of that header to
>> satisfy them. - I recall there were occasionally issues with lacking
>> consistency, but that was in our project contexts considered a bug.
>
> I follow that principle too. But not everyone does. So I would have :
>
> #ifndef __NUMBER_GENERATOR_H__
> #define __NUMBER_GENERATOR_H__ 1
>
> #include <stdint.h>
>
> extern uint64_t make_a_big_number(void);
>
> #endif // #ifndef __NUMBER_GENERATOR_H__
A couple of nitpicks:
I'd choose a non-reserved name for the macro, probably
H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
reserved name for a header whose name starts with 'e'). Admittedly
the odds of a collision with an implementation-defined reserved
name are small, but I prefer to make them zero. I'd also use
`#define ...` rather than `#define ... 1`; it only matters whether
it's defined or not, not what it expands to.
> But some people would omit the "#include <stdint.h>" line, and leave
> that as the responsibility of the person writing the C file. The same
> applies to dependencies on local header files.
Ick. That would mean that if a future version depends on another
standard header, all client code has to be updated, even if it
doesn't use the new functionality.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 15:07 +0200 |
| Message-ID | <117rlmp$s9ir$9@dont-email.me> |
| In reply to | #401775 |
On 09/09/2026 11:45, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/09/2026 09:59, Janis Papanagnou wrote:
> [...]
>>> Hmm.. - I'm not sure I can follow you here. - If some of our headers
>>> had its own dependencies it was the responsibility of that header to
>>> satisfy them. - I recall there were occasionally issues with lacking
>>> consistency, but that was in our project contexts considered a bug.
>>
>> I follow that principle too. But not everyone does. So I would have :
>>
>> #ifndef __NUMBER_GENERATOR_H__
>> #define __NUMBER_GENERATOR_H__ 1
>>
>> #include <stdint.h>
>>
>> extern uint64_t make_a_big_number(void);
>>
>> #endif // #ifndef __NUMBER_GENERATOR_H__
>
> A couple of nitpicks:
>
> I'd choose a non-reserved name for the macro, probably
> H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
> reserved name for a header whose name starts with 'e'). Admittedly
> the odds of a collision with an implementation-defined reserved
> name are small, but I prefer to make them zero. I'd also use
> `#define ...` rather than `#define ... 1`; it only matters whether
> it's defined or not, not what it expands to.
Sure. In practice, it's common to include a bit of directory structure
in the header guard name too.
>
>> But some people would omit the "#include <stdint.h>" line, and leave
>> that as the responsibility of the person writing the C file. The same
>> applies to dependencies on local header files.
>
> Ick. That would mean that if a future version depends on another
> standard header, all client code has to be updated, even if it
> doesn't use the new functionality.
>
Yes.
I've seen worse issues than that, however.
Imagine a library where there is a configuration option NUMBER_OF_THINGS
that library users might want to specify, or might want to leave as the
default.
So you have :
// user_config.h
#define NUMBER_OF_THINGS 20
// platform_default.h
#ifndef NUMBER_OF_THINGS
#define NUMBER_OF_THINGS 30 // Standard on target X
#endif
// library_funcs.h
#ifndef NUMBER_OF_THINGS
#define NUMBER_OF_THINGS 40 // Default if not overridden
#endif
struct Thing_Holder {
int things[NUMBER_OF_THINGS];
};
extern void do_things(struct Thing_Holder * th);
// library_funcs.c
#include "user_config.h" // User overrides
#include "platform_default.h" // Platform-specific details
#include "library_funcs.h"
void do_things(struct Thing_Holder * th) {
...
}
And then your own code has:
#include "library_funcs.h"
#include "user_config.h"
Imagine the hilarity that results when trying to debug the code. And
then suppose that there's another similar pre-processor symbol that
someone has added manually to an IDE project setup (giving a
"-DNUMBER_OF_OTHER_THINGS=42" command-line argument to the compiler),
but that's missing when the project is moved over to a different IDE by
someone who didn't know about it.
This kind of nonsense turns up regularly in embedded programming for
libraries for RTOS's, network stacks, and manufacturer-provided SDKs and
other stuff. Oh, and you might also find multiple different files named
"user_config.h" in example code from the supplier, with different
settings (and no information about /why/ particular settings are
picked). Every little bit of the SDK is then in its own directory of
two or three files, and each of these directories is added to the
include path for the compilation, in a random and sometimes inconsistent
order.
C's include system works well when used in a sensible and disciplined
manner, but unfortunately not all C programmers are sensible and
disciplined.
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-09 07:14 -0600 |
| Message-ID | <117rm3k$15nep$1@dont-email.me> |
| In reply to | #401793 |
David Brown wrote:
> On 09/09/2026 11:45, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 09/09/2026 09:59, Janis Papanagnou wrote:
>> [...]
>>>> Hmm.. - I'm not sure I can follow you here. - If some of our headers
>>>> had its own dependencies it was the responsibility of that header to
>>>> satisfy them. - I recall there were occasionally issues with lacking
>>>> consistency, but that was in our project contexts considered a bug.
>>>
>>> I follow that principle too. But not everyone does. So I would have :
>>>
>>> #ifndef __NUMBER_GENERATOR_H__
>>> #define __NUMBER_GENERATOR_H__ 1
>>>
>>> #include <stdint.h>
>>>
>>> extern uint64_t make_a_big_number(void);
>>>
>>> #endif // #ifndef __NUMBER_GENERATOR_H__
>>
>> A couple of nitpicks:
>>
>> I'd choose a non-reserved name for the macro, probably
>> H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
>> reserved name for a header whose name starts with 'e'). Admittedly
>> the odds of a collision with an implementation-defined reserved
>> name are small, but I prefer to make them zero. I'd also use
>> `#define ...` rather than `#define ... 1`; it only matters whether
>> it's defined or not, not what it expands to.
>
> Sure. In practice, it's common to include a bit of directory structure
> in the header guard name too.
>
>>
>>> But some people would omit the "#include <stdint.h>" line, and leave
>>> that as the responsibility of the person writing the C file. The same
>>> applies to dependencies on local header files.
>>
>> Ick. That would mean that if a future version depends on another
>> standard header, all client code has to be updated, even if it
>> doesn't use the new functionality.
>>
>
> Yes.
>
> I've seen worse issues than that, however.
>
> Imagine a library where there is a configuration option NUMBER_OF_THINGS
> that library users might want to specify, or might want to leave as the
> default.
>
> So you have :
>
> // user_config.h
> #define NUMBER_OF_THINGS 20
>
>
> // platform_default.h
> #ifndef NUMBER_OF_THINGS
> #define NUMBER_OF_THINGS 30 // Standard on target X
> #endif
>
>
> // library_funcs.h
> #ifndef NUMBER_OF_THINGS
> #define NUMBER_OF_THINGS 40 // Default if not overridden
> #endif
>
> struct Thing_Holder {
> int things[NUMBER_OF_THINGS];
> };
> extern void do_things(struct Thing_Holder * th);
>
>
> // library_funcs.c
> #include "user_config.h" // User overrides
> #include "platform_default.h" // Platform-specific details
> #include "library_funcs.h"
>
> void do_things(struct Thing_Holder * th) {
> ...
> }
>
>
> And then your own code has:
>
> #include "library_funcs.h"
> #include "user_config.h"
>
>
> Imagine the hilarity that results when trying to debug the code. And
> then suppose that there's another similar pre-processor symbol that
> someone has added manually to an IDE project setup (giving a
> "-DNUMBER_OF_OTHER_THINGS=42" command-line argument to the compiler),
> but that's missing when the project is moved over to a different IDE by
> someone who didn't know about it.
>
>
> This kind of nonsense turns up regularly in embedded programming for
> libraries for RTOS's, network stacks, and manufacturer-provided SDKs and
> other stuff. Oh, and you might also find multiple different files named
> "user_config.h" in example code from the supplier, with different
> settings (and no information about /why/ particular settings are
> picked). Every little bit of the SDK is then in its own directory of
> two or three files, and each of these directories is added to the
> include path for the compilation, in a random and sometimes inconsistent
> order.
>
> C's include system works well when used in a sensible and disciplined
> manner, but unfortunately not all C programmers are sensible and
> disciplined.
>
Agreed. Plus some C programmers use the switch keyword, which we all
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of my
propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-09 15:31 +0200 |
| Message-ID | <117rn3j$s9ir$10@dont-email.me> |
| In reply to | #401794 |
On 09/09/2026 15:14, Lane W wrote: > David Brown wrote: >> C's include system works well when used in a sensible and disciplined >> manner, but unfortunately not all C programmers are sensible and >> disciplined. >> > Agreed. Plus some C programmers use the switch keyword, which we all > agree is BAD BAD BAD, right Janis and Keith? > > In fact at work, I'm regularly known as __The Evil One__ because of my > propensity to use the switch construct. > > Every company brochure shows my position as Sauron in the company > fables, with my signature golden ring. Pure evil, I guarantee it. > I can't understand where this martyr complex comes from. I saw your post about an alternative way to structure fir's code, and I thought it was a poor solution. That was not because it used "switch", or because /you/ wrote it, but simply because I did not think it was a clear or maintainable way to express the algorithm. It added complexity and a layer of indirection without adding advantages of flexibility or clarity. (I fully agree with your comment in the post that there are many ways to structure the code here - without knowing much more about the program, it is impossible to give a good comparison to them.) If you don't want people to express opinions on code snippets or suggestions, don't post them. I think most regulars here (and certainly Janis and Keith) will judge them as fairly as they can, on the merits of the code - with a total disregard to who posts them. (The exception is that many regulars have kill-filed some of the more irksome posters.) Don't imagine that people will treat your posts or code samples specially. You are not that important, and you haven't been posting in c.l.c. long enough to have established much of a reputation (positive or negative). It would be a lot better if you stuck to writing posts that are sensible replies within threads, or start new topical threads. Post C code, get feedback on it, and treat that feedback as constructive criticism of the code - not as some kind of personal attack. (My post here is intended as constructive criticism - it is not a personal attack.)
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-09 07:41 -0600 |
| Message-ID | <117rnn6$167n7$2@dont-email.me> |
| In reply to | #401795 |
David Brown wrote: > On 09/09/2026 15:14, Lane W wrote: >> David Brown wrote: > >>> C's include system works well when used in a sensible and disciplined >>> manner, but unfortunately not all C programmers are sensible and >>> disciplined. >>> >> Agreed. Plus some C programmers use the switch keyword, which we all >> agree is BAD BAD BAD, right Janis and Keith? >> >> In fact at work, I'm regularly known as __The Evil One__ because of my >> propensity to use the switch construct. >> >> Every company brochure shows my position as Sauron in the company >> fables, with my signature golden ring. Pure evil, I guarantee it. >> > > I can't understand where this martyr complex comes from. I saw your > post about an alternative way to structure fir's code, and I thought it > was a poor solution. That was not because it used "switch", or because > /you/ wrote it, but simply because I did not think it was a clear or > maintainable way to express the algorithm. It added complexity and a > layer of indirection without adding advantages of flexibility or > clarity. (I fully agree with your comment in the post that there are > many ways to structure the code here - without knowing much more about > the program, it is impossible to give a good comparison to them.) > > If you don't want people to express opinions on code snippets or > suggestions, don't post them. I think most regulars here (and certainly > Janis and Keith) will judge them as fairly as they can, on the merits of > the code - with a total disregard to who posts them. (The exception is > that many regulars have kill-filed some of the more irksome posters.) > > Don't imagine that people will treat your posts or code samples > specially. You are not that important, and you haven't been posting in > c.l.c. long enough to have established much of a reputation (positive or > negative). > > It would be a lot better if you stuck to writing posts that are sensible > replies within threads, or start new topical threads. Post C code, get > feedback on it, and treat that feedback as constructive criticism of the > code - not as some kind of personal attack. (My post here is intended > as constructive criticism - it is not a personal attack.) > > It's because many of the lot of you are tying your hands with what you think Policy tells you. The poster asked how to avoid if then else and I showed him a way. It solved his problem. Where is the evil in that? Who is this deity you worship that say to you you can gauge a morality of a snippet of code based on your pathetic standards and policies at YOUR company?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-09 15:58 +0200 |
| Message-ID | <117rold$16l97$1@dont-email.me> |
| In reply to | #401798 |
Lane W pisze:
> David Brown wrote:
>> On 09/09/2026 15:14, Lane W wrote:
>>> David Brown wrote:
>>
>>>> C's include system works well when used in a sensible and
>>>> disciplined manner, but unfortunately not all C programmers are
>>>> sensible and disciplined.
>>>>
>>> Agreed. Plus some C programmers use the switch keyword, which we all
>>> agree is BAD BAD BAD, right Janis and Keith?
>>>
>>> In fact at work, I'm regularly known as __The Evil One__ because of
>>> my propensity to use the switch construct.
>>>
>>> Every company brochure shows my position as Sauron in the company
>>> fables, with my signature golden ring. Pure evil, I guarantee it.
>>>
>>
>> I can't understand where this martyr complex comes from. I saw your
>> post about an alternative way to structure fir's code, and I thought
>> it was a poor solution. That was not because it used "switch", or
>> because /you/ wrote it, but simply because I did not think it was a
>> clear or maintainable way to express the algorithm. It added
>> complexity and a layer of indirection without adding advantages of
>> flexibility or clarity. (I fully agree with your comment in the post
>> that there are many ways to structure the code here - without knowing
>> much more about the program, it is impossible to give a good
>> comparison to them.)
>>
>> If you don't want people to express opinions on code snippets or
>> suggestions, don't post them. I think most regulars here (and
>> certainly Janis and Keith) will judge them as fairly as they can, on
>> the merits of the code - with a total disregard to who posts them.
>> (The exception is that many regulars have kill-filed some of the more
>> irksome posters.)
>>
>> Don't imagine that people will treat your posts or code samples
>> specially. You are not that important, and you haven't been posting
>> in c.l.c. long enough to have established much of a reputation
>> (positive or negative).
>>
>> It would be a lot better if you stuck to writing posts that are
>> sensible replies within threads, or start new topical threads. Post C
>> code, get feedback on it, and treat that feedback as constructive
>> criticism of the code - not as some kind of personal attack. (My post
>> here is intended as constructive criticism - it is not a personal
>> attack.)
>>
>>
> It's because many of the lot of you are tying your hands with what you
> think Policy tells you. The poster asked how to avoid if then else and I
> showed him a way. It solved his problem. Where is the evil in that? Who
> is this deity you worship that say to you you can gauge a morality of a
> snippet of code based on your pathetic standards and policies at YOUR
> company?
in fact i was talking about quite other and more theoretical problem,
not how rewrite tis pice of code (as to revrite i think the ones
with
char* a= ""; if(d<0.3) a ="barely" ; if(d>.9) a= "hardly";
slog("siunsusn %s", a);
is best)
what i wast talkin about was that (whot showed) there are
cases in c programming ehen you need such construct
if() {}
if() {}
if() {}
if() {}
othercase {}
and c has no such thing in languuage
you may add elses but then the logic of this laddes not fits the
"intention" - becouse intention is 'i dont care for elses.. ifs are in
intention liek independant..but i care of "othercase" case
and c has no construction for it imo
here as to this INTENTION the gotos would fit more than elses
if() {} goto go_on;
if() {} goto go_on;
if() {} goto go_on;
if() {} goto go_on;
//othercase
go_on:
and switch also would be close to that but it not takes the d<0.3 type
conditions/keys
so conclusions were c lacks some language construct which i described as
case() {}
case() {}
case() {}
otherwise {}
AND follow to that conclusion was that maybe C needs logical operator
for ifs
if() {} & if() {} | if() {} then {}
thet was the core story her in my own intent ;c
(some others talked about the snipets, its ok but i was writing on what
i write here)
[toc] | [prev] | [next] | [standalone]
Page 3 of 25 — ← Prev page 1 2 [3] 4 5 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web