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 11 of 25 — ← Prev page 1 … 9 10 [11] 12 13 … 25 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-14 23:56 +0200 |
| Message-ID | <1189qip$15iga$2@dont-email.me> |
| In reply to | #402071 |
On 2026-09-14 22:54, David Brown wrote:
> On 14/09/2026 20:21, tTh wrote:
>> On 9/14/26 18:11, David Brown wrote:
>>>>
>>>> I simply always use braces, regardless of whether or not
>>>> the clause contains a single statement or a compound statement.
>>>>
>>>
>>> That's always a safe choice, but some C programmers prefer to use
>>> fewer braces. A compromise is to insist on always using braces if
>>> there is an "else" clause (in both the "if" and "else" parts), or at
>>> the very least, to do so if there are nested "if" statements.
>>
>> About braces, I always use them except in one case :
>> when the code fragment is on the same line as the if.
>>
>> if (retval) fprintf(stderr, "retval is %d\n", retval);
I have the habit to regularly use a line-break and indentation here.
if (retval)
fprintf(stderr, "retval is %d\n", retval);
>> I think it's dangerous, but for some little things
>> like my sample, it make things clearer for me.
I wouldn't exactly call it "dangerous". But I think one should apply
any means and habits that avoid the errors that one personally knows
to make.
For collaborative work we therefore had a rule to always use braces.
>
> I do the same, but restrict it to simpler statements.
>
> "Simpler" is a matter of taste and subjective judgement here -
> "return;", "break;", "continue;" are all "simple". A short assignment
> is "simple". For a longer printf, I'd usually use braces. If the
> statement is too long to be comfortable on one line, or may reasonably
> become so in future modifications, then I'd have braces.
For specific "simple statements" like early exits I usually even add
an empty line after it;
if (!precond)
return special;
regular_process;
For 'if'-cascades with "simple statements" I also omit the line-break,
though. As you say it's also about any specific code being comfortably
represented.
Being a personal preference one should use a style to minimize problems
in one's own style, or follow the company standards where collaborative
work is expected.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-15 09:07 +0200 |
| Message-ID | <118aqqq$25itf$1@dont-email.me> |
| In reply to | #402077 |
On 14/09/2026 23:56, Janis Papanagnou wrote:
> On 2026-09-14 22:54, David Brown wrote:
>> On 14/09/2026 20:21, tTh wrote:
>>> On 9/14/26 18:11, David Brown wrote:
>>>>>
>>>>> I simply always use braces, regardless of whether or not
>>>>> the clause contains a single statement or a compound statement.
>>>>>
>>>>
>>>> That's always a safe choice, but some C programmers prefer to use
>>>> fewer braces. A compromise is to insist on always using braces if
>>>> there is an "else" clause (in both the "if" and "else" parts), or at
>>>> the very least, to do so if there are nested "if" statements.
>>>
>>> About braces, I always use them except in one case :
>>> when the code fragment is on the same line as the if.
>>>
>>> if (retval) fprintf(stderr, "retval is %d\n", retval);
>
> I have the habit to regularly use a line-break and indentation here.
>
> if (retval)
> fprintf(stderr, "retval is %d\n", retval);
>
To my eyes (and I fully appreciate that this kind of thing is highly
subjective), that is the worst you can do. That's how you end up with
mistakes like this, after lines are added, removed or changed during
code maintenance :
if (...)
goto fail;
goto fail;
It gets even worse if different people have worked with the code and
have different habits or settings for tabs and spaces. Suppose the
first line of your code snippet had eight spaces, and the second line
two tabs, written with someone using an "8 spaces per tab" setting.
Someone looking at the code with "4 spaces per tab" will see them
aligned and may assume the "fprintf" always runs.
I believe it is good practice to write code that is clear regardless of
the indents - and then use consistent indentation to make it even
clearer. Even with tab/space muddles, there's no room for
misinterpretation with either :
if (retval) fprintf(stderr, "retval is %d\n", retval);
or
if (retval) {
fprintf(stderr, "retval is %d\n", retval);
}
My indentation rule is very simple - end a line with { and everything
afterwards is indented once, start a line with } and that line and
everything afterwards is outdented once. The main exception is that if
a single logical line has to be split over multiple lines because it is
a long expression, there are at least two additional indents.
>>> I think it's dangerous, but for some little things
>>> like my sample, it make things clearer for me.
>
> I wouldn't exactly call it "dangerous". But I think one should apply
> any means and habits that avoid the errors that one personally knows
> to make.
>
Sure.
> For collaborative work we therefore had a rule to always use braces.
>
Good. And in collaborative work, compromises are often made - following
the style of existing code will often overrule other style rules.
>>
>> I do the same, but restrict it to simpler statements.
>>
>> "Simpler" is a matter of taste and subjective judgement here -
>> "return;", "break;", "continue;" are all "simple". A short assignment
>> is "simple". For a longer printf, I'd usually use braces. If the
>> statement is too long to be comfortable on one line, or may reasonably
>> become so in future modifications, then I'd have braces.
>
> For specific "simple statements" like early exits I usually even add
> an empty line after it;
>
> if (!precond)
> return special;
>
> regular_process;
>
The empty line here helps, I think, and reduces some risk of error.
> For 'if'-cascades with "simple statements" I also omit the line-break,
> though. As you say it's also about any specific code being comfortably
> represented.
Occasionally a repeating pattern in code is clearer if you your usual
rules are set aside. Clarity is more important than consistency.
>
> Being a personal preference one should use a style to minimize problems
> in one's own style, or follow the company standards where collaborative
> work is expected.
>
Yes.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-15 09:41 +0200 |
| Message-ID | <118asrk$15iga$4@dont-email.me> |
| In reply to | #402089 |
On 2026-09-15 09:07, David Brown wrote: > On 14/09/2026 23:56, Janis Papanagnou wrote: >>> [...] >> >> I have the habit to regularly use a line-break and indentation here. >> >> if (retval) >> fprintf(stderr, "retval is %d\n", retval); >> > > To my eyes (and I fully appreciate that this kind of thing is highly > subjective), that is the worst you can do. Yes, you said that before. (But your example below doesn't quite fit.) > That's how you end up with > mistakes like this, after lines are added, removed or changed during > code maintenance : Erm, no. - First, I never need to use 'goto' with my programming style. And second, a 'goto' I'd handle like a 'return' (as seen in my example below); any "severe disruption" of the linear processing I'd indicate by an empty line. > > if (...) > goto fail; > goto fail; > > [...] >> >> For specific "simple statements" like early exits I usually even add >> an empty line after it; >> >> if (!precond) >> return special; >> >> regular_process; >> > > The empty line here helps, I think, and reduces some risk of error. It indeed does. (And certainly works for me.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-15 10:22 +0200 |
| Message-ID | <118av90$25itf$2@dont-email.me> |
| In reply to | #402091 |
On 15/09/2026 09:41, Janis Papanagnou wrote: > On 2026-09-15 09:07, David Brown wrote: >> On 14/09/2026 23:56, Janis Papanagnou wrote: >>>> [...] >>> >>> I have the habit to regularly use a line-break and indentation here. >>> >>> if (retval) >>> fprintf(stderr, "retval is %d\n", retval); >>> >> >> To my eyes (and I fully appreciate that this kind of thing is highly >> subjective), that is the worst you can do. > > Yes, you said that before. (But your example below doesn't quite fit.) > >> That's how you end up with mistakes like this, after lines are added, >> removed or changed during code maintenance : > > Erm, no. - First, I never need to use 'goto' with my programming style. > And second, a 'goto' I'd handle like a 'return' (as seen in my example > below); any "severe disruption" of the linear processing I'd indicate > by an empty line. The example was not about "goto" itself. It was paraphrased from the massive vulnerability "Heartbleed" in OpenSSL, where code that had been written in "your" style had later been edited had resulted in the code below. There were a series of "if (test...)" lines followed by "goto fail;" lines, in the format style you use. During a refactoring or change of these, one of the tests had been removed but by mistake the "goto fail;" line was not removed. This resulted in one of the biggest security failures seen. If the code had been written in /my/ style - either with the "goto fail;" on the same line, or with braces around it - it is extremely unlikely that the mistake could have happened, while still having code that could compile. Now, the mistake also required other failures - failure in code review, failure to test properly, failure to use static error checking (gcc's "-Wmisleading-indent" would have spotted it), and general failure of the IT world to put enough effort and resources into supporting such a critical piece of software. It is always thus when something like this happens - multiple safeguards must fail. A safe coding style - which this is not - would have been an additional safeguard. You can, of course, put different emphasis on different aspects of these safeguards - maybe you don't need any static error checking if you have good enough testing, and you don't need a good coding style if code reviews are careful enough. But I believe it always makes sense to make good use of the easy and cheap guards - basic static error checking and good coding style. Safe coding styles do not in any sense eliminate bugs or guarantee correct code, but they reduce the risk of certain classes of code bugs and code misunderstandings. Having a style where indentation sometimes means blocks, and sometimes does not, is a /bad/ idea for code safety because it increases the cognitive load to interpret the code. > >> >> if (...) >> goto fail; >> goto fail; >> >> [...] > >>> >>> For specific "simple statements" like early exits I usually even add >>> an empty line after it; >>> >>> if (!precond) >>> return special; >>> >>> regular_process; >>> >> >> The empty line here helps, I think, and reduces some risk of error. > > It indeed does. (And certainly works for me.) > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-15 11:51 +0200 |
| Message-ID | <118b4eu$15iga$5@dont-email.me> |
| In reply to | #402092 |
On 2026-09-15 10:22, David Brown wrote: > On 15/09/2026 09:41, Janis Papanagnou wrote: >> On 2026-09-15 09:07, David Brown wrote: >>> On 14/09/2026 23:56, Janis Papanagnou wrote: >>>>> [...] >>>> >>>> I have the habit to regularly use a line-break and indentation here. >>>> >>>> if (retval) >>>> fprintf(stderr, "retval is %d\n", retval); >>>> >>> >>> To my eyes (and I fully appreciate that this kind of thing is highly >>> subjective), that is the worst you can do. >> >> Yes, you said that before. (But your example below doesn't quite fit.) >> >>> That's how you end up with mistakes like this, after lines are >>> added, removed or changed during code maintenance : >> >> Erm, no. - First, I never need to use 'goto' with my programming style. >> And second, a 'goto' I'd handle like a 'return' (as seen in my example >> below); any "severe disruption" of the linear processing I'd indicate >> by an empty line. > > The example was not about "goto" itself. I'm well aware that your 'goto' example was badly chosen, and that there are other examples that illustrate your point more accurately. (But I was also aware what "problems" you actually have in mind; I know the mindset, there was actually no need to be that verbose. :-) > [...] This resulted in one of the biggest security failures seen. Obviously a failure in two ways; having insufficient QA measures, and programmers that had problems with the necessary attention and experience. (Adding after I read your text below: Or maybe subjective problems with the "abstract picture" one has about the syntactic elements.) > [...] > > Now, the mistake also required other failures - failure in code review, > failure to test properly, failure to use static error checking (gcc's "- > Wmisleading-indent" would have spotted it), and general failure of the > IT world to put enough effort and resources into supporting such a > critical piece of software. Yes. > It is always thus when something like this > happens - multiple safeguards must fail. A safe coding style - which > this is not - would have been an additional safeguard. You can, of > course, put different emphasis on different aspects of these safeguards > - maybe you don't need any static error checking if you have good enough > testing, and you don't need a good coding style if code reviews are > careful enough. But I believe it always makes sense to make good use of > the easy and cheap guards - basic static error checking and good coding > style. Right. - But don't forget that "spurious means" to tackle a topic is as well a source of obfuscating information; I certainly won't judge whether one or the other is in any (absolute or relative) way "better", but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate to "ensure" "programming safety". > > Safe coding styles do not in any sense eliminate bugs or guarantee > correct code, but they reduce the risk of certain classes of code bugs > and code misunderstandings. Sure. - The point is; is there an objectively safe style here? I think there's subjective styles that helps some and annoys others. I don't think it makes sense to argue about that. (Especially given that we both have many decades of experience in the area.) > Having a style where indentation sometimes > means blocks, and sometimes does not, is a /bad/ idea for code safety > because it increases the cognitive load to interpret the code. I disagree. - Your statement makes assumptions about a subjective idea of two different things. I can agree only insofar as accepting that you have that picture in mind, and with that picture it seems inconsistent (or something like that) to you. So I accept it's "cognitive load" for you. (While spurious syntax elements is "cognitive load" for me.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-15 12:53 +0200 |
| Message-ID | <118b83i$2bi4l$1@dont-email.me> |
| In reply to | #402093 |
On 15/09/2026 11:51, Janis Papanagnou wrote: > On 2026-09-15 10:22, David Brown wrote: >> On 15/09/2026 09:41, Janis Papanagnou wrote: >>> On 2026-09-15 09:07, David Brown wrote: >>>> On 14/09/2026 23:56, Janis Papanagnou wrote: >>>>>> [...] >>>>> >>>>> I have the habit to regularly use a line-break and indentation here. >>>>> >>>>> if (retval) >>>>> fprintf(stderr, "retval is %d\n", retval); >>>>> >>>> >>>> To my eyes (and I fully appreciate that this kind of thing is highly >>>> subjective), that is the worst you can do. >>> >>> Yes, you said that before. (But your example below doesn't quite fit.) >>> >>>> That's how you end up with mistakes like this, after lines are >>>> added, removed or changed during code maintenance : >>> >>> Erm, no. - First, I never need to use 'goto' with my programming style. >>> And second, a 'goto' I'd handle like a 'return' (as seen in my example >>> below); any "severe disruption" of the linear processing I'd indicate >>> by an empty line. >> >> The example was not about "goto" itself. > > I'm well aware that your 'goto' example was badly chosen, and that > there are other examples that illustrate your point more accurately. > (But I was also aware what "problems" you actually have in mind; I > know the mindset, there was actually no need to be that verbose. :-) > >> [...] This resulted in one of the biggest security failures seen. > > Obviously a failure in two ways; having insufficient QA measures, > and programmers that had problems with the necessary attention and > experience. > > (Adding after I read your text below: Or maybe subjective problems > with the "abstract picture" one has about the syntactic elements.) > >> [...] >> >> Now, the mistake also required other failures - failure in code >> review, failure to test properly, failure to use static error checking >> (gcc's "- Wmisleading-indent" would have spotted it), and general >> failure of the IT world to put enough effort and resources into >> supporting such a critical piece of software. > > Yes. > >> It is always thus when something like this happens - multiple >> safeguards must fail. A safe coding style - which this is not - would >> have been an additional safeguard. You can, of course, put different >> emphasis on different aspects of these safeguards - maybe you don't >> need any static error checking if you have good enough testing, and >> you don't need a good coding style if code reviews are careful >> enough. But I believe it always makes sense to make good use of the >> easy and cheap guards - basic static error checking and good coding >> style. > > Right. - But don't forget that "spurious means" to tackle a topic is > as well a source of obfuscating information; I certainly won't judge > whether one or the other is in any (absolute or relative) way "better", > but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate > to "ensure" "programming safety". Fair point. It would be wrong to note that this particular bug would have been prevented by a particular coding practice, and use that to say that we should always follow that coding practice. One data point is not statistical evidence. And we all know we should be writing "if (a == 5)", with decent spacing :-) Far more effective than any one developer changing their coding style would be having more warnings enabled by default in common compilers. (clang warns about "if (a = 5)" by default, while gcc needs "-Wall". Both warn about the misleading indentation only when warnings are enabled.) > >> >> Safe coding styles do not in any sense eliminate bugs or guarantee >> correct code, but they reduce the risk of certain classes of code bugs >> and code misunderstandings. > > Sure. - The point is; is there an objectively safe style here? > I think there's subjective styles that helps some and annoys others. > I have no statistics or reports to back up anything I say, so I can only say that I would /expect/ to see a small but measurable reduction in code errors if "indent without braces" conditionals are not allowed in code, if one were to compare code samples that had not used appropriate static checks. That is, I /believe/ there is a objective difference here. But I certainly can't claim to /know/ that there is. And even if statistics bear me out here (maybe some PhD student has done the research), that would still not contradict your statement. It is entirely reasonable to suppose that the style choices here would reduce risks for some programmers while making no difference to others - and no one likes being told to change their style without good reason. > I don't think it makes sense to argue about that. (Especially given > that we both have many decades of experience in the area.) > This also makes it difficult to judge. I am confident that any choice of style here would make no difference to the risk of errors in either your code or my code - we both know how to use "-Wall" and pay attention to the warnings, so if we /did/ make a mistake, our tools would tell us. >> Having a style where indentation sometimes means blocks, and sometimes >> does not, is a /bad/ idea for code safety because it increases the >> cognitive load to interpret the code. > > I disagree. - Your statement makes assumptions about a subjective idea > of two different things. I can agree only insofar as accepting that you > have that picture in mind, and with that picture it seems inconsistent > (or something like that) to you. So I accept it's "cognitive load" for > you. (While spurious syntax elements is "cognitive load" for me.) > Okay - again, that's a fair point. Cognitive load is always subjective, as it is less effort to interpret code written in a style with which the reader is most familiar.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-18 09:10 +0200 |
| Message-ID | <118io4h$scqh$2@dont-email.me> |
| In reply to | #402095 |
On 2026-09-15 12:53, David Brown wrote: > On 15/09/2026 11:51, Janis Papanagnou wrote: [...] >> >> Right. - But don't forget that "spurious means" to tackle a topic is >> as well a source of obfuscating information; I certainly won't judge >> whether one or the other is in any (absolute or relative) way "better", >> but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate >> to "ensure" "programming safety". > > [...] > > And we all know we should be writing "if (a == 5)", with decent spacing :-) Sure. Above was just a deliberate terse form for inline reference. Usually I'm using probably more spacing inline and between lines and chapters than the average programmer would find tolerable. ;-) > > Far more effective than any one developer changing their coding style > would be having more warnings enabled by default in common compilers. > (clang warns about "if (a = 5)" by default, while gcc needs "-Wall". > Both warn about the misleading indentation only when warnings are enabled.) Yes, things have gotten much better since the dates back then when I did my professional programming in C/C++. >> >> Sure. - The point is; is there an objectively safe style here? >> I think there's subjective styles that helps some and annoys others. >> > > I have no statistics or reports to back up anything I say, so I can only > say that I would /expect/ to see a small but measurable reduction in > code errors if "indent without braces" conditionals are not allowed in > code, if one were to compare code samples that had not used appropriate > static checks. That is, I /believe/ there is a objective difference > here. But I certainly can't claim to /know/ that there is. And even if > statistics bear me out here (maybe some PhD student has done the > research), that would still not contradict your statement. It is > entirely reasonable to suppose that the style choices here would reduce > risks for some programmers while making no difference to others - and no > one likes being told to change their style without good reason. Actually, we established coding standards, and not following these required(!) - by those same standards - any deviation to be explained. (BTW, I authored, co-authored, and reviewed coding standard for three different programming languages; one of the rules - and contrary to my own convenience - was to always use braces also in the cases discussed! Just note that I haven't formulated it because one would be safer than the other; but we had to choose one option, and the rule to "always use braces" is just simpler (more practicable and easier to memorize) than an also sensible but very differentiated rule option - remember these simple 'if' cascades.) > >> I don't think it makes sense to argue about that. (Especially given >> that we both have many decades of experience in the area.) >> > > This also makes it difficult to judge. I am confident that any choice > of style here would make no difference to the risk of errors in either > your code or my code - we both know how to use "-Wall" and pay attention > to the warnings, so if we /did/ make a mistake, our tools would tell us. You might be astonished but I don't recall to have needed any explicit warnings setting; our policy was a zero-warning approach (by the default warnings of our compilers), and where we identified any needs beyond we communicated with the build-management to make it the company default. Having good programmers, providing trainings and courses, helped also. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-18 11:37 +0200 |
| Message-ID | <118j0o7$14tgi$1@dont-email.me> |
| In reply to | #402208 |
On 18/09/2026 09:10, Janis Papanagnou wrote: > On 2026-09-15 12:53, David Brown wrote: >> On 15/09/2026 11:51, Janis Papanagnou wrote: > [...] >>> >>> Right. - But don't forget that "spurious means" to tackle a topic is >>> as well a source of obfuscating information; I certainly won't judge >>> whether one or the other is in any (absolute or relative) way "better", >>> but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate >>> to "ensure" "programming safety". >> >> [...] >> >> And we all know we should be writing "if (a == 5)", with decent >> spacing :-) > > Sure. Above was just a deliberate terse form for inline reference. > Usually I'm using probably more spacing inline and between lines > and chapters than the average programmer would find tolerable. ;-) I like space - it aids legibility. There's a reason the biggest key on the keyboard is the spacebar, and the second biggest is the return key. > >> >> Far more effective than any one developer changing their coding style >> would be having more warnings enabled by default in common compilers. >> (clang warns about "if (a = 5)" by default, while gcc needs "-Wall". >> Both warn about the misleading indentation only when warnings are >> enabled.) > > Yes, things have gotten much better since the dates back then when > I did my professional programming in C/C++. > Tools have certainly got better, but the default warnings in compilers progress much too slowly IMHO. (Of course I can enable all the warning flags I like for my own use - but I'd prefer if everyone else used them more!) >>> >>> Sure. - The point is; is there an objectively safe style here? >>> I think there's subjective styles that helps some and annoys others. >>> >> >> I have no statistics or reports to back up anything I say, so I can >> only say that I would /expect/ to see a small but measurable reduction >> in code errors if "indent without braces" conditionals are not allowed >> in code, if one were to compare code samples that had not used >> appropriate static checks. That is, I /believe/ there is a objective >> difference here. But I certainly can't claim to /know/ that there >> is. And even if statistics bear me out here (maybe some PhD student >> has done the research), that would still not contradict your >> statement. It is entirely reasonable to suppose that the style >> choices here would reduce risks for some programmers while making no >> difference to others - and no one likes being told to change their >> style without good reason. > > Actually, we established coding standards, and not following these > required(!) - by those same standards - any deviation to be explained. > > (BTW, I authored, co-authored, and reviewed coding standard for three > different programming languages; one of the rules - and contrary to my > own convenience - was to always use braces also in the cases discussed! > Just note that I haven't formulated it because one would be safer than > the other; but we had to choose one option, and the rule to "always use > braces" is just simpler (more practicable and easier to memorize) than > an also sensible but very differentiated rule option - remember these > simple 'if' cascades.) That makes sense. Coding standard rules can never be the "best" for all circumstances and all users - even if people could agree what "best" means. They are always a compromise of sorts. > >> >>> I don't think it makes sense to argue about that. (Especially given >>> that we both have many decades of experience in the area.) >>> >> >> This also makes it difficult to judge. I am confident that any choice >> of style here would make no difference to the risk of errors in either >> your code or my code - we both know how to use "-Wall" and pay >> attention to the warnings, so if we /did/ make a mistake, our tools >> would tell us. > > You might be astonished but I don't recall to have needed any explicit > warnings setting; our policy was a zero-warning approach (by the default > warnings of our compilers), and where we identified any needs beyond we > communicated with the build-management to make it the company default. > Having good programmers, providing trainings and courses, helped also. > If the default warnings for your compiler matched something like "-Wall" in gcc, then that could be a good starting point. I don't know what compiler(s) you used, but for many IME the default warnings are pretty feeble. But it can certainly be impractical to insist on a specific list of different warning options, especially when a project includes third-party code that might have different conventions.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-19 09:03 +0200 |
| Message-ID | <118lc47$scqh$3@dont-email.me> |
| In reply to | #402216 |
On 2026-09-18 11:37, David Brown wrote: > On 18/09/2026 09:10, Janis Papanagnou wrote: >> On 2026-09-15 12:53, David Brown wrote: >>> On 15/09/2026 11:51, Janis Papanagnou wrote: >> [...] >>> >>> And we all know we should be writing "if (a == 5)", with decent >>> spacing :-) >> >> Sure. Above was just a deliberate terse form for inline reference. >> Usually I'm using probably more spacing inline and between lines >> and chapters than the average programmer would find tolerable. ;-) > > I like space - it aids legibility. There's a reason the biggest key on > the keyboard is the spacebar, and the second biggest is the return key. And the third biggest the Backspace key to quickly erase all this ugly code we wrote? ;-) >> >> Yes, things have gotten much better since the dates back then when >> I did my professional programming in C/C++. >> > > Tools have certainly got better, but the default warnings in compilers > progress much too slowly IMHO. (Of course I can enable all the warning > flags I like for my own use - but I'd prefer if everyone else used them > more!) Well, I cannot really tell about the more recent behaviors. All I noticed was that I've got (or could enable) more diagnostics than in earlier days, and that the information got better (in content and in display representation) - it would certainly be bad if it were otherwise. >> >> You might be astonished but I don't recall to have needed any explicit >> warnings setting; our policy was a zero-warning approach (by the default >> warnings of our compilers), and where we identified any needs beyond we >> communicated with the build-management to make it the company default. >> Having good programmers, providing trainings and courses, helped also. >> > > If the default warnings for your compiler matched something like "-Wall" > in gcc, then that could be a good starting point. I don't recall what the settings were. (As said, I rarely needed to make individual settings.) > I don't know what compiler(s) you used, I seem to recall that (in the late 1980's) on SunOS we used gcc/g++ (for some reason I don't recall any more). Later we usually used compilers that came with the commercial systems (on AIX for example xlC, IIRC). Privately I used only the GNU tools (but back then in my professional days I did only very few private projects). > but for many IME the default warnings are pretty > feeble. But it can certainly be impractical to insist on a specific > list of different warning options, especially when a project includes > third-party code that might have different conventions. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-19 13:01 +0200 |
| Message-ID | <118lq33$2526u$1@dont-email.me> |
| In reply to | #402264 |
On 19/09/2026 09:03, Janis Papanagnou wrote: > On 2026-09-18 11:37, David Brown wrote: >> On 18/09/2026 09:10, Janis Papanagnou wrote: >>> On 2026-09-15 12:53, David Brown wrote: >>>> On 15/09/2026 11:51, Janis Papanagnou wrote: >>> [...] >>>> >>>> And we all know we should be writing "if (a == 5)", with decent >>>> spacing :-) >>> >>> Sure. Above was just a deliberate terse form for inline reference. >>> Usually I'm using probably more spacing inline and between lines >>> and chapters than the average programmer would find tolerable. ;-) >> >> I like space - it aids legibility. There's a reason the biggest key >> on the keyboard is the spacebar, and the second biggest is the return >> key. > > And the third biggest the Backspace key to quickly erase all this > ugly code we wrote? ;-) > :-) >>> >>> Yes, things have gotten much better since the dates back then when >>> I did my professional programming in C/C++. >>> >> >> Tools have certainly got better, but the default warnings in compilers >> progress much too slowly IMHO. (Of course I can enable all the >> warning flags I like for my own use - but I'd prefer if everyone else >> used them more!) > > Well, I cannot really tell about the more recent behaviors. All I > noticed was that I've got (or could enable) more diagnostics than > in earlier days, and that the information got better (in content > and in display representation) - it would certainly be bad if it > were otherwise. > Absolutely - warnings of all sorts have got better over time in gcc. But I would like to see more of them enabled by default, so that common mistakes are unavoidably identified. (Though I understand why the gcc developers are conservative here.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-05 01:57 +0000 |
| Message-ID | <119v073$ekf9$2@dont-email.me> |
| In reply to | #402064 |
On Mon, 14 Sep 2026 20:21:51 +0200, tTh wrote:
> About braces, I always use them except in one case : when the code
> fragment is on the same line as the if.
>
> if (retval) fprintf(stderr, "retval is %d\n", retval);
>
> I think it's dangerous, but for some little things like my sample, it
> make things clearer for me.
Interesting that Perl decided to never allow the braces to be
optional.
Myself, the only exception I make is if the statement is just a break:
if («cond»)
break;
and even then, I put it on a line by itself.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-14 18:54 +0000 |
| Message-ID | <KpXpS.53755$k62.39083@fx14.iad> |
| In reply to | #402062 |
David Brown <david.brown@hesbynett.no> writes:
>On 14/09/2026 17:01, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>>> Personally, I tend to prefer the non-C delimited approach, since
>>> it's a bit less error-prone, but both approaches are perfectly
>>> valid and can be used cleanly and correctly with a little care.
>>> It's not a factor I consider when deciding which language to use.
>>
>> I simply always use braces, regardless of whether or not
>> the clause contains a single statement or a compound statement.
>>
>
>That's always a safe choice, but some C programmers prefer to use fewer
>braces. A compromise is to insist on always using braces if there is an
>"else" clause (in both the "if" and "else" parts), or at the very least,
>to do so if there are nested "if" statements.
>
>Always using braces (combined with a consistent indent style) is the
>choice with the lowest risk of mistakes or misinterpretation, and means
>that changes such as adding or removing statements to the controlled
>parts do not lead to additional changes. For anyone using version
>control systems, the advantage of :
>
> if (test) {
> do_this();
> }
>
>over :
>
> if (test)
> do_this();
>
>is obvious the first time they need to change the code to :
>
> if (test) {
> do_this();
> do_that();
> }
>
That's true for anyone still using 80-column punched cards
(or ancient line-oriented editors) as well.
:-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-14 22:55 +0200 |
| Message-ID | <1189n0p$1svho$2@dont-email.me> |
| In reply to | #402065 |
On 14/09/2026 20:54, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/09/2026 17:01, Scott Lurndal wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>>> Personally, I tend to prefer the non-C delimited approach, since
>>>> it's a bit less error-prone, but both approaches are perfectly
>>>> valid and can be used cleanly and correctly with a little care.
>>>> It's not a factor I consider when deciding which language to use.
>>>
>>> I simply always use braces, regardless of whether or not
>>> the clause contains a single statement or a compound statement.
>>>
>>
>> That's always a safe choice, but some C programmers prefer to use fewer
>> braces. A compromise is to insist on always using braces if there is an
>> "else" clause (in both the "if" and "else" parts), or at the very least,
>> to do so if there are nested "if" statements.
>>
>> Always using braces (combined with a consistent indent style) is the
>> choice with the lowest risk of mistakes or misinterpretation, and means
>> that changes such as adding or removing statements to the controlled
>> parts do not lead to additional changes. For anyone using version
>> control systems, the advantage of :
>>
>> if (test) {
>> do_this();
>> }
>>
>> over :
>>
>> if (test)
>> do_this();
>>
>> is obvious the first time they need to change the code to :
>>
>> if (test) {
>> do_this();
>> do_that();
>> }
>>
>
> That's true for anyone still using 80-column punched cards
> (or ancient line-oriented editors) as well.
>
> :-)
I don't quite follow you. (I use line lengths up to perhaps 120
characters, but not rigidly fixed.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-14 21:03 +0000 |
| Message-ID | <YiZpS.10983$HXQd.4881@fx06.iad> |
| In reply to | #402072 |
David Brown <david.brown@hesbynett.no> writes:
>On 14/09/2026 20:54, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 14/09/2026 17:01, Scott Lurndal wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>>> Personally, I tend to prefer the non-C delimited approach, since
>>>>> it's a bit less error-prone, but both approaches are perfectly
>>>>> valid and can be used cleanly and correctly with a little care.
>>>>> It's not a factor I consider when deciding which language to use.
>>>>
>>>> I simply always use braces, regardless of whether or not
>>>> the clause contains a single statement or a compound statement.
>>>>
>>>
>>> That's always a safe choice, but some C programmers prefer to use fewer
>>> braces. A compromise is to insist on always using braces if there is an
>>> "else" clause (in both the "if" and "else" parts), or at the very least,
>>> to do so if there are nested "if" statements.
>>>
>>> Always using braces (combined with a consistent indent style) is the
>>> choice with the lowest risk of mistakes or misinterpretation, and means
>>> that changes such as adding or removing statements to the controlled
>>> parts do not lead to additional changes. For anyone using version
>>> control systems, the advantage of :
>>>
>>> if (test) {
>>> do_this();
>>> }
>>>
>>> over :
>>>
>>> if (test)
>>> do_this();
>>>
>>> is obvious the first time they need to change the code to :
>>>
>>> if (test) {
>>> do_this();
>>> do_that();
>>> }
>>>
>>
>> That's true for anyone still using 80-column punched cards
>> (or ancient line-oriented editors) as well.
>>
>> :-)
>
>I don't quite follow you. (I use line lengths up to perhaps 120
>characters, but not rigidly fixed.)
If the braces weren't there in the original source, one would
need to repunch one card and add two[*]. Rather than just
sliding the one new card in the appropriate place in the deck.
Likewise with a line-mode editor - you'd need to edit three lines
instead of adding one.
>
[*] or add three cards instead of modifying the if card.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-15 00:33 +0200 |
| Message-ID | <1189sn1$15ig9$1@dont-email.me> |
| In reply to | #402065 |
On 2026-09-14 20:54, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/09/2026 17:01, Scott Lurndal wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>>> Personally, I tend to prefer the non-C delimited approach, since
>>>> it's a bit less error-prone, but both approaches are perfectly
>>>> valid and can be used cleanly and correctly with a little care.
>>>> It's not a factor I consider when deciding which language to use.
>>>
>>> I simply always use braces, regardless of whether or not
>>> the clause contains a single statement or a compound statement.
>>>
>>
>> That's always a safe choice, but some C programmers prefer to use fewer
>> braces. A compromise is to insist on always using braces if there is an
>> "else" clause (in both the "if" and "else" parts), or at the very least,
>> to do so if there are nested "if" statements.
>>
>> Always using braces (combined with a consistent indent style) is the
>> choice with the lowest risk of mistakes or misinterpretation, and means
>> that changes such as adding or removing statements to the controlled
>> parts do not lead to additional changes. For anyone using version
>> control systems, the advantage of :
>>
>> if (test) {
>> do_this();
>> }
>>
>> over :
>>
>> if (test)
>> do_this();
>>
>> is obvious the first time they need to change the code to :
>>
>> if (test) {
>> do_this();
>> do_that();
>> }
I sometimes hear that as argument but to me it had never been a
convincing one. - If I change my program in any way, complex or
(as here) trivially, I always inspect the context and make the
necessary adjustments. For me there's no need to add spurious
syntactical elements, visually polluting ballast, in the first
place. YMMV.
It's another thing if one is working in a collaborative context,
and/or using an "IDE" that will automatically create appropriate
(though still spurious) braces when you enter keywords.
>
> That's true for anyone still using 80-column punched cards
> (or ancient line-oriented editors) as well.
>
> :-)
Okay, I see the smiley, but I don't see the relation to what was
quoted.
Concerning your statement per se; restricting your column-width
in programs adds to legibility! - I recall my *cough* Java times
where line lengths of a (rare) minimum of 120, and more typical
lengths of 160-200+, was the "standard" - code really horrible to
read.
Personally I use the classical 80-column width as _soft hint_ that
I try to not exceed. - A quick browse over some sources shows that
typical lengths of the longer lines are around 50-60 columns, and
lines >80 are rare, and >100 even much rarer.
BTW, yes I've used punch-cards (and still have a stack somewhere)
but the habit of using not too long lines did not stem from there.
It is just a matter of legibility (and thus maintenance); again,
beyond personal preferences, especially in collaborative working
environments.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-13 10:50 +0200 |
| Message-ID | <1185o4m$eof6$1@dont-email.me> |
| In reply to | #402005 |
On 12/09/2026 19:58, bart wrote: (Snipping lots of good points about language design - I don't want to discuss fir's hypothetical language, but I can still give you a little more information on a C point.) > > * The function doesn't use an unspecified parameter list (this was a > feature of C but C23 may have deprecated that) The use of non-prototype function declarations (including implicit ones) was marked as an "obsolescent" feature in C90. (That is, if I understand correctly, it was not actually deprecated but was planned to be deprecated in the near future). C23 skipped deprecation entirely and removed it from the language. (I think most C programmers see that as absurdly slow timing from the C standards committee and C compiler implementers. I only know of one C expert who thought non-prototype function declarations were useful to keep around, and I don't think he ever gave a good reason for that.)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 12:32 +0200 |
| Message-ID | <1185u4g$heq5$1@dont-email.me> |
| In reply to | #402017 |
David Brown pisze: > On 12/09/2026 19:58, bart wrote: > > (Snipping lots of good points about language design - I don't want to > discuss fir's hypothetical language, but I can still give you a little > more information on a C point.) > >> >> * The function doesn't use an unspecified parameter list (this was a >> feature of C but C23 may have deprecated that) > > The use of non-prototype function declarations (including implicit ones) > was marked as an "obsolescent" feature in C90. (That is, if I > understand correctly, it was not actually deprecated but was planned to > be deprecated in the near future). C23 skipped deprecation entirely and > removed it from the language. (I think most C programmers see that as > absurdly slow timing from the C standards committee and C compiler > implementers. I only know of one C expert who thought non-prototype > function declarations were useful to keep around, and I don't think he > ever gave a good reason for that.) > i was thinking about possible usage of this thinghbut dont see clearly many..its maybe weird as it seem tit should be some more probably i see as to thios global tmp ram record which you cn at least use to pass values among f(); b(); with no passing arguments //via this tmp global ram
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 20:15 +0200 |
| Message-ID | <11844rk$5uv$1@dont-email.me> |
| In reply to | #402002 |
fir pisze:
>
> no worry , definitions wouldnt help here
>
> this above is obviously non possible you cant have unary and binary
> here (as far as it seems, i may be maybe wrong)
>
> a*b must be binary if *b would be unary then it mean you have
>
> a *b so its ambiguity , so there some additional rule would need to be
> used at least
>
> rule can be
>
> a*b // is binary
> a(*b) //is unary
> (a*)b //is unary
>
> this touches some problem becouse it blocks a(b) syntax which eventually
> could be usefull, but it eventually may be seen not much usefull
> as i see () more like separators not 'calling' operator
> (it only be blocked for those types of ab though not necessary for
> fiunction calls
>
> there is also option to use this space as a seperator ..this kind of
> mmeaningfull spaces i use here all time for example in a b c d
> apaces are meaningfull coz its not ab c d
>
> so a *b wouldnt be considered good idea but a (*b) being different than
> a(*b) may be (but VERY eventually)
>
overally the question if to allow a(b) as a syntax is by chance good
question
it is mostly eventually needed from traditional reasons
f(a) [4 chars] is also maybe shorter than (f a)[5 chars] but longer than
f a [3 chars]
some coud say fthat f(a)f(a)f(a)f(a) wins over (f a)(f a)(f a) and
equals with f a f a f a f a f a, hard to say at this moment
f(a) probabably could be allowed but if so probably tha lack of space
would be meaningfull at least for some types
i cant say yet for sure in this case.. problem is imo
f(a) is in fact more misleading than helpfull
some really do like
print("ass " foo(x y) sin(x))
over more logical
print "ass" (foo x y)(sin x)
over a cleaner
print "ass" foo x y sin x
esp as free spaces may be added for clarity
print "ass" foo x y sin x
there ere many unicode eventuals separators for optional usage
for someone who need it in some cases but not for general usage imo but
an option
not this above but something could ba taken but
1) FOR OPTIONAL USAGE ONLY
2) NOT , MUST BE SOMETHING OTHER
for example those circles (bullets) i generally find more suitable for
denoting definitions
○ foo
x = 28
○ bar
print "ataa"
○ zoo { sin x}
some liek python keyword def but shorter
Ↄ ya!
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 19:34 +0200 |
| Message-ID | <11842el$3v96g$1@dont-email.me> |
| In reply to | #402000 |
bart pisze: > Sure, but what happens when someone /wants/ to have user-define types? > So in general it is ambiguous. > > In C you can also have a parameter list which has only types, no > parameter names. If that is still a feature, then: > > (a, b, c, d); > > can be assumed (by the reader) to be all types. But this: > > (a b c d) > > is more ambiguous; how many parameters are there: is it 4 (abcd are all > types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are > names)? Other combinations may be possible. this one i dont understand whats difference id someone uses like structure nameinstead of int? no difference and if ou see such thing as int int a b foo float do i ask you how many type names are there? how many wariables and how many function names? note in code if it is not obfuscated names are meaningfull, type names are not popular ther repeat and you know them generally function names are usualy verbs (i write is mostly in big letter, variables i personally always write low leter) some functions i write low letter but those very qshort very quick usage one like sin strcmp print - only few things like that
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-12 19:39 +0200 |
| Message-ID | <11842ov$3vcad$1@dont-email.me> |
| In reply to | #402003 |
fir pisze: > bart pisze: >> Sure, but what happens when someone /wants/ to have user-define types? >> So in general it is ambiguous. >> >> In C you can also have a parameter list which has only types, no >> parameter names. If that is still a feature, then: >> >> (a, b, c, d); >> >> can be assumed (by the reader) to be all types. But this: >> >> (a b c d) >> >> is more ambiguous; how many parameters are there: is it 4 (abcd are >> all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are >> names)? Other combinations may be possible. > > this one i dont understand whats difference id someone uses like > structure nameinstead of int? > > no difference > > and if ou see such thing as int int a b foo float > do i ask you how many type names are there? how many wariables and how > many function names? > > note in code if it is not obfuscated names are meaningfull, type names > are not popular ther repeat and you know them generally function names > are usualy verbs (i write is mostly in big letter, variables i > personally always write low leter) > > some functions i write low letter but those very qshort very quick usage > one like sin strcmp print - only few things like that > obviously your not obliged to understand that (i mean this new naked/no gothic clothes) syntax its maybe better people dont understand that it maybe mnimalises chanse someone would take that valueable syntax results and implement it and not adress (credt) me an propar author of this stuff its not that those results are not to take, they may be taken but thecredits should be done just to make historical acuracy of some solutions not spreading lies (and filling history with lies (yawn) i think its understood
[toc] | [prev] | [next] | [standalone]
Page 11 of 25 — ← Prev page 1 … 9 10 [11] 12 13 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web