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 10 of 25 — ← Prev page 1 … 8 9 [10] 11 12 … 25 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 13:11 +0200 |
| Message-ID | <11860d2$i5ja$1@dont-email.me> |
| In reply to | #402025 |
fir pisze: > esp this 𝒙10 is clean and weighty i got a lot of problems with this > becouse x10 eventually worked but has terrible disadwantage xa is not > standable (a is variable value say 100) but unicode resolves a lot of > problems coz 𝒙a work > > NOTE this all now seem obvious but before discovering this what seems > obvious LATER BEFORE this all conclusions was VERY FAR form obvious you by chance illustrate this problem you in fact has notably more feel in this things as average comp.lang.c user (as seen the fight with you statements often true but you itself when confronted with better sollution not only not take it but also fights with it this illustrates how indeed far from this solution are nearly all people ;c (so rare i dont know none who is close but maybe some are hidden in some mountains ;c wtill my solutions are oryginal as i dont know no one who is doin something close as me here)
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-13 05:29 -0600 |
| Message-ID | <11861f0$iim0$1@dont-email.me> |
| In reply to | #402022 |
bart wrote: > On 13/09/2026 10:53, fir wrote: >> fir pisze: >>> bart pisze: > >>>> It sounds like your ideal language would be APL, if is not 'clean' >>>> and 'clear' that you're after, but 'minimal' and 'cryptic'. >>>> >>>> The first version above is the best balance in my view. You /want/ >>>> some mixture of keywords and symbols. >>>> >>>> In any case, in a typical program, only 1/3 of alphanumerics of >>>> keywords; the rest will still be user-identifiers. >>> >>> >>> i gave you example - its only cryptic if you dont know what it means >>> >>> >> consider for example french or polish language its totally cryptic >> until you will learn it... > > > That is not your aim. That appears to be to start with a language that > you know perfectly well, but remove all punctuation, capitalisation and > structure, and half the words. But to what purpose; because you're too > lazy to type? > > not to say you want to understand it without >> definitions > > So an APL (or J or K) program is never cryptic because all you have to > do is learn it? If only I'd thought of that! > > The same applies to Assembly I guess. And machine code? > >> >> overally this discussin ended i think at least as for few months, >> cant continue becouse you repeat the same things > > And you keep repeating the same nonsense. What is your endpoint: a > program that can be expressed in one byte? > He wants to compress the language, metaphor a plum, into a prune that has much reduced. It is the same way with a newsgroup when the warlord Lane W has compressed all the shitheads, David Brown, Keith, bart, and the rest except I guess the fellows who are in the mood, when they all conspire by email to not respond to anything he writes. It is at such a time that he declares victory. As I roll over yet another group in the 97 I have subjugated to my rule and made complacent, a tear drips from my eye. C, such a beautiful language, yet what hypocrites such as David Brown defending it. Really, nothing personal? I beg to differ. Under my boot, a serpent crawls out of the skull of another victim.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 13:43 +0200 |
| Message-ID | <118628u$irqm$1@dont-email.me> |
| In reply to | #402029 |
Lane W pisze: > bart wrote: >> On 13/09/2026 10:53, fir wrote: >>> fir pisze: >>>> bart pisze: >> >>>>> It sounds like your ideal language would be APL, if is not 'clean' >>>>> and 'clear' that you're after, but 'minimal' and 'cryptic'. >>>>> >>>>> The first version above is the best balance in my view. You /want/ >>>>> some mixture of keywords and symbols. >>>>> >>>>> In any case, in a typical program, only 1/3 of alphanumerics of >>>>> keywords; the rest will still be user-identifiers. >>>> >>>> >>>> i gave you example - its only cryptic if you dont know what it means >>>> >>>> >>> consider for example french or polish language its totally cryptic >>> until you will learn it... >> >> >> That is not your aim. That appears to be to start with a language that >> you know perfectly well, but remove all punctuation, capitalisation >> and structure, and half the words. But to what purpose; because you're >> too lazy to type? >> >> not to say you want to understand it without >>> definitions >> >> So an APL (or J or K) program is never cryptic because all you have to >> do is learn it? If only I'd thought of that! >> >> The same applies to Assembly I guess. And machine code? >> >>> >>> overally this discussin ended i think at least as for few months, >>> cant continue becouse you repeat the same things >> >> And you keep repeating the same nonsense. What is your endpoint: a >> program that can be expressed in one byte? >> > He wants to compress the language, metaphor a plum, into a prune that > has much reduced. > > It is the same way with a newsgroup when the warlord Lane W has > compressed all the shitheads, David Brown, Keith, bart, and the rest > except I guess the fellows who are in the mood, when they all conspire > by email to not respond to anything he writes. It is at such a time that > he declares victory. As I roll over yet another group in the 97 I have > subjugated to my rule and made complacent, a tear drips from my eye. C, > such a beautiful language, yet what hypocrites such as David Brown > defending it. Really, nothing personal? I beg to differ. Under my boot, > a serpent crawls out of the skull of another victim. no worry its hard to answer this becouse its hard to know what exactly tis is about but it sometimes have some points (you will need hovever care not to overdo it..becouse as i said when commenting some people with sticks up in their asses some such type coments are fun but if there is to much of cross boundering there may haos os spam do appear and that is harmfull
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-09-13 14:00 -0700 |
| Message-ID | <11872sr$v3ni$1@dont-email.me> |
| In reply to | #402029 |
On 9/13/2026 4:29 AM, Lane W wrote: > bart wrote: >> On 13/09/2026 10:53, fir wrote: >>> fir pisze: >>>> bart pisze: >> >>>>> It sounds like your ideal language would be APL, if is not 'clean' >>>>> and 'clear' that you're after, but 'minimal' and 'cryptic'. >>>>> >>>>> The first version above is the best balance in my view. You /want/ >>>>> some mixture of keywords and symbols. >>>>> >>>>> In any case, in a typical program, only 1/3 of alphanumerics of >>>>> keywords; the rest will still be user-identifiers. >>>> >>>> >>>> i gave you example - its only cryptic if you dont know what it means >>>> >>>> >>> consider for example french or polish language its totally cryptic >>> until you will learn it... >> >> >> That is not your aim. That appears to be to start with a language that >> you know perfectly well, but remove all punctuation, capitalisation >> and structure, and half the words. But to what purpose; because you're >> too lazy to type? >> >> not to say you want to understand it without >>> definitions >> >> So an APL (or J or K) program is never cryptic because all you have to >> do is learn it? If only I'd thought of that! >> >> The same applies to Assembly I guess. And machine code? >> >>> >>> overally this discussin ended i think at least as for few months, >>> cant continue becouse you repeat the same things >> >> And you keep repeating the same nonsense. What is your endpoint: a >> program that can be expressed in one byte? >> > He wants to compress the language, metaphor a plum, into a prune that > has much reduced. Take a source file, compress it, and show all the printable chars from the blob? ;^) > > It is the same way with a newsgroup when the warlord Lane W has > compressed all the shitheads, David Brown, Keith, bart, and the rest > except I guess the fellows who are in the mood, when they all conspire > by email to not respond to anything he writes. It is at such a time that > he declares victory. As I roll over yet another group in the 97 I have > subjugated to my rule and made complacent, a tear drips from my eye. C, > such a beautiful language, yet what hypocrites such as David Brown > defending it. Really, nothing personal? I beg to differ. Under my boot, > a serpent crawls out of the skull of another victim.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2026-09-13 10:53 +0000 |
| Message-ID | <slrn11ad05a.mc7.ike@iceland.freeshell.org> |
| In reply to | #402010 |
On 2026-09-12, bart <bc@freeuk.com> wrote:
> Note that the code will still have braces. I suggest a better aim is to
> eliminate most braces. The should be no need to ever see '} else {'
> instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
if (0) { if (1) puts("foo"); else puts("bar"); }
if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-13 13:46 +0100 |
| Message-ID | <11865vo$k4bm$1@dont-email.me> |
| In reply to | #402026 |
On 13/09/2026 11:53, Ike Naar wrote:
> On 2026-09-12, bart <bc@freeuk.com> wrote:
>> Note that the code will still have braces. I suggest a better aim is to
>> eliminate most braces. The should be no need to ever see '} else {'
>> instead of just 'else'.
>
> There can be a difference; for example (assume <stdio.h> included):
>
> if (0) { if (1) puts("foo"); else puts("bar"); }
>
> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>
> The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else' can
act as block delimiters:
if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for statements
and expressions to run together provided that there is a way to infer
where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 15:21 +0200 |
| Message-ID | <118680j$ks5k$1@dont-email.me> |
| In reply to | #402031 |
bart pisze:
> On 13/09/2026 11:53, Ike Naar wrote:
>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>> Note that the code will still have braces. I suggest a better aim is to
>>> eliminate most braces. The should be no need to ever see '} else {'
>>> instead of just 'else'.
>>
>> There can be a difference; for example (assume <stdio.h> included):
>>
>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>
>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>
>> The first line will print nothing; the second one will print "bar".
>
>
> This illustrates my point; first some Pascal:
>
> if cond then begin s1; s2 end else begin s3; s4 end
>
> C is the same but uses braces, and semicolons are terminators:
>
> if (cond) { s1; s2; } else { s3; s4; }
>
> One has 'end else begin', the other has '} else {'.
>
> However the Pascal version can be improved; since 'then' and 'else' can
> act as block delimiters:
>
> if cond then s1; s2 end else s3; s4 end
>
> Only the final block in a chain (eg. if-else-if) needs the 'end'
> terminator. And now 'else' is by itself.
>
> Unfortunately this doesn't transfer well to C:
>
> if (cond) s1; s2; else s3; s4; }
>
> The () around 'cond' are needed as the ')' separates cond and s1 (fir
> doesn't not appreciate this point; he thinks it is fine for statements
> and expressions to run together provided that there is a way to infer
> where one logically ends and the other starts).
>
> The trouble is that lone, unbalanced } at the end.
>
> So it would need a bigger change. But then that's what fir is doing.
> (He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 → x++>5
→ more_than_five
↘ less_than_six
↘ do_nothing
those → ale also sorta redundant
x<10 x++>5 more_than_five ↘ less_than_six ↘ do_nothing
can optionally ad parenthesis or braces for clarity
x<10 (x++>5 more_than_five ↘ less_than_six) ↘ do_nothing
x<10 {x++>5 more_than_five ↘ less_than_six } ↘ do_nothing
but im not fully convinced
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-13 15:31 +0100 |
| Message-ID | <1186c3k$me64$1@dont-email.me> |
| In reply to | #402033 |
On 13/09/2026 14:21, fir wrote:
> bart pisze:
>> On 13/09/2026 11:53, Ike Naar wrote:
>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>> Note that the code will still have braces. I suggest a better aim is to
>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>> instead of just 'else'.
>>>
>>> There can be a difference; for example (assume <stdio.h> included):
>>>
>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>
>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>
>>> The first line will print nothing; the second one will print "bar".
>>
>>
>> This illustrates my point; first some Pascal:
>>
>> if cond then begin s1; s2 end else begin s3; s4 end
>>
>> C is the same but uses braces, and semicolons are terminators:
>>
>> if (cond) { s1; s2; } else { s3; s4; }
>>
>> One has 'end else begin', the other has '} else {'.
>>
>> However the Pascal version can be improved; since 'then' and 'else'
>> can act as block delimiters:
>>
>> if cond then s1; s2 end else s3; s4 end
>>
>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>> terminator. And now 'else' is by itself.
>>
>> Unfortunately this doesn't transfer well to C:
>>
>> if (cond) s1; s2; else s3; s4; }
>>
>> The () around 'cond' are needed as the ')' separates cond and s1 (fir
>> doesn't not appreciate this point; he thinks it is fine for statements
>> and expressions to run together provided that there is a way to infer
>> where one logically ends and the other starts).
>>
>> The trouble is that lone, unbalanced } at the end.
>>
>> So it would need a bigger change. But then that's what fir is doing.
>> (He's never going to get there, but there's no harm in humouring him.)
>
>
> what you consider problems is so siple i dont even think on it
>
>
> as to ifs syntax i am yet not sure
>
> some like this may be considered but its not much good loking
> though is sorta logical
>
> x<10 → x++>5
> → more_than_five
> ↘ less_than_six
> ↘ do_nothing
Try: if 5 < x < 10.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 16:34 +0200 |
| Message-ID | <1186c9e$mfbg$1@dont-email.me> |
| In reply to | #402035 |
bart pisze:
> On 13/09/2026 14:21, fir wrote:
>> bart pisze:
>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>> Note that the code will still have braces. I suggest a better aim
>>>>> is to
>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>> instead of just 'else'.
>>>>
>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>
>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>
>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>
>>>> The first line will print nothing; the second one will print "bar".
>>>
>>>
>>> This illustrates my point; first some Pascal:
>>>
>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>
>>> C is the same but uses braces, and semicolons are terminators:
>>>
>>> if (cond) { s1; s2; } else { s3; s4; }
>>>
>>> One has 'end else begin', the other has '} else {'.
>>>
>>> However the Pascal version can be improved; since 'then' and 'else'
>>> can act as block delimiters:
>>>
>>> if cond then s1; s2 end else s3; s4 end
>>>
>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>> terminator. And now 'else' is by itself.
>>>
>>> Unfortunately this doesn't transfer well to C:
>>>
>>> if (cond) s1; s2; else s3; s4; }
>>>
>>> The () around 'cond' are needed as the ')' separates cond and s1 (fir
>>> doesn't not appreciate this point; he thinks it is fine for
>>> statements and expressions to run together provided that there is a
>>> way to infer where one logically ends and the other starts).
>>>
>>> The trouble is that lone, unbalanced } at the end.
>>>
>>> So it would need a bigger change. But then that's what fir is doing.
>>> (He's never going to get there, but there's no harm in humouring him.)
>>
>>
>> what you consider problems is so siple i dont even think on it
>>
>>
>> as to ifs syntax i am yet not sure
>>
>> some like this may be considered but its not much good loking
>> though is sorta logical
>>
>> x<10 → x++>5
>> → more_than_five
>> ↘ less_than_six
>> ↘ do_nothing
>
> Try: if 5 < x < 10.
>
why? its the same
5<x<10 →
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 16:58 +0200 |
| Message-ID | <1186dna$n0so$1@dont-email.me> |
| In reply to | #402036 |
fir pisze:
> bart pisze:
>> On 13/09/2026 14:21, fir wrote:
>>> bart pisze:
>>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>>> Note that the code will still have braces. I suggest a better aim
>>>>>> is to
>>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>>> instead of just 'else'.
>>>>>
>>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>>
>>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>>
>>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>>
>>>>> The first line will print nothing; the second one will print "bar".
>>>>
>>>>
>>>> This illustrates my point; first some Pascal:
>>>>
>>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>>
>>>> C is the same but uses braces, and semicolons are terminators:
>>>>
>>>> if (cond) { s1; s2; } else { s3; s4; }
>>>>
>>>> One has 'end else begin', the other has '} else {'.
>>>>
>>>> However the Pascal version can be improved; since 'then' and 'else'
>>>> can act as block delimiters:
>>>>
>>>> if cond then s1; s2 end else s3; s4 end
>>>>
>>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>>> terminator. And now 'else' is by itself.
>>>>
>>>> Unfortunately this doesn't transfer well to C:
>>>>
>>>> if (cond) s1; s2; else s3; s4; }
>>>>
>>>> The () around 'cond' are needed as the ')' separates cond and s1
>>>> (fir doesn't not appreciate this point; he thinks it is fine for
>>>> statements and expressions to run together provided that there is a
>>>> way to infer where one logically ends and the other starts).
>>>>
>>>> The trouble is that lone, unbalanced } at the end.
>>>>
>>>> So it would need a bigger change. But then that's what fir is doing.
>>>> (He's never going to get there, but there's no harm in humouring him.)
>>>
>>>
>>> what you consider problems is so siple i dont even think on it
>>>
>>>
>>> as to ifs syntax i am yet not sure
>>>
>>> some like this may be considered but its not much good loking
>>> though is sorta logical
>>>
>>> x<10 → x++>5
>>> → more_than_five
>>> ↘ less_than_six
>>> ↘ do_nothing
>>
>> Try: if 5 < x < 10.
>
>>
> why? its the same
>
>
> 5<x<10 →
>
interesting problem is if
a→b→c→d→ all must be tru to go here
so how to implement or this way
a↘b↘c↘d↘ {all must be false to go here}
{or would be here it seems but you may go here also after false
and it has no end/delimiter so it needs something..}
so maybe or is
(a↘b↘c↘d↘)↘ { or is here? }
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-13 18:01 +0100 |
| Message-ID | <1186ksc$prj7$1@dont-email.me> |
| In reply to | #402036 |
On 13/09/2026 15:34, fir wrote:
> bart pisze:
>> On 13/09/2026 14:21, fir wrote:
>>> bart pisze:
>>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>>> Note that the code will still have braces. I suggest a better aim
>>>>>> is to
>>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>>> instead of just 'else'.
>>>>>
>>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>>
>>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>>
>>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>>
>>>>> The first line will print nothing; the second one will print "bar".
>>>>
>>>>
>>>> This illustrates my point; first some Pascal:
>>>>
>>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>>
>>>> C is the same but uses braces, and semicolons are terminators:
>>>>
>>>> if (cond) { s1; s2; } else { s3; s4; }
>>>>
>>>> One has 'end else begin', the other has '} else {'.
>>>>
>>>> However the Pascal version can be improved; since 'then' and 'else'
>>>> can act as block delimiters:
>>>>
>>>> if cond then s1; s2 end else s3; s4 end
>>>>
>>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>>> terminator. And now 'else' is by itself.
>>>>
>>>> Unfortunately this doesn't transfer well to C:
>>>>
>>>> if (cond) s1; s2; else s3; s4; }
>>>>
>>>> The () around 'cond' are needed as the ')' separates cond and s1
>>>> (fir doesn't not appreciate this point; he thinks it is fine for
>>>> statements and expressions to run together provided that there is a
>>>> way to infer where one logically ends and the other starts).
>>>>
>>>> The trouble is that lone, unbalanced } at the end.
>>>>
>>>> So it would need a bigger change. But then that's what fir is doing.
>>>> (He's never going to get there, but there's no harm in humouring him.)
>>>
>>>
>>> what you consider problems is so siple i dont even think on it
>>>
>>>
>>> as to ifs syntax i am yet not sure
>>>
>>> some like this may be considered but its not much good loking
>>> though is sorta logical
>>>
>>> x<10 → x++>5
>>> → more_than_five
>>> ↘ less_than_six
>>> ↘ do_nothing
>>
>> Try: if 5 < x < 10.
>
>>
> why? its the same
>
The same as ... what?
I don't know what your example was meant to do. But if testing whether x
was in some interval, and with my example 'x' is only written once.
Otherwise you might want to look at how lots of languages do more
general pattern-matching.>
> 5<x<10 →
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 21:14 +0200 |
| Message-ID | <1186sms$squk$1@dont-email.me> |
| In reply to | #402043 |
bart pisze:
> On 13/09/2026 15:34, fir wrote:
>> bart pisze:
>>> On 13/09/2026 14:21, fir wrote:
>>>> bart pisze:
>>>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>>>> Note that the code will still have braces. I suggest a better aim
>>>>>>> is to
>>>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>>>> instead of just 'else'.
>>>>>>
>>>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>>>
>>>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>>>
>>>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>>>
>>>>>> The first line will print nothing; the second one will print "bar".
>>>>>
>>>>>
>>>>> This illustrates my point; first some Pascal:
>>>>>
>>>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>>>
>>>>> C is the same but uses braces, and semicolons are terminators:
>>>>>
>>>>> if (cond) { s1; s2; } else { s3; s4; }
>>>>>
>>>>> One has 'end else begin', the other has '} else {'.
>>>>>
>>>>> However the Pascal version can be improved; since 'then' and 'else'
>>>>> can act as block delimiters:
>>>>>
>>>>> if cond then s1; s2 end else s3; s4 end
>>>>>
>>>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>>>> terminator. And now 'else' is by itself.
>>>>>
>>>>> Unfortunately this doesn't transfer well to C:
>>>>>
>>>>> if (cond) s1; s2; else s3; s4; }
>>>>>
>>>>> The () around 'cond' are needed as the ')' separates cond and s1
>>>>> (fir doesn't not appreciate this point; he thinks it is fine for
>>>>> statements and expressions to run together provided that there is a
>>>>> way to infer where one logically ends and the other starts).
>>>>>
>>>>> The trouble is that lone, unbalanced } at the end.
>>>>>
>>>>> So it would need a bigger change. But then that's what fir is
>>>>> doing. (He's never going to get there, but there's no harm in
>>>>> humouring him.)
>>>>
>>>>
>>>> what you consider problems is so siple i dont even think on it
>>>>
>>>>
>>>> as to ifs syntax i am yet not sure
>>>>
>>>> some like this may be considered but its not much good loking
>>>> though is sorta logical
>>>>
>>>> x<10 → x++>5
>>>> → more_than_five
>>>> ↘ less_than_six
>>>> ↘ do_nothing
>>>
>>> Try: if 5 < x < 10.
>>
>>>
>> why? its the same
>>
>
> The same as ... what?
>
> I don't know what your example was meant to do. But if testing whether x
> was in some interval, and with my example 'x' is only written once.
>
> Otherwise you might want to look at how lots of languages do more
> general pattern-matching.>
>> 5<x<10 →
>>
>>
this was not on topic so i dont understand what you mean
on this comparsions 0<=x<640 i was writing already long ago
this example was not on checking x but on if-else forms
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 17:17 +0200 |
| Message-ID | <1186epr$nf9i$1@dont-email.me> |
| In reply to | #402035 |
bart pisze:
> On 13/09/2026 14:21, fir wrote:
>> bart pisze:
>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>> Note that the code will still have braces. I suggest a better aim
>>>>> is to
>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>> instead of just 'else'.
>>>>
>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>
>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>
>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>
>>>> The first line will print nothing; the second one will print "bar".
>>>
>>>
>>> This illustrates my point; first some Pascal:
>>>
>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>
>>> C is the same but uses braces, and semicolons are terminators:
>>>
>>> if (cond) { s1; s2; } else { s3; s4; }
>>>
>>> One has 'end else begin', the other has '} else {'.
>>>
>>> However the Pascal version can be improved; since 'then' and 'else'
>>> can act as block delimiters:
>>>
>>> if cond then s1; s2 end else s3; s4 end
>>>
>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>> terminator. And now 'else' is by itself.
>>>
>>> Unfortunately this doesn't transfer well to C:
>>>
>>> if (cond) s1; s2; else s3; s4; }
>>>
>>> The () around 'cond' are needed as the ')' separates cond and s1 (fir
>>> doesn't not appreciate this point; he thinks it is fine for
>>> statements and expressions to run together provided that there is a
>>> way to infer where one logically ends and the other starts).
>>>
>>> The trouble is that lone, unbalanced } at the end.
>>>
>>> So it would need a bigger change. But then that's what fir is doing.
>>> (He's never going to get there, but there's no harm in humouring him.)
>>
>>
>> what you consider problems is so siple i dont even think on it
>>
>>
>> as to ifs syntax i am yet not sure
>>
>> some like this may be considered but its not much good loking
>> though is sorta logical
>>
>> x<10 → x++>5
>> → more_than_five
>> ↘ less_than_six
>> ↘ do_nothing
>
> Try: if 5 < x < 10.
>
not btw that if you want make much more rigid and more descriptive
language youre obviously fukll right to implement this philosophy im not
denying this
i waguely remember i sad to you something like "try" or "you my try"
giving some of my outcomes as to my philosophy as i assumed you
want to use something good ;c
im joking (imo ofc my philosophy here is better but you may use your own
ofc)
for me your conventions are suboptimal (all those ones who not by chance
are mine own ;c )
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 17:23 +0200 |
| Message-ID | <1186f5m$njt6$1@dont-email.me> |
| In reply to | #402040 |
fir pisze:
> bart pisze:
>> On 13/09/2026 14:21, fir wrote:
>>> bart pisze:
>>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>>> Note that the code will still have braces. I suggest a better aim
>>>>>> is to
>>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>>> instead of just 'else'.
>>>>>
>>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>>
>>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>>
>>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>>
>>>>> The first line will print nothing; the second one will print "bar".
>>>>
>>>>
>>>> This illustrates my point; first some Pascal:
>>>>
>>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>>
>>>> C is the same but uses braces, and semicolons are terminators:
>>>>
>>>> if (cond) { s1; s2; } else { s3; s4; }
>>>>
>>>> One has 'end else begin', the other has '} else {'.
>>>>
>>>> However the Pascal version can be improved; since 'then' and 'else'
>>>> can act as block delimiters:
>>>>
>>>> if cond then s1; s2 end else s3; s4 end
>>>>
>>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>>> terminator. And now 'else' is by itself.
>>>>
>>>> Unfortunately this doesn't transfer well to C:
>>>>
>>>> if (cond) s1; s2; else s3; s4; }
>>>>
>>>> The () around 'cond' are needed as the ')' separates cond and s1
>>>> (fir doesn't not appreciate this point; he thinks it is fine for
>>>> statements and expressions to run together provided that there is a
>>>> way to infer where one logically ends and the other starts).
>>>>
>>>> The trouble is that lone, unbalanced } at the end.
>>>>
>>>> So it would need a bigger change. But then that's what fir is doing.
>>>> (He's never going to get there, but there's no harm in humouring him.)
>>>
>>>
>>> what you consider problems is so siple i dont even think on it
>>>
>>>
>>> as to ifs syntax i am yet not sure
>>>
>>> some like this may be considered but its not much good loking
>>> though is sorta logical
>>>
>>> x<10 → x++>5
>>> → more_than_five
>>> ↘ less_than_six
>>> ↘ do_nothing
>>
>> Try: if 5 < x < 10.
>>
> not btw that if you want make much more rigid and more descriptive
> language youre obviously fukll right to implement this philosophy im not
> denying this
>
> i waguely remember i sad to you something like "try" or "you my try"
> giving some of my outcomes as to my philosophy as i assumed you
> want to use something good ;c
>
> im joking (imo ofc my philosophy here is better but you may use your own
> ofc)
>
> for me your conventions are suboptimal (all those ones who not by chance
> are mine own ;c )
>
for me the ones im searching are optimal at least ofr last 'research
state' though i got different worry (on whch i was saint more than one)
c indeed is on some very impressive track to me and im not quite sure
using my filosophy (which is at seen very fractal and syntax
minimalising) is in fact worse than this oryginal "railroad" track
in old c i by chance see something like 'coal' and 'rails'/railroad
feeling and in this mine i see its more like light and plastic 'style'
not so much nice eventually - it worries my but dont know what to do
with that..maybe its too much far form assembly/machine language but
today hard to work in machne language on raw steel and oil machines..
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-13 17:27 +0200 |
| Message-ID | <1186fcd$nm4m$1@dont-email.me> |
| In reply to | #402041 |
fir pisze:
> fir pisze:
>> bart pisze:
>>> On 13/09/2026 14:21, fir wrote:
>>>> bart pisze:
>>>>> On 13/09/2026 11:53, Ike Naar wrote:
>>>>>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>>>>>> Note that the code will still have braces. I suggest a better aim
>>>>>>> is to
>>>>>>> eliminate most braces. The should be no need to ever see '} else {'
>>>>>>> instead of just 'else'.
>>>>>>
>>>>>> There can be a difference; for example (assume <stdio.h> included):
>>>>>>
>>>>>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>>>>>
>>>>>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>>>>>
>>>>>> The first line will print nothing; the second one will print "bar".
>>>>>
>>>>>
>>>>> This illustrates my point; first some Pascal:
>>>>>
>>>>> if cond then begin s1; s2 end else begin s3; s4 end
>>>>>
>>>>> C is the same but uses braces, and semicolons are terminators:
>>>>>
>>>>> if (cond) { s1; s2; } else { s3; s4; }
>>>>>
>>>>> One has 'end else begin', the other has '} else {'.
>>>>>
>>>>> However the Pascal version can be improved; since 'then' and 'else'
>>>>> can act as block delimiters:
>>>>>
>>>>> if cond then s1; s2 end else s3; s4 end
>>>>>
>>>>> Only the final block in a chain (eg. if-else-if) needs the 'end'
>>>>> terminator. And now 'else' is by itself.
>>>>>
>>>>> Unfortunately this doesn't transfer well to C:
>>>>>
>>>>> if (cond) s1; s2; else s3; s4; }
>>>>>
>>>>> The () around 'cond' are needed as the ')' separates cond and s1
>>>>> (fir doesn't not appreciate this point; he thinks it is fine for
>>>>> statements and expressions to run together provided that there is a
>>>>> way to infer where one logically ends and the other starts).
>>>>>
>>>>> The trouble is that lone, unbalanced } at the end.
>>>>>
>>>>> So it would need a bigger change. But then that's what fir is
>>>>> doing. (He's never going to get there, but there's no harm in
>>>>> humouring him.)
>>>>
>>>>
>>>> what you consider problems is so siple i dont even think on it
>>>>
>>>>
>>>> as to ifs syntax i am yet not sure
>>>>
>>>> some like this may be considered but its not much good loking
>>>> though is sorta logical
>>>>
>>>> x<10 → x++>5
>>>> → more_than_five
>>>> ↘ less_than_six
>>>> ↘ do_nothing
>>>
>>> Try: if 5 < x < 10.
>>>
>> not btw that if you want make much more rigid and more descriptive
>> language youre obviously fukll right to implement this philosophy im
>> not denying this
>>
>> i waguely remember i sad to you something like "try" or "you my try"
>> giving some of my outcomes as to my philosophy as i assumed you
>> want to use something good ;c
>>
>> im joking (imo ofc my philosophy here is better but you may use your
>> own ofc)
>>
>> for me your conventions are suboptimal (all those ones who not by
>> chance are mine own ;c )
>>
> for me the ones im searching are optimal at least ofr last 'research
> state' though i got different worry (on whch i was saint more than one)
>
> c indeed is on some very impressive track to me and im not quite sure
> using my filosophy (which is at seen very fractal and syntax
> minimalising) is in fact worse than this oryginal "railroad" track
>
> in old c i by chance see something like 'coal' and 'rails'/railroad
> feeling and in this mine i see its more like light and plastic 'style'
> not so much nice eventually - it worries my but dont know what to do
> with that..maybe its too much far form assembly/machine language but
> today hard to work in machne language on raw steel and oil machines..
so i also not judge your language stylistically - it may heve some
feeling (though i not get this feeling as i dont know it... this feeling
is maybe a part of times where things were used..as c had probably a
feeling of thi 60ties or 70ties in MIT (berkeley?) or something
for ma c has always good 'dark' feeling but all that times was more like
rain night and oxygene feeling that present times... bright lcd plastic
monitors and things
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-13 17:06 -0700 |
| Message-ID | <1187dp9$12auj$1@kst.eternal-september.org> |
| In reply to | #402026 |
Ike Naar <ike@sdf.org> writes:
> On 2026-09-12, bart <bc@freeuk.com> wrote:
>> Note that the code will still have braces. I suggest a better aim is to
>> eliminate most braces. The should be no need to ever see '} else {'
>> instead of just 'else'.
>
> There can be a difference; for example (assume <stdio.h> included):
>
> if (0) { if (1) puts("foo"); else puts("bar"); }
>
> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>
> The first line will print nothing; the second one will print "bar".
I believe bart was suggesting a language change, not offering advice
on how to program in C.
In C, the syntax for an "if" statement is:
if ( expression ) statement
if ( expression ) statement else statement
(C23 tweaks this very slightly in ways that are not relevant to
the current discussion.) Since it's defined in terms of single
statements, if you want multiple statements in a branch you need to
create one by enclosing multiple statements in braces. This also
requires a rule about which "if" a given "else" is associated with.
Many other langauges allow multiple statements where C only allows
a single statement. They typically do so by requiring a closing
delimiter matching the "if", for example "endif", "end if", "end",
or "fi". They also typically add a single token combining "else"
and "if", typically "elseif", "elsif", or "elif".
(Pascal follows the C approach, but spells "{" and "}" as "begin"
and "end".)
It's not practical to follow bart's advice (always use "else" rather
than "} else {" unless you're using some language other than C.
bart's point, I think, is that he dislikes the way C does this.
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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-14 15:01 +0000 |
| Message-ID | <__TpS.4358$Pwy8.4318@fx36.iad> |
| In reply to | #402048 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Ike Naar <ike@sdf.org> writes:
>> On 2026-09-12, bart <bc@freeuk.com> wrote:
>>> Note that the code will still have braces. I suggest a better aim is to
>>> eliminate most braces. The should be no need to ever see '} else {'
>>> instead of just 'else'.
>>
>> There can be a difference; for example (assume <stdio.h> included):
>>
>> if (0) { if (1) puts("foo"); else puts("bar"); }
>>
>> if (0) { if (1) puts("foo"); } else { puts("bar"); }
>>
>> The first line will print nothing; the second one will print "bar".
>
>I believe bart was suggesting a language change, not offering advice
>on how to program in C.
>
>In C, the syntax for an "if" statement is:
>
> if ( expression ) statement
> if ( expression ) statement else statement
>
>(C23 tweaks this very slightly in ways that are not relevant to
>the current discussion.) Since it's defined in terms of single
>statements, if you want multiple statements in a branch you need to
>create one by enclosing multiple statements in braces. This also
>requires a rule about which "if" a given "else" is associated with.
>
>Many other langauges allow multiple statements where C only allows
>a single statement. They typically do so by requiring a closing
>delimiter matching the "if", for example "endif", "end if", "end",
>or "fi". They also typically add a single token combining "else"
>and "if", typically "elseif", "elsif", or "elif".
>
>(Pascal follows the C approach, but spells "{" and "}" as "begin"
>and "end".)
>
>It's not practical to follow bart's advice (always use "else" rather
>than "} else {" unless you're using some language other than C.
>
>bart's point, I think, is that he dislikes the way C does this.
>
>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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-14 18:11 +0200 |
| Message-ID | <11896bm$1lqbn$1@dont-email.me> |
| In reply to | #402058 |
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();
}
Still, the important thing is writing the code in a good, clear manner,
regardless of what the language allows or does not allow.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-09-14 20:21 +0200 |
| Message-ID | <1189dvv$mlc$1@news.gegeweb.eu> |
| In reply to | #402062 |
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 think it's dangerous, but for some little things
like my sample, it make things clearer for me.
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-14 22:54 +0200 |
| Message-ID | <1189mtd$1svho$1@dont-email.me> |
| In reply to | #402064 |
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 think it's dangerous, but for some little things > like my sample, it make things clearer for me. > 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.
[toc] | [prev] | [next] | [standalone]
Page 10 of 25 — ← Prev page 1 … 8 9 [10] 11 12 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web