Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #392008 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2025-04-04 16:23 -0300 |
| Last post | 2025-10-16 00:43 +0100 |
| Articles | 20 on this page of 698 — 31 participants |
Back to article view | Back to comp.lang.c
do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-04 16:23 -0300
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-04 21:18 +0100
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-04 17:31 -0300
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-04 20:34 +0000
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-04 17:37 -0300
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-04 21:01 +0000
Re: do { quit; } else { } "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 14:36 -0700
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-04 20:39 +0000
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-04 17:43 -0300
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-04 17:46 -0300
Re: do { quit; } else { } candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-08 19:00 +0000
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-05 14:54 +0000
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-05 17:54 +0200
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-05 16:10 +0000
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-05 23:37 +0200
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-06 14:41 +0000
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-06 10:52 +0300
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-06 14:45 +0000
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-04 13:48 -0700
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-04 17:58 -0300
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-06 05:47 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-06 16:13 +0300
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-06 07:32 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-06 19:03 +0300
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-07 05:45 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-07 21:02 +0300
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-07 19:31 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-08 10:12 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-08 12:35 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-08 16:50 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-08 17:28 +0100
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 10:32 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-08 19:04 +0100
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 14:18 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-08 23:38 +0100
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 16:27 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-09 01:02 +0100
Re: do { quit; } else { } "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-08 22:55 -0700
Re: do { quit; } else { } "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-08 22:56 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 15:07 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-10 00:49 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 00:20 +0000
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-10 12:08 +0300
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 16:23 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-10 12:00 +0100
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 04:28 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-10 14:34 +0100
Endless complaints [was Re: do { quit; } else { }] scott@slp53.sl.home (Scott Lurndal) - 2025-04-10 14:33 +0000
Re: Endless complaints [was Re: do { quit; } else { }] bart <bc@freeuk.com> - 2025-04-10 16:12 +0100
Re: Endless complaints [was Re: do { quit; } else { }] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-11 00:18 +0200
Re: Endless complaints [was Re: do { quit; } else { }] bart <bc@freeuk.com> - 2025-04-11 00:10 +0100
Re: Endless complaints [was Re: do { quit; } else { }] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 17:41 -0700
Re: Endless complaints [was Re: do { quit; } else { }] Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-11 02:45 +0000
Re: Endless complaints [was Re: do { quit; } else { }] David Brown <david.brown@hesbynett.no> - 2025-04-11 10:14 +0200
Re: Endless complaints [was Re: do { quit; } else { }] bart <bc@freeuk.com> - 2025-04-11 12:32 +0100
Re: Endless complaints [was Re: do { quit; } else { }] Michael S <already5chosen@yahoo.com> - 2025-04-11 14:50 +0300
Re: Endless complaints [was Re: do { quit; } else { }] bart <bc@freeuk.com> - 2025-04-11 12:56 +0100
Re: Endless complaints [was Re: do { quit; } else { }] Michael S <already5chosen@yahoo.com> - 2025-04-11 15:12 +0300
Re: Endless complaints [was Re: do { quit; } else { }] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-11 15:12 +0200
Re: Endless complaints [was Re: do { quit; } else { }] bart <bc@freeuk.com> - 2025-04-11 15:55 +0100
Re: Endless complaints [was Re: do { quit; } else { }] David Brown <david.brown@hesbynett.no> - 2025-04-11 15:02 +0200
Re: Endless complaints Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-11 10:03 -0700
Re: Endless complaints [was Re: do { quit; } else { }] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 12:26 -0700
Re: Endless complaints [was Re: do { quit; } else { }] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 15:27 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 15:23 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 00:49 +0100
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 17:59 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-11 14:26 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 16:11 +0200
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-11 17:22 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 20:46 +0100
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 14:10 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-13 20:45 +0300
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 19:05 -0700
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-12 16:37 +0200
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 13:25 -0700
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-13 11:40 +0200
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-13 20:17 -0400
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 17:51 -0700
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-13 22:23 -0400
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-14 11:07 +0200
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-14 15:03 +0000
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-14 23:17 -0400
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-14 11:22 +0200
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 18:15 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 11:20 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 16:12 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 16:36 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 17:01 -0700
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 16:51 +0000
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-10 18:31 +0000
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 19:14 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-10 19:36 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 19:29 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 00:02 +0100
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-10 18:52 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 20:51 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-10 22:55 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 23:00 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 12:14 +0100
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 22:01 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 21:20 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 21:22 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 21:24 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-10 20:11 +0100
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-11 10:07 -0700
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 16:25 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 15:38 +0100
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 16:42 +0200
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-09 17:43 +0200
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 19:34 -0700
Re: do { quit; } else { } Richard Damon <richard@damon-family.org> - 2025-04-09 07:15 -0400
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 13:51 +0200
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 11:42 +0200
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-09 13:04 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 14:06 +0200
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 12:27 -0400
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-09 13:11 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 14:11 +0200
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-09 13:16 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 14:24 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-09 11:51 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 14:36 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-09 14:13 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 16:00 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-09 16:37 +0100
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-10 20:40 -0400
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 12:20 -0400
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-11 17:30 +0000
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-09 12:58 +0200
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-09 14:23 +0300
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 12:50 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 14:44 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-10 11:55 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-10 14:46 +0200
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 15:41 +0000
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-10 21:05 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-10 20:27 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 20:57 +0000
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 11:17 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 12:51 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 16:25 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 15:50 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 17:24 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 17:56 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 20:29 +0200
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 13:58 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-11 22:24 +0100
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 14:36 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 00:13 +0100
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 16:59 -0700
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 02:27 +0100
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 18:53 -0700
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-12 02:43 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 12:50 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-12 12:57 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 14:33 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-13 04:53 +0200
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-12 15:43 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 17:52 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-12 17:40 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-13 00:09 +0100
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-13 21:40 +0300
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-13 20:08 +0000
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-14 00:30 +0300
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-13 21:07 -0400
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-13 18:33 -0700
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-13 22:57 -0400
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-13 20:26 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-13 14:58 -0700
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-13 21:58 -0300
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-13 18:22 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-13 14:52 -0700
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-13 20:50 -0400
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 19:17 +0100
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-12 09:59 -0400
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 15:15 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-12 06:33 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 12:00 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-13 04:27 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-13 12:33 +0100
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-13 12:36 +0100
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-13 14:54 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-13 17:48 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-14 05:59 +0200
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-14 14:11 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-13 14:58 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-13 14:34 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-13 17:39 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-14 06:23 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-14 11:16 +0100
Re: do { quit; } else { } tTh <tth@none.invalid> - 2025-04-14 12:51 +0200
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-14 12:12 +0100
Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-14 14:18 +0200
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-14 15:33 +0300
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-14 16:22 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 09:17 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 11:30 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-15 15:34 +0300
Re: Loops (was Re: do { quit; } else { }) Richard Heathfield <rjh@cpax.org.uk> - 2025-04-15 13:51 +0100
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 07:40 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 07:31 -0700
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-04 18:08 +0300
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-05 10:42 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-10 06:43 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-10 15:56 +0000
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-05-10 17:48 +0000
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-11 08:20 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-10 14:29 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-11 08:21 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-11 12:02 +0200
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-11 15:30 +0000
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-05-11 16:29 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-11 18:49 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 14:41 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-11 17:43 -0400
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 15:06 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-11 18:30 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 18:15 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 19:09 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 00:16 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 02:23 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 07:19 -0700
Re: Loops (was Re: do { quit; } else { }) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 15:34 +0100
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 22:42 -0700
Re: Loops (was Re: do { quit; } else { }) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 07:31 +0100
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 21:12 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 09:30 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 22:28 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 13:31 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 20:44 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-14 21:45 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-12 17:24 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-12 00:07 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 00:43 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 02:27 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-12 17:18 +0200
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-28 09:54 -0800
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-28 16:42 -0800
Re: Loops (was Re: do { quit; } else { }) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-31 07:03 +0000
Re: Loops (was Re: do { quit; } else { }) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-31 03:53 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2026-01-31 18:26 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2026-01-31 18:33 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2026-01-31 21:02 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-12 19:53 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 23:03 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 19:04 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-12 17:08 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 13:38 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-13 12:41 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 23:16 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 14:35 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 15:10 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 15:41 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 18:38 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 19:37 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-13 23:54 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 21:19 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 21:12 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 22:38 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 21:55 -0800
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-01 23:37 -0800
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-14 03:35 +0000
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 21:54 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-14 06:31 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 06:01 -0700
Re: Loops (was Re: do { quit; } else { }) Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-14 12:24 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-06-14 13:57 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-06-14 22:27 +0300
Re: Loops (was Re: do { quit; } else { }) Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-15 09:32 +0200
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-14 13:00 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-14 13:20 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-14 23:20 -0400
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-15 11:23 +0200
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 13:55 -0800
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 17:59 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-05-12 10:11 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-12 17:09 +0300
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-11 01:09 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 17:30 -0700
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-12 16:18 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 11:09 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 15:57 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-04 13:52 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-15 13:19 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 18:17 +0100
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 19:07 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 21:46 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 01:41 +0000
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 22:37 -0400
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 03:30 +0000
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 20:50 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 18:11 +0000
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 18:43 +0000
Re: Loops (was Re: do { quit; } else { }) Richard Heathfield <rjh@cpax.org.uk> - 2025-04-16 20:05 +0100
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 03:47 -0800
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 04:21 -0800
Re: Loops (was Re: do { quit; } else { }) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-02-04 23:40 +0000
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-05 08:10 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2026-02-05 11:30 +0200
Re: Loops (was Re: do { quit; } else { }) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-05 15:21 +0000
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 14:12 +0000
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-16 07:35 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 12:32 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-16 15:08 +0300
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 14:23 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 21:32 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 15:31 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 15:01 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-18 15:34 +0100
Re: Loops (was Re: do { quit; } else { }) Alexis <flexibeast@gmail.com> - 2025-04-19 11:01 +1000
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 09:20 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 14:21 +0000
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 15:06 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-16 10:47 -0400
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 16:14 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-16 18:18 +0300
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-16 12:28 -0400
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 13:03 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 23:14 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 17:26 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 02:26 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 20:14 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 15:37 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-18 15:19 +0100
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-18 16:58 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-18 18:27 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 09:09 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-17 00:59 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 02:09 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 21:43 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 23:42 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 23:49 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 01:48 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 19:18 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 12:16 +0100
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 14:36 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-17 11:47 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 20:18 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-17 12:55 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 21:44 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-17 15:32 -0700
Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-17 21:21 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-04-17 22:29 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-18 13:58 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-04-18 18:33 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) bart <bc@freeuk.com> - 2025-04-18 20:10 +0100
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) bart <bc@freeuk.com> - 2025-04-18 16:07 +0100
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) scott@slp53.sl.home (Scott Lurndal) - 2025-04-18 16:52 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Rosario19 <Ros@invalid.invalid> - 2025-04-24 22:43 +0200
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-25 07:50 +0200
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Richard Harnden <richard.nospam@gmail.invalid> - 2025-04-25 07:04 +0100
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Rosario19 <Ros@invalid.invalid> - 2025-04-25 10:38 +0200
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Rosario19 <Ros@invalid.invalid> - 2025-04-25 10:42 +0200
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-18 15:24 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-04-18 15:48 +0000
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) bart <bc@freeuk.com> - 2025-04-18 16:57 +0100
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 18:46 +0200
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) bart <bc@freeuk.com> - 2025-04-18 18:40 +0100
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 08:36 +0200
Re: Checking the loop variable after the loop has ended (Was: Loops (was Re: do { quit; } else { })) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 17:49 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-17 02:19 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 17:47 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 14:41 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 14:09 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-16 17:37 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-06 05:59 -0700
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-07 12:32 +0300
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-07 14:54 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-05-07 13:50 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 23:48 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 15:45 +0100
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 15:44 +0000
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 13:18 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-15 19:55 +0000
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-16 07:19 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-16 07:44 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 12:01 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 16:40 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-18 14:10 -0400
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-18 23:27 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 08:27 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 11:26 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 13:32 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 14:05 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-19 12:54 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 20:57 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-19 14:07 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 00:34 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 12:18 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 12:43 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 18:46 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 20:51 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-20 15:36 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 00:29 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-20 19:08 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 12:26 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-21 03:16 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 12:57 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-21 18:43 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 20:57 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-21 20:25 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 00:33 +0100
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-21 23:46 +0000
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 10:32 +0200
Re: Loops (was Re: do { quit; } else { }) antispam@fricas.org (Waldek Hebisch) - 2025-04-22 01:06 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 02:24 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 10:47 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 11:28 +0100
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-22 19:19 +0200
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-22 19:26 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 21:03 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-22 21:40 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 00:43 +0100
Re: Loops (was Re: do { quit; } else { }) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-22 16:59 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-23 00:01 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 11:15 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-23 10:58 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 14:50 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-23 16:00 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 17:39 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-24 07:41 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 09:31 +0100
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-23 17:31 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 18:43 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-23 18:43 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 21:49 +0100
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-24 15:12 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 15:28 +0100
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-24 17:21 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 18:30 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-24 17:59 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-25 15:19 +0200
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-24 07:40 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 09:26 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-24 10:52 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 12:44 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-24 14:31 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-24 14:25 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 14:51 +0100
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-24 15:32 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-24 18:49 +0100
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-24 18:03 +0000
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-24 18:26 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-04-25 08:53 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 22:17 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-09-26 02:00 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-25 02:56 +0000
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-25 13:48 +0200
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-25 17:51 +0200
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-25 17:48 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-24 18:51 +0200
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-23 09:01 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 09:32 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 09:14 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-20 15:07 -0700
Re: Loops (was Re: do { quit; } else { }) gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-20 23:19 +0000
Re: Loops (was Re: do { quit; } else { }) antispam@fricas.org (Waldek Hebisch) - 2025-04-21 13:51 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 16:36 +0100
Re: Loops (was Re: do { quit; } else { }) antispam@fricas.org (Waldek Hebisch) - 2025-04-21 21:06 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 23:54 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 16:12 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 01:26 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 18:22 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 11:43 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-22 14:15 -0700
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 23:52 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-22 16:22 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 10:40 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 18:25 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 10:19 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 12:39 +0100
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 02:21 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 09:54 +0200
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-22 20:16 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 19:54 +0100
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-22 21:11 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 20:43 +0100
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-23 17:41 +0200
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-19 16:28 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 19:59 +0100
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 20:15 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 12:41 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 12:34 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-19 14:35 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 16:24 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-19 16:36 +0000
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-19 15:22 -0400
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 20:55 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-19 13:55 -0700
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-20 00:52 +0300
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 13:00 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 14:53 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-20 17:34 +0300
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 16:25 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-20 19:01 +0300
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 18:10 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 18:07 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 17:55 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 17:28 +0100
Re: Loops (was Re: do { quit; } else { }) antispam@fricas.org (Waldek Hebisch) - 2025-04-21 03:07 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 13:46 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 14:21 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 00:14 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 00:19 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 15:39 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-22 10:12 +0200
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-21 22:16 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 01:12 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-22 03:31 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 12:33 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-22 14:36 +0000
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-22 16:10 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-22 17:27 +0100
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-22 17:48 +0000
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-22 14:31 -0700
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-22 22:39 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-22 17:53 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-22 15:02 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-23 19:05 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-23 18:52 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-23 13:22 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-21 07:34 -0400
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-21 13:26 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 13:39 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 21:35 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-19 15:15 -0400
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-19 20:36 +0100
Re: Loops (was Re: do { quit; } else { }) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-19 19:43 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 11:27 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 11:25 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-20 11:25 -0400
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-20 16:53 +0100
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-16 12:29 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-16 12:38 +0100
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-16 19:15 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 15:28 +0100
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 14:44 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 06:14 +0200
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-15 06:57 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 09:25 +0200
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-16 11:45 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-18 16:57 +0200
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-20 15:00 +0300
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-20 17:45 +0200
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-24 22:35 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-25 07:46 +0200
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-25 10:29 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-25 14:22 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 11:15 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-15 15:25 +0300
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 13:55 +0100
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-15 13:33 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 15:30 +0100
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 18:22 +0200
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 17:42 +0100
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-15 20:14 +0300
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-16 07:39 +0200
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-15 20:37 +0000
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-16 12:09 +0200
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-16 12:04 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:13 +0000
Re: Loops (was Re: do { quit; } else { }) bart <bc@freeuk.com> - 2025-04-15 15:41 +0100
Re: Loops (was Re: do { quit; } else { }) Rosario19 <Ros@invalid.invalid> - 2025-04-16 11:58 +0200
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:07 -0700
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-14 23:12 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-15 01:35 +0100
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:05 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-15 15:44 +0100
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 15:31 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-15 17:38 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-12 14:39 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-04-12 14:21 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-12 15:52 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-04-12 16:32 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-13 16:26 +0200
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-13 14:48 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-12 15:01 +0100
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 18:24 -0400
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-13 21:03 +0300
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-13 20:56 -0400
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 11:24 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 01:30 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 02:35 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-27 09:17 -0800
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-27 15:28 -0800
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 11:15 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-13 20:57 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-13 20:53 +0200
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-13 22:14 +0300
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-13 21:03 -0400
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-14 06:43 +0200
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-14 09:00 -0400
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 09:40 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-04-15 09:18 +0100
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 10:39 -0400
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-14 08:44 +0200
Re: do { quit; } else { } Ike Naar <ike@sdf.org> - 2025-04-11 19:45 +0000
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 16:00 -0400
Re: do { quit; } else { } antispam@fricas.org (Waldek Hebisch) - 2025-04-15 15:44 +0000
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-10 20:21 +0000
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 15:43 -0700
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-11 02:12 +0000
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 20:44 -0700
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 11:33 +0200
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-10 15:14 -0400
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-10 16:25 -0400
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-04-10 21:42 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-11 11:35 +0200
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-10 15:49 -0700
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-10 20:57 -0400
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-11 14:37 +0300
Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 11:16 -0400
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-11 18:31 +0300
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 11:10 -0700
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-11 14:02 +0000
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-04-11 15:24 +0000
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-11 18:46 +0300
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 12:01 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 10:47 -0700
Re: do { quit; } else { } Ike Naar <ike@sdf.org> - 2025-04-09 09:00 +0000
Re: do { quit; } else { } bart <bc@freeuk.com> - 2025-04-09 11:36 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-09 14:54 +0200
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 10:59 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-09 11:51 +0300
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 12:56 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-06 16:26 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-06 16:02 +0200
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-04-06 16:53 -0300
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 19:45 +0200
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-05-09 15:23 -0300
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-05-09 15:35 -0300
Re: do { quit; } else { } yeti <yeti@tilde.institute> - 2025-04-07 03:56 +0042
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-07 09:16 +0200
Re: do { quit; } else { } gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-06 14:18 +0000
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-06 17:08 +0200
Beyond the pale... (Was: do { quit; } else { }) gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-07 16:08 +0000
Re: Beyond the pale... (Was: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-04-07 18:39 +0200
Re: Beyond the pale... (Was: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-07 23:30 +0000
Re: Beyond the pale... (Was: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-04-08 12:39 +0300
Re: Beyond the pale... (Was: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-08 16:57 +0000
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-07 08:06 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-06 08:14 -0700
Re: do { quit; } else { } Michael S <already5chosen@yahoo.com> - 2025-04-06 23:48 +0300
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-07 09:21 +0200
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-07 04:50 -0700
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 16:40 +0200
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-05-09 15:01 +0000
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 17:04 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 16:26 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-09 17:54 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 17:26 +0100
Re: do { quit; } else { } scott@slp53.sl.home (Scott Lurndal) - 2025-05-09 17:07 +0000
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 19:11 +0100
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 20:21 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 19:35 +0100
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 19:09 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 19:29 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 14:55 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 14:35 +0100
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-14 11:22 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 10:34 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-09 19:09 +0200
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 19:11 +0200
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-09 19:18 +0200
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 14:54 +0200
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-13 15:36 +0200
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-14 11:19 +0200
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 11:44 -0700
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 15:13 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 14:46 +0100
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-13 16:07 +0200
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 14:05 -0700
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-14 11:31 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 10:37 +0100
Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-09 15:31 +0000
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 19:07 +0200
Re: do { quit; } else { } Wuns Haerst <Wuns.Haerst@wurstfabrik.at> - 2025-05-07 06:56 +0200
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 06:52 +0100
Re: do { quit; } else { } Wuns Haerst <Wuns.Haerst@wurstfabrik.at> - 2025-05-07 15:46 +0200
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 06:04 -0700
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 14:24 -0700
Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-27 09:15 -0800
Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-27 15:36 -0800
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 11:09 +0200
Re: do { quit; } else { } Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-06 02:58 +0000
Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-04-06 12:05 +0200
Re: do { quit; } else { } Mikko <mikko.levanto@iki.fi> - 2025-04-18 10:30 +0300
Re: do { quit; } else { } Anton Shepelev <anton.txt@g{oogle}mail.com> - 2025-10-08 14:14 +0300
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-10-08 09:59 -0300
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:05 +0200
Re: do { quit; } else { } Anton Shepelev <anton.txt@g{oogle}mail.com> - 2025-10-08 17:08 +0300
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:35 +0200
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-10-15 16:04 -0300
Re: do { quit; } else { } Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:06 +0200
Re: do { quit; } else { } Bonita Montero <Bonita.Montero@gmail.com> - 2025-10-15 23:04 +0200
Re: do { quit; } else { } Thiago Adams <thiago.adams@gmail.com> - 2025-10-15 20:41 -0300
Re: do { quit; } else { } Richard Heathfield <rjh@cpax.org.uk> - 2025-10-16 00:43 +0100
Page 8 of 35 — ← Prev page 1 … 6 7 [8] 9 10 … 35 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-11 12:51 +0100 |
| Message-ID | <vtavn9$1dp7m$3@dont-email.me> |
| In reply to | #392367 |
On 11/04/2025 10:17, David Brown wrote:
> On 10/04/2025 21:27, bart wrote:
>> On 10/04/2025 20:05, David Brown wrote:
>>> C rarely makes things more complicated without a good reason.
>>
>> C usually makes things more complicated without a good reason!
>
> Nope.
>
>>
>> Here's one example, of dozens, of perfectly legal C:
>>
>> long unsigned const long const const typedef int A;
>> int long unsigned const long const const typedef A;
>> long unsigned const long const typedef int A;
>> .....
>>
>
> That is not more complicated, nor is it without good reason.
Huh? That demonstrates several things:
1 That the same identifier can be redeclared multiple times
2 That 'typedef' needn't be on the left, but can be anywhere in the
middle of a type spec
3 That 'const' can also be anywhere inside the type spec
4 That duplicate 'const's are tolerated
5 That the three tokens ('int', 'unsigned' and two 'long's) denoting the
type can be be any order (and mixed up with other attributes)
I missed out:
6 'int' can be optionally omitted in this case.
That makes it pretty complicated to me! And I can't see that any of
these are necessary. A syntax like this:
typedef A = const unsigned long long int;
which is only allowed once; typedef always on the left; 'const' only
once; and the token order must be as specified, will achieve everything
that needs to be achieved.
I haven't remarked on:
7 That you need 3/4 tokens to specify a simple u64 type.
since you suggest that 'uint64_t' used. However, that adds to the
complication:
8 A u64 type can be denoted as either 'uint64_t' OR as some combination
of the tokens (long, long, unsigned, [int])
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-11 16:25 +0200 |
| Message-ID | <vtb8nv$1plb2$2@dont-email.me> |
| In reply to | #392375 |
On 11/04/2025 13:51, bart wrote:
> On 11/04/2025 10:17, David Brown wrote:
>> On 10/04/2025 21:27, bart wrote:
>>> On 10/04/2025 20:05, David Brown wrote:
>
>>>> C rarely makes things more complicated without a good reason.
>>>
>>> C usually makes things more complicated without a good reason!
>>
>> Nope.
>>
>>>
>>> Here's one example, of dozens, of perfectly legal C:
>>>
>>> long unsigned const long const const typedef int A;
>>> int long unsigned const long const const typedef A;
>>> long unsigned const long const typedef int A;
>>> .....
>>>
>>
>> That is not more complicated, nor is it without good reason.
>
> Huh? That demonstrates several things:
>
> 1 That the same identifier can be redeclared multiple times
Many types of declarations can be repeated, as long as they define the
same identifier to be the same thing. If you want the details, they are
in section 6.7 of the standard.
>
> 2 That 'typedef' needn't be on the left, but can be anywhere in the
> middle of a type spec
Correct. Putting it anywhere other than the left may be disallowed
sometime in the future (it is an "obsolescent feature"), but it is
currently supported in C.
>
> 3 That 'const' can also be anywhere inside the type spec
Correct.
>
> 4 That duplicate 'const's are tolerated
Correct.
>
> 5 That the three tokens ('int', 'unsigned' and two 'long's) denoting the
> type can be be any order (and mixed up with other attributes)
>
Correct.
You seem to think that allowing a variation in the way a declaration is
made makes the feature "more complicated". That is simply incorrect.
The feature - the syntax and the rules in the language definition - are
/less/ complicated because of this flexibility. It means the syntax
here can be, as given in 6.7p1 :
declaration-specifiers:
storage-class-specifier declaration-specifiers opt
type-specifier declaration-specifiers opt
type-qualifier declaration-specifiers opt
function-specifier declaration-specifiers opt
alignment-specifier declaration-specifiers opt
If the order were to be strictly specified, there would need to be a
half-dozen more named and defined specifier lists in the syntax.
It would certainly have been possible to specify an order - either in
the syntax or the constraints. I think that would have been a good
idea, and would make C code a little more consistent. But by the time
this was codified, there was probably a variety of orderings in use in
real code, and such ordering would make the standard, and therefore the
language, a little more complicated.
> I missed out:
>
> 6 'int' can be optionally omitted in this case.
>
> That makes it pretty complicated to me! And I can't see that any of
> these are necessary.
No one suggested it was at all necessary.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-11 15:50 +0100 |
| Message-ID | <vtba81$1qfbm$1@dont-email.me> |
| In reply to | #392383 |
On 11/04/2025 15:25, David Brown wrote:
> On 11/04/2025 13:51, bart wrote:
>> On 11/04/2025 10:17, David Brown wrote:
>>> On 10/04/2025 21:27, bart wrote:
>>>> On 10/04/2025 20:05, David Brown wrote:
>>
>>>>> C rarely makes things more complicated without a good reason.
>>>>
>>>> C usually makes things more complicated without a good reason!
>>>
>>> Nope.
>>>
>>>>
>>>> Here's one example, of dozens, of perfectly legal C:
>>>>
>>>> long unsigned const long const const typedef int A;
>>>> int long unsigned const long const const typedef A;
>>>> long unsigned const long const typedef int A;
>>>> .....
>>>>
>>>
>>> That is not more complicated, nor is it without good reason.
>>
>> Huh? That demonstrates several things:
>>
>> 1 That the same identifier can be redeclared multiple times
>
> Many types of declarations can be repeated, as long as they define the
> same identifier to be the same thing. If you want the details, they are
> in section 6.7 of the standard.
>
>>
>> 2 That 'typedef' needn't be on the left, but can be anywhere in the
>> middle of a type spec
>
> Correct. Putting it anywhere other than the left may be disallowed
> sometime in the future (it is an "obsolescent feature"), but it is
> currently supported in C.
>
>>
>> 3 That 'const' can also be anywhere inside the type spec
>
> Correct.
>
>>
>> 4 That duplicate 'const's are tolerated
>
> Correct.
>
>>
>> 5 That the three tokens ('int', 'unsigned' and two 'long's) denoting
>> the type can be be any order (and mixed up with other attributes)
>>
>
> Correct.
>
> You seem to think that allowing a variation in the way a declaration is
> made makes the feature "more complicated". That is simply incorrect.
> The feature - the syntax and the rules in the language definition -
> are /less/ complicated because of this flexibility. It means the syntax
> here can be, as given in 6.7p1 :
>
> declaration-specifiers:
> storage-class-specifier declaration-specifiers opt
> type-specifier declaration-specifiers opt
> type-qualifier declaration-specifiers opt
> function-specifier declaration-specifiers opt
> alignment-specifier declaration-specifiers opt
That always reads to me like 'lots of twisty windy passages, all alike'.
> If the order were to be strictly specified, there would need to be a
> half-dozen more named and defined specifier lists in the syntax.
This is the similar feature for my syntax, a bit of BNF:
typedef = [scopeattr] 'type' name = typespec
It does a bit more than C's 'typedef' in that such names can be
exported, to render them visible to modules that import this one.
Notice that the 'type' keyword and the new identifier are outside of the
type-spec, which is part of what makes C syntax a nightmare.
> It would certainly have been possible to specify an order - either in
> the syntax or the constraints. I think that would have been a good
> idea, and would make C code a little more consistent. But by the time
> this was codified, there was probably a variety of orderings in use in
> real code, and such ordering would make the standard, and therefore the
> language, a little more complicated.
>
>> I missed out:
>>
>> 6 'int' can be optionally omitted in this case.
>>
>> That makes it pretty complicated to me! And I can't see that any of
>> these are necessary.
>
> No one suggested it was at all necessary.
/You/ did: "That is not more complicated, nor is it without good reason."
What are those good reasons, that it makes code more readable? That it
is easier to describe in a grammar? That it makes it easier to parse?
I've parsed C code; I can confirm it is much harder to do that any
language I've devised.
Pretending for a minute that I have 'const' in my syntax, the example I
posted would be written like this:
type A = const u64
You can only define it once. The new name is ALWAYS on the left of the
'=', unlike C, where here:
typedef int (*A)[];
the name is in the middle of the 'int(*)[]' type.
If shared across multiple modules, then you'd write it like this (and
not in a header either):
global type A = const u64
*That* is simple. Remember you said this:
"C rarely makes things more complicated without a good reason."
And I responded woth this:
"C usually makes things more complicated without a good reason!"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-11 17:24 +0200 |
| Message-ID | <vtbc6o$1te2o$1@dont-email.me> |
| In reply to | #392385 |
On 11/04/2025 16:50, bart wrote:
> On 11/04/2025 15:25, David Brown wrote:
>> On 11/04/2025 13:51, bart wrote:
>>> On 11/04/2025 10:17, David Brown wrote:
>>>> On 10/04/2025 21:27, bart wrote:
>>>>> On 10/04/2025 20:05, David Brown wrote:
>>>
>>>>>> C rarely makes things more complicated without a good reason.
>>>>>
>>>>> C usually makes things more complicated without a good reason!
>>>>
>>>> Nope.
>>>>
>>>>>
>>>>> Here's one example, of dozens, of perfectly legal C:
>>>>>
>>>>> long unsigned const long const const typedef int A;
>>>>> int long unsigned const long const const typedef A;
>>>>> long unsigned const long const typedef int A;
>>>>> .....
>>>>>
>>>>
>>>> That is not more complicated, nor is it without good reason.
>>>
>>> Huh? That demonstrates several things:
>>>
>>> 1 That the same identifier can be redeclared multiple times
>>
>> Many types of declarations can be repeated, as long as they define the
>> same identifier to be the same thing. If you want the details, they
>> are in section 6.7 of the standard.
>>
>>>
>>> 2 That 'typedef' needn't be on the left, but can be anywhere in the
>>> middle of a type spec
>>
>> Correct. Putting it anywhere other than the left may be disallowed
>> sometime in the future (it is an "obsolescent feature"), but it is
>> currently supported in C.
>>
>>>
>>> 3 That 'const' can also be anywhere inside the type spec
>>
>> Correct.
>>
>>>
>>> 4 That duplicate 'const's are tolerated
>>
>> Correct.
>>
>>>
>>> 5 That the three tokens ('int', 'unsigned' and two 'long's) denoting
>>> the type can be be any order (and mixed up with other attributes)
>>>
>>
>> Correct.
>>
>> You seem to think that allowing a variation in the way a declaration
>> is made makes the feature "more complicated". That is simply
>> incorrect. The feature - the syntax and the rules in the language
>> definition - are /less/ complicated because of this flexibility. It
>> means the syntax here can be, as given in 6.7p1 :
>>
>> declaration-specifiers:
>> storage-class-specifier declaration-specifiers opt
>> type-specifier declaration-specifiers opt
>> type-qualifier declaration-specifiers opt
>> function-specifier declaration-specifiers opt
>> alignment-specifier declaration-specifiers opt
>
> That always reads to me like 'lots of twisty windy passages, all alike'.
Try reading it without your usual anti-C prejudice. Perhaps read the
whole section of the standard.
>
>> If the order were to be strictly specified, there would need to be a
>> half-dozen more named and defined specifier lists in the syntax.
>
> This is the similar feature for my syntax, a bit of BNF:
>
> typedef = [scopeattr] 'type' name = typespec
>
> It does a bit more than C's 'typedef' in that such names can be
> exported, to render them visible to modules that import this one.
>
The C syntax for declarations here is for /all/ declarations in C. It's
not just for typedefs in a simple little toy language. (And yes, if you
are going to make absurd claims about your language in comparison to C,
you can expect to hear that it is a toy in comparison C.)
>>>
>>> That makes it pretty complicated to me! And I can't see that any of
>>> these are necessary.
>>
>> No one suggested it was at all necessary.
>
> /You/ did: "That is not more complicated, nor is it without good reason."
You just quoted me - at no point did I say it was "necessary".
Are you still surprised that sometimes people say you are trolling or lying?
I didn't give the slightest reason to suggest the syntax of C's
declarations was necessary. Nor did I suggest that I like C's rules
here - on the contrary, I have made it clear that I'd prefer a stricter
ordering. But C is not a language I designed, nor is it designed for my
needs alone.
>
> What are those good reasons, that it makes code more readable? That it
> is easier to describe in a grammar?
That is, as I have already said, a good reason for this. It is also
more flexible - some people like that. Remember also that not all C
code is written out by hand - some is generated, some is also the result
of macro expansion. It is a language designed to work well for a vast
number of people in a vast number of circumstances - not a plaything for
a single person.
> That it makes it easier to parse?
>
Who cares? That's irrelevant to the language design, except for toys
where the only user is the person who writes the tools.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-11 17:56 +0100 |
| Message-ID | <vtbhjv$24api$1@dont-email.me> |
| In reply to | #392388 |
On 11/04/2025 16:24, David Brown wrote: > On 11/04/2025 16:50, bart wrote: >>> declaration-specifiers: >>> storage-class-specifier declaration-specifiers opt >>> type-specifier declaration-specifiers opt >>> type-qualifier declaration-specifiers opt >>> function-specifier declaration-specifiers opt >>> alignment-specifier declaration-specifiers opt >> >> That always reads to me like 'lots of twisty windy passages, all alike'. > > Try reading it without your usual anti-C prejudice. Perhaps read the > whole section of the standard. > >> >>> If the order were to be strictly specified, there would need to be a >>> half-dozen more named and defined specifier lists in the syntax. >> >> This is the similar feature for my syntax, a bit of BNF: >> >> typedef = [scopeattr] 'type' name = typespec >> >> It does a bit more than C's 'typedef' in that such names can be >> exported, to render them visible to modules that import this one. >> > > The C syntax for declarations here is for /all/ declarations in C. It's > not just for typedefs in a simple little toy language. That's not right. You pasted part of 6.7p1. The full syntax for declarations comprises all of 6.7.p1, plus 6.7.1p1, 6.7.2p1, 6.7.2p2 (constraints to do with the ordering of long, int etc), 6.7.2.1, 6.7.2.2, 6.7.3, 6.7.6, 6.7.7, and 6.7.8. (And yes, if you > are going to make absurd claims about your language in comparison to C, > you can expect to hear that it is a toy in comparison C.) Really? Please show /any/ declaration in C that I can't write in mine, but in a saner and less convoluted manner. Please define /any/ data structure that I can't express. I could spend all day showing absurdity after absurdity in C. And you're saying /my/ language is a toy?! My language /has/ a module scheme. All that palaver about type compatability just doesn't arise, because of careful language design. My language /has/ the ability to import and export types, structs, enums, macros; anything that can be named. My language /has/ named and default arguments. It /has/ reference parameters. It /has/ multiple function returns. My language /has/ embedded text and binary files (and in a far simpler manner than proposed for C23). Lots more, and it does it with a sane syntax Still think it's a toy? (Silly question, of source you will say Yes.) >> That it makes it easier to parse? >> > > Who cares? That's irrelevant to the language design, except for toys > where the only user is the person who writes the tools. Humans have to parse it too. C must be the only non-esoteric language where you need to use third-party tools (CDECL etc) to make sense of type-declarations. Either that or follow complex spirular algorithms to decade them. A complete fail in my view. Yes, your tools (thanks to 1000s of man-years of effort) are superior and more expansive that any of mine**, but your language is still a turd, sorry. All those tools can do is polish it. (** in some ways, but not in the ways /I/ value.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-11 20:29 +0200 |
| Message-ID | <vtbn2k$293r1$1@dont-email.me> |
| In reply to | #392397 |
On 11/04/2025 18:56, bart wrote: > On 11/04/2025 16:24, David Brown wrote: >> On 11/04/2025 16:50, bart wrote: > >>>> declaration-specifiers: >>>> storage-class-specifier declaration-specifiers opt >>>> type-specifier declaration-specifiers opt >>>> type-qualifier declaration-specifiers opt >>>> function-specifier declaration-specifiers opt >>>> alignment-specifier declaration-specifiers opt >>> >>> That always reads to me like 'lots of twisty windy passages, all alike'. >> >> Try reading it without your usual anti-C prejudice. Perhaps read the >> whole section of the standard. >> >>> >>>> If the order were to be strictly specified, there would need to be a >>>> half-dozen more named and defined specifier lists in the syntax. >>> >>> This is the similar feature for my syntax, a bit of BNF: >>> >>> typedef = [scopeattr] 'type' name = typespec >>> >>> It does a bit more than C's 'typedef' in that such names can be >>> exported, to render them visible to modules that import this one. >>> >> >> The C syntax for declarations here is for /all/ declarations in C. >> It's not just for typedefs in a simple little toy language. > > That's not right. You pasted part of 6.7p1. The full syntax for > declarations comprises all of 6.7.p1, plus 6.7.1p1, 6.7.2p1, 6.7.2p2 > (constraints to do with the ordering of long, int etc), 6.7.2.1, > 6.7.2.2, 6.7.3, 6.7.6, 6.7.7, and 6.7.8. > It is the full syntax for declaration specifiers - the matter under discussion. I did not include initialisation, static assertions, the syntax for identifiers, or any number of different parts of the syntax of C. > > (And yes, if you >> are going to make absurd claims about your language in comparison to >> C, you can expect to hear that it is a toy in comparison C.) > > Really? Please show /any/ declaration in C that I can't write in mine, > but in a saner and less convoluted manner. Please define /any/ data > structure that I can't express. > I have no idea about your language, nor do I care. > I could spend all day showing absurdity after absurdity in C. And you're > saying /my/ language is a toy?! Yes. It is a toy because it is a personal little language for your ego. There is no specification or description of it, there are no serious implementations of it, there are no users of it other than you, there is no consistency in it - you change your language and your tools to suit the program you are writing at the time, and regularly don't know yourself how it works or what features it has. It is in no sense "battle-tested" - the only user writes code that he knows will not cause trouble. Thus you avoid all the issues that real languages have to handle - real programs written by many different people for many different purposes. The fact that you have made a living using your language(s) does not mean they are not toys. You are like an Esperanto fanatic trying to tell people their language is so much better than English because the spelling is consistent, so the world would be a better place if we all switched over. Except in your case, you are the only one who speaks the language. > >>> That it makes it easier to parse? >>> >> >> Who cares? That's irrelevant to the language design, except for toys >> where the only user is the person who writes the tools. > > Humans have to parse it too. C must be the only non-esoteric language > where you need to use third-party tools (CDECL etc) to make sense of > type-declarations. Either that or follow complex spirular algorithms to > decade them. > I have never heard of anyone other than you who views cdecl as a necessity. A tiny proportion of C programmers find it helpful when dealing with code written by others - especially if the code is written in a poor style and the reader is relatively new to C. If you want to learn more about C, ask about it here - if you want to promote your own language, perhaps comp.lang.misc is a better place.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-11 13:58 -0700 |
| Message-ID | <87semequt6.fsf@nosuchdomain.example.com> |
| In reply to | #392406 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I have never heard of anyone other than you who views cdecl as a
> necessity. A tiny proportion of C programmers find it helpful when
> dealing with code written by others - especially if the code is
> written in a poor style and the reader is relatively new to C.
I find cdecl useful (but not necessary).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-11 22:24 +0100 |
| Message-ID | <vtc19j$2kqlj$1@dont-email.me> |
| In reply to | #392406 |
On 11/04/2025 19:29, David Brown wrote:
> On 11/04/2025 18:56, bart wrote:
>> That's not right. You pasted part of 6.7p1. The full syntax for
>> declarations comprises all of 6.7.p1, plus 6.7.1p1, 6.7.2p1, 6.7.2p2
>> (constraints to do with the ordering of long, int etc), 6.7.2.1,
>> 6.7.2.2, 6.7.3, 6.7.6, 6.7.7, and 6.7.8.
>>
>
> It is the full syntax for declaration specifiers - the matter under
> discussion. I did not include initialisation, static assertions, the
> syntax for identifiers, or any number of different parts of the syntax
> of C.
So how much of:
long unsigned const long const const typedef int A;
does it cover? I can see that it doesn't cover any of the terminals (all
tokens up to 'A'); the identifier ('A'); or the semicolon.
I suggest there's more missing that you seem to think.
>> I could spend all day showing absurdity after absurdity in C. And
>> you're saying /my/ language is a toy?!
>
> Yes.
>
> It is a toy because it is a personal little language for your ego. There
> is no specification or description of it, there are no serious
> implementations of it, there are no users of it other than you, there is
> no consistency in it - you change your language and your tools to suit
> the program you are writing at the time, and regularly don't know
> yourself how it works or what features it has. It is in no sense
> "battle-tested" - the only user writes code that he knows will not cause
> trouble. Thus you avoid all the issues that real languages have to
> handle - real programs written by many different people for many
> different purposes.
Yes, it is partly experimental. But how does that invalidate the
usefulness of a particular feature?
How does that invalidate its sane left-to-right type syntax compared to
the nightware syntax that C uses?
Even an experimental language can throw up dozens of useful features and
improvements.
'Battle-testing' is more useful for getting solid implementations,
finding bugs, filling in patches in coverage. But I am not providing an
implementation, only ideas and comparisons of language features.
You were talking about named arguments, well here is how /my/ version
works (which i first tried 30 years ago); here is the benefit of my
experience; here is how I solved the same problems you might have.
My language has been in use for over 40 years, and it has been
self-hosted in a continuous chain over the same period. That's some toy.
It has also managed to evolve a lot more than C has, BECAUSE there are
few users and there is a small codebase.
> You are like an Esperanto fanatic trying to tell people their language
> is so much better than English because the spelling is consistent, so
> the world would be a better place if we all switched over. Except in
> your case, you are the only one who speaks the language.
(Huh. I grow up, in the UK, in a family and circle of relatives where we
spoke our own obscure dialect from a region of Italy. We seemed to get by.)
Computer languages are different: if you have a compiler for a private
language, then it can do anything. Plus it is possible to write
conversion programs to advantage of tooling available for the more
mainstream language.
> I have never heard of anyone other than you who views cdecl as a
> necessity. A tiny proportion of C programmers find it helpful when
> dealing with code written by others - especially if the code is written
> in a poor style and the reader is relatively new to C.
Rubbish. Everyone finds C declaration syntax a nightmare.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-11 14:36 -0700 |
| Message-ID | <87a58mqt2o.fsf@nosuchdomain.example.com> |
| In reply to | #392420 |
bart <bc@freeuk.com> writes:
[...]
> Rubbish. Everyone finds C declaration syntax a nightmare.
Rubbish. I find C declaration syntax annoying, not a "nightmare".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-12 00:13 +0100 |
| Message-ID | <vtc7mp$2q5hr$1@dont-email.me> |
| In reply to | #392421 |
On 11/04/2025 22:36, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> Rubbish. Everyone finds C declaration syntax a nightmare.
>
> Rubbish. I find C declaration syntax annoying, not a "nightmare".
>
Annoying would be having to get letter case or punctuation just right.
But C typepecs can go far beyond it. I can just about do arrays of
pointers, or pointers to arrays. Anything more complicated is pretty
much trial and error.
In an example in my post which I then deleted (DB will just ignore
examples), I wanted to create an array of 10 pointers to functions that
take an int and return an int.
I started with something like this that I recalled from memory
(otherwise it would be even more wrong):
int (*A)[10](int);
but CDECL said it was something different. I tried one or two more
combinations before I gave up and asked CDECL to tell me the type from
the English.
C type syntax is just not fit for purpose. This is not how a language is
meant to work, and this is not supposed to be the hard part of a
language! Syntax should be the easy bit.
This is that English spec (with the significant bits numbered):
array 10 pointer to func take int return int
1 2 3 4 5 6
Here is what CDECL came up with:
int (*A[10])(int);
6 3 1 2 4 5 (Not sure which bit is the '4')
The numbers below show the correspondence with the English. You can see
it's all over the place. This is how I'd write it in another actual
language syntax:
[10]ref func(int)int A
1 2 3 4 5 6
Notice that that numbering here exactly corresponds to the English. THIS
is how easy it should be. I could write this as fast as I can type.
Further, the variable name is well out of it. In my syntax, any names go
on the right; names on the left is also popular. But no language other
than C and C++ has names IN THE MIDDLE.
So, yeah, a 'nightmare' is more apt than 'annoying'.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-11 16:59 -0700 |
| Message-ID | <875xjaqmgf.fsf@nosuchdomain.example.com> |
| In reply to | #392423 |
bart <bc@freeuk.com> writes:
> On 11/04/2025 22:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> Rubbish. Everyone finds C declaration syntax a nightmare.
>> Rubbish. I find C declaration syntax annoying, not a "nightmare".
>
> Annoying would be having to get letter case or punctuation just right.
[...]
> So, yeah, a 'nightmare' is more apt than 'annoying'.
Bart, bart, bart.
You made a false statement about how *everyone* feels about
C's declaration syntax. We all know that you consider it to be
a nightmare. I don't think I've ever said or implied that you
shouldn't feel that way. You think everyone *should* find it
a nightmare? Fine.
You cannot possibly be so deluded that you think everyone feels
the same way as you do, and we're all lying about it.
Do you seriously believe that I personally find C declaration syntax
a nightmare? Why the hell would I lie about something like that?
Why would you? Or perhaps you don't consider me to be a member of
"everyone"?
Perhaps when you wrote "Everyone finds C declaration syntax a
nightmare", you meant something other than that everyone finds C
declaration syntax a nightmare.
Earlier in this thread, you wrote: "I wonder if I could withdraw all
MY statements in this thread, and be treated with an equal amount
of civility?". Here's your opportunity to find out. Withdraw your
statement about how everyone feels about C declaration syntax and
see how we react.
You want to be treated better? Stop making deeply silly statements.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-12 02:27 +0100 |
| Message-ID | <vtcfhp$325g6$1@dont-email.me> |
| In reply to | #392424 |
On 12/04/2025 00:59, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 11/04/2025 22:36, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>> [...] >>>> Rubbish. Everyone finds C declaration syntax a nightmare. >>> Rubbish. I find C declaration syntax annoying, not a "nightmare". >> >> Annoying would be having to get letter case or punctuation just right. > [...] >> So, yeah, a 'nightmare' is more apt than 'annoying'. > > Bart, bart, bart. > You made a false statement about how *everyone* feels about > C's declaration syntax. So what would be a true statement? That everyone finds it at least midly annoying? C type syntax is famous for being difficult and confusing; I think most will agree about that. Even the creators said so. This was the discussion: BC: > Humans have to parse it too. C must be the only non-esoteric language where you need to use third-party tools (CDECL etc) to make sense of type-declarations. Either that or follow complex spirular algorithms to [decode] them. DB: I have never heard of anyone other than you who views cdecl as a necessity. So, is that last statement true or not? I didn't say it was a necessity, but that you need to use such tools or special methods to understand them. And clearly, that would be the more complicated ones; people can usually cope with 'int'. I replied to one sweeping statement with another. > We all know that you consider it to be > a nightmare. I don't think I've ever said or implied that you > shouldn't feel that way. You think everyone *should* find it > a nightmare? Fine. > > You cannot possibly be so deluded that you think everyone feels > the same way as you do, and we're all lying about it. There are plenty of resources like this about: http://www.unixwiz.net/techtips/reading-cdecl.html https://news.ycombinator.com/item?id=42564861 Why are they even necessary? (That last link includes this comment: "If you need a program to help you read C programs, that suggests a serious flaw in C." I have to give quotes from others because everybody here thinks it is only me. Here's a couple from Ritchie and Stroustrop: https://dev.to/pauljlucas/musings-on-c-c-declarations-169o) > You want to be treated better? Stop making deeply silly statements. DB was making light of the type syntax issue and pretty much dismissed it out of hand. How should I have responded? Not that it would cut any ice with him. Nothing is ever that complicated or too onerous or too slow or too over the top or too badly designed or ... I suggest also that you stop taking throwaway comments too literally. Yet, there is probably more truth in my remark than in David's. You might also consider that while many features of C have been copied, I don't know of any language that has copied its type syntax. I wonder why? Do you think the designers had an opinion about it closer to mine, or to David Brown's?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-11 18:53 -0700 |
| Message-ID | <87y0w6p2kw.fsf@nosuchdomain.example.com> |
| In reply to | #392425 |
bart <bc@freeuk.com> writes:
> On 12/04/2025 00:59, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 11/04/2025 22:36, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> Rubbish. Everyone finds C declaration syntax a nightmare.
>>>> Rubbish. I find C declaration syntax annoying, not a "nightmare".
>>>
>>> Annoying would be having to get letter case or punctuation just right.
>> [...]
>>> So, yeah, a 'nightmare' is more apt than 'annoying'.
>> Bart, bart, bart.
>
>> You made a false statement about how *everyone* feels about
>> C's declaration syntax.
>
> So what would be a true statement? That everyone finds it at least
> midly annoying?
Bart, bart, bart.
You made a false statement. It's not my freaking job to help you turn
it into a true statement.
[SNIP]
--
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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-04-12 02:43 +0000 |
| Message-ID | <20250411192435.573@kylheku.com> |
| In reply to | #392425 |
On 2025-04-12, bart <bc@freeuk.com> wrote: > On 12/04/2025 00:59, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 11/04/2025 22:36, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>> [...] >>>>> Rubbish. Everyone finds C declaration syntax a nightmare. >>>> Rubbish. I find C declaration syntax annoying, not a "nightmare". >>> >>> Annoying would be having to get letter case or punctuation just right. >> [...] >>> So, yeah, a 'nightmare' is more apt than 'annoying'. >> >> Bart, bart, bart. > > >> You made a false statement about how *everyone* feels about >> C's declaration syntax. > > So what would be a true statement? That everyone finds it at least midly > annoying? > > C type syntax is famous for being difficult and confusing; I think most > will agree about that. Even the creators said so. If you had a function that takes an int, that returned a pointer to an array, how would you pass in 42, and then get at the third element? f(42) // gets the pointer to the array (*f(42)) // designates the array (*f(42))[2] // gets at the third element. Ok, now declaring a function of int, which returns a pointer to an array of 16 elements: (*f(int))[16]; Notice any resemblance? The 42 argumet has changed to a type specifier for the corresponding parameter type. The array reference turns into the size. Minor! We need a type specifier to the elements: double (*f(int))[16]; Declaration follows use: it's not just a slogan, it's real! If you don't like the declaration syntax, it's possibly because you don't like the expression syntax for working with pointer dereferencing and arrays, which it mirrors. (You not liking C expression syntax: billion to one odds, right?) Making the type operators in the declarator resemble the unary and postfix operators of the use is kind of clever though! IDEA: maybe you would like the "dedclaration follows use", if it was rendered over a different expression grammar in which pointer, arrays and whatnot work the way you like. If didn't dislike the "use", you might not dislike "declaration follows use". Now, from this "envelope shape": double (.......)[16]; we know that whatever ..... is, it is an array of 16 doubles. This .... is called a "type hole" by functional programmers working in Haskell and whatnot. If we replace the hole with a name like abc: double (abc)[16]; then what is being declared is that name. We get an object abc which is such an array. The parentheses are then unnecessary and we can drop them. If we plug in *f(int) instead of abc, then *f(int) isn't what is being declared: f is. But we know that when this f is called, and the pointer it returns is dereferenced, we get an array. We know that from its correspondence to the ..... hole in the expression. Thus the function mut be returning a pointer to an array (of 16 double). The parentheses remain necessary then because the * on the left has lower precedence than the postfixes (int) and [16]. There is kind of minor algebra to it all, where you can play these substitution games. The declarator type constructors like the (...) function parentheses, [...] array brackets and the prefix * pointer are not called operators in ISO C, but they mimic the unary and postfix operators and have the same associativity and precedence. Moreover, the parentheses function the same way, for overriding precedence. If you know that postfix binds tighter than unary, but parentheses override, that's 90% of it. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-12 12:50 +0100 |
| Message-ID | <vtdk1f$e52f$1@dont-email.me> |
| In reply to | #392427 |
On 12/04/2025 03:43, Kaz Kylheku wrote:
> On 2025-04-12, bart <bc@freeuk.com> wrote:
>> C type syntax is famous for being difficult and confusing; I think most
>> will agree about that. Even the creators said so.
>
> If you had a function that takes an int, that returned a pointer to an
> array, how would you pass in 42, and then get at the third element?
>
> f(42) // gets the pointer to the array
>
> (*f(42)) // designates the array
>
> (*f(42))[2] // gets at the third element.
>
> Ok, now declaring a function of int, which returns a pointer to an array
> of 16 elements:
>
> (*f(int))[16];
>
> Notice any resemblance? The 42 argumet has changed to a type specifier
> for the corresponding parameter type. The array reference turns into
> the size. Minor!
> We need a type specifier to the elements:
>
> double (*f(int))[16];
>
> Declaration follows use: it's not just a slogan, it's real!
I'm sorry, but it doesn't work! The thought processes are entirely
different between writing expressions, and declaring types. They differ
in many ways anyway:
* A typespec needs a base type; an expr doesn't
* A typespec needs to express the whole thing right up to the base type;
an expr can be partial
* A typespec can include 'const' and other attributes; an expr doesn't
* A typespec uses '*' for pointers, an expr can use '*' or '[]' to deref
* A typespec uses '[]' for arrays; an expression can choose to use '*'
to index
* A typespec uses (*) for function pointers, but an expression can
choose to omit both that * and the accompanying ().
Further if you have an expression like (*A)[i] + (*B[i]) + (*C[i]), then
you necessarily have to elaborate each term, but it shouldn't be
necessary to repeat that typespec for each in the declarations.
C doesn't directly have the means to centralise a common type, you have
to do:
typedef int (*Arr)[10];
Arr A, B, C;
or:
typeof(int (*)[10]) A, B, C
Here there is a clear (and clean!) disconnect between each variable, and
its type. A variable's type shouldn't be something it has to 'wear'
wrapped around it, so that it literally looks like an expression. That
would be a bizarre concept.
But unfortunately people are used to thinking that this is normal:
int (*A)[10], (*B[10]), (*C)[10];
Even if you wrote this, perhaps you are passing those pointers to a
function:
F(A, B, C)
Hmm, those terms don't look much like their declarations, do they?!
> If you don't like the declaration syntax, it's possibly because
> you don't like the expression syntax for working with pointer
> dereferencing and arrays, which it mirrors. (You not liking
> C expression syntax: billion to one odds, right?)
Yes, making deref a prefix op was a bad idea. Postfix is much better
(but the choice of '*' makes that problematical).
My examples become (ignoring the unsuitability of '*'):
int A*[10], B*[10], C*[10];
A*[i] + B*[i] + C*[i]
Generally cleaner syntax all round. Maybe people would now use proper
pointer-to-array types (T(*)[] in current syntax) instead of the less
safe T*.
The -> operator can be dispensed with too: you write P*.m or Q**.m
instead of the messy (*P).m or P->m or (*Q)->m.
> IDEA: maybe you would like the "dedclaration follows use", if it was
> rendered over a different expression grammar in which pointer, arrays
> and whatnot work the way you like. If didn't dislike the "use",
> you might not dislike "declaration follows use".
>
> Now, from this "envelope shape":
>
> double (.......)[16];
>
> we know that whatever ..... is, it is an array of 16 doubles.
> This .... is called a "type hole" by functional programmers working
> in Haskell and whatnot.
>
> If we replace the hole with a name like abc:
>
> double (abc)[16];
>
> then what is being declared is that name. We get an object abc which is
> such an array. The parentheses are then unnecessary and we can drop
> them.
>
> If we plug in *f(int) instead of abc, then *f(int) isn't what is
> being declared: f is. But we know that when this f is called, and the
I'm lost, sorry. Things are getting more complicated, not simpler!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-04-12 12:57 +0000 |
| Message-ID | <20250412050238.916@kylheku.com> |
| In reply to | #392433 |
On 2025-04-12, bart <bc@freeuk.com> wrote: > On 12/04/2025 03:43, Kaz Kylheku wrote: >> On 2025-04-12, bart <bc@freeuk.com> wrote: > >>> C type syntax is famous for being difficult and confusing; I think most >>> will agree about that. Even the creators said so. >> >> If you had a function that takes an int, that returned a pointer to an >> array, how would you pass in 42, and then get at the third element? >> >> f(42) // gets the pointer to the array >> >> (*f(42)) // designates the array >> >> (*f(42))[2] // gets at the third element. >> >> Ok, now declaring a function of int, which returns a pointer to an array >> of 16 elements: >> >> (*f(int))[16]; >> >> Notice any resemblance? The 42 argumet has changed to a type specifier >> for the corresponding parameter type. The array reference turns into >> the size. Minor! > >> We need a type specifier to the elements: >> >> double (*f(int))[16]; >> >> Declaration follows use: it's not just a slogan, it's real! > > I'm sorry, but it doesn't work! The thought processes are entirely > different between writing expressions, and declaring types. They differ > in many ways anyway: The main difference is that the the expressions are the payload that does the work, whereas declarations are just mental overead. The thought process is that the C programmer has a data structure layout in their mind and can write expressions to navigate through it, from the top-level reference down to its leaves. But, oh crap, the C programmer has to declare the things they are using in that expression. C brings a nice simplification here. If you can write the expression to access the thing you are imagining, the declaration can be derived from that shape. > * A typespec needs a base type; an expr doesn't > * A typespec needs to express the whole thing right up to the base type; > an expr can be partial > * A typespec can include 'const' and other attributes; an expr doesn't > * A typespec uses '*' for pointers, an expr can use '*' or '[]' to deref > * A typespec uses '[]' for arrays; an expression can choose to use '*' > to index > * A typespec uses (*) for function pointers, but an expression can > choose to omit both that * and the accompanying (). "Declaration follow use" is not perfect or absolute, but it helps exactly with the confusing cases with mlutiple levels of pointers, arrays and functions. > C doesn't directly have the means to centralise a common type, you have > to do: > > typedef int (*Arr)[10]; > Arr A, B, C; > > or: > typeof(int (*)[10]) , B, C Why would you showing two ways how C has the direct means to centralize a common array type, to illustrate the claim that it doesn't? > Here there is a clear (and clean!) disconnect between each variable, and > its type. A variable's type shouldn't be something it has to 'wear' > wrapped around it, so that it literally looks like an expression. That > would be a bizarre concept. If you had thought of it first, you'd think it's brilliant. Dennis Ritchie really showed us a nice way to deal with messes of pointers, arrays and function pointers. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-12 14:33 +0100 |
| Message-ID | <vtdq2g$jddk$1@dont-email.me> |
| In reply to | #392435 |
On 12/04/2025 13:57, Kaz Kylheku wrote:
> On 2025-04-12, bart <bc@freeuk.com> wrote:
>> On 12/04/2025 03:43, Kaz Kylheku wrote:
>>> On 2025-04-12, bart <bc@freeuk.com> wrote:
>>
>>>> C type syntax is famous for being difficult and confusing; I think most
>>>> will agree about that. Even the creators said so.
>>>
>>> If you had a function that takes an int, that returned a pointer to an
>>> array, how would you pass in 42, and then get at the third element?
>>>
>>> f(42) // gets the pointer to the array
>>>
>>> (*f(42)) // designates the array
>>>
>>> (*f(42))[2] // gets at the third element.
>>>
>>> Ok, now declaring a function of int, which returns a pointer to an array
>>> of 16 elements:
>>>
>>> (*f(int))[16];
>>>
>>> Notice any resemblance? The 42 argumet has changed to a type specifier
>>> for the corresponding parameter type. The array reference turns into
>>> the size. Minor!
>>
>>> We need a type specifier to the elements:
>>>
>>> double (*f(int))[16];
>>>
>>> Declaration follows use: it's not just a slogan, it's real!
>>
>> I'm sorry, but it doesn't work! The thought processes are entirely
>> different between writing expressions, and declaring types. They differ
>> in many ways anyway:
>
> The main difference is that the the expressions are the payload that
> does the work, whereas declarations are just mental overead.
>
> The thought process is that the C programmer has a data structure
> layout in their mind and can write expressions to navigate through
> it, from the top-level reference down to its leaves.
>
> But, oh crap, the C programmer has to declare the things they are using
> in that expression.
>
> C brings a nice simplification here. If you can write the expression to
> access the thing you are imagining, the declaration can be derived
> from that shape.
>
>> * A typespec needs a base type; an expr doesn't
>> * A typespec needs to express the whole thing right up to the base type;
>> an expr can be partial
>> * A typespec can include 'const' and other attributes; an expr doesn't
>> * A typespec uses '*' for pointers, an expr can use '*' or '[]' to deref
>> * A typespec uses '[]' for arrays; an expression can choose to use '*'
>> to index
>> * A typespec uses (*) for function pointers, but an expression can
>> choose to omit both that * and the accompanying ().
>
> "Declaration follow use" is not perfect or absolute, but it helps
> exactly with the confusing cases with mlutiple levels of pointers,
> arrays and functions.
>
>> C doesn't directly have the means to centralise a common type, you have
>> to do:
>>
>> typedef int (*Arr)[10];
>> Arr A, B, C;
>>
>> or:
>> typeof(int (*)[10]) , B, C
>
> Why would you showing two ways how C has the direct means to centralize
> a common array type, to illustrate the claim that it doesn't?
Those aren't direct. The only direct means C has is this form:
T A, B, C
when all the type info is concentrated in T. But T can only be a simple
type, or the name of a user-defined type. (Or, in C23, typeof can be used).
The problems come when you use modifiers that are applied to either side
of each name:
T A, *B, (*C)[10]
It is these modifiers that are the bits that can be applied in expressions.
That whole concept was a mistake. Such modifiers belong with the base
type. That also allows all names declared in the list to share that
exact same type.
>> Here there is a clear (and clean!) disconnect between each variable, and
>> its type. A variable's type shouldn't be something it has to 'wear'
>> wrapped around it, so that it literally looks like an expression. That
>> would be a bizarre concept.
>
> If you had thought of it first, you'd think it's brilliant.
>
> Dennis Ritchie really showed us a nice way to deal with messes
> of pointers, arrays and function pointers.
The simplest function pointer type in C is this:
void(*)(void)
The simplest variable declaration is this:
void(*F)(void)
C23 (when it is widespread in 10-20 years) allows you to write
'void(*)()' instead.
I wouldn't call any of them 'nice'; they all look cryptic.
I write those two examples as:
ref proc
ref proc F
This comes from Algol68 which predated C by 4 years.
Now try a more complicated function pointer type...
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-04-13 04:53 +0200 |
| Message-ID | <vtf8um$1s1am$1@dont-email.me> |
| In reply to | #392435 |
On 12.04.2025 14:57, Kaz Kylheku wrote:
> On 2025-04-12, bart <bc@freeuk.com> wrote:
>> [...]
>
> The main difference is that the the expressions are the payload that
> does the work, whereas declarations are just mental overead.
(Not for me, but okay.)
> The thought process is that the C programmer has a data structure
> layout in their mind and can write expressions to navigate through
> it, from the top-level reference down to its leaves.
>
> But, oh crap, the C programmer has to declare the things they are using
> in that expression.
Different people might think differently. Myself (for example) I have
the structure in mind first, and then the natural traversal/navigation
through those structures; navigation follows the structure, which is
defined by the declaration. (And not vice versa.)
> C brings a nice simplification here. If you can write the expression to
> access the thing you are imagining, the declaration can be derived
> from that shape.
This "simplification" is what might be the reason for some to dislike
it. And its "rationale" to be "derived from that _shape_[sic!]" which
is probably the source of the convoluted declaration syntax.
WRT "shape"; I'm certainly someone who would not mind (or rather who'd
appreciate) to have a * declaration ('ptr') and a * operation ('deref')
clearly differentiated and I've no need for a common "shape"; here my
primary requirement is certainly a clean, non-convoluted declaration
syntax.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-12 15:43 +0200 |
| Message-ID | <vtdql9$kspt$1@dont-email.me> |
| In reply to | #392425 |
On 12/04/2025 03:27, bart wrote: > On 12/04/2025 00:59, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 11/04/2025 22:36, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>> [...] >>>>> Rubbish. Everyone finds C declaration syntax a nightmare. >>>> Rubbish. I find C declaration syntax annoying, not a "nightmare". >>> >>> Annoying would be having to get letter case or punctuation just right. >> [...] >>> So, yeah, a 'nightmare' is more apt than 'annoying'. >> >> Bart, bart, bart. > > > > > >> You made a false statement about how *everyone* feels about >> C's declaration syntax. > > So what would be a true statement? That everyone finds it at least midly > annoying? I don't find C's declaration syntax annoying in the least. What I /do/ find annoying at times is the way some programmers write declarations in C. But that is a very different thing. If someone wrote "int (*A)[10](int);" in code that I had to maintain, I would find that mildly annoying. If someone wrote "int long unsigned const long const const typedef A;", I would find it extremely annoying. But I don't have any problem writing : typedef int (*FIntInt)(int); FIntInt A[10]; or typedef const unsigned long long A; (other than that I'd want better names for the object or type). I write my C code in a way that I don't find annoying to read, nor do others that read me code. I'd recommend all programmers try to do the same (with the full understanding that different kinds of code will be read by different kinds of programmers). Like a great many things in C, if I were making the syntax for a language I would do it a little differently. Again, that is a different thing from saying that I find C's syntax a problem. And there /are/ things about C that I find annoying, or limiting. Some of these things I can work around using good tools and language extensions. Often I use C++ rather than C (C++ also has things I find annoying). However, C declaration syntax is not something that bothers me at all for the code I write. I'm sure that /some/ people find it annoying, at least in some situations. With a language used by so many people, pretty much every feature is going to annoy someone, and pretty much every programmer is going to find something annoying. But there will be a wide range of which things different people find annoying, and to what extent. Generalisations like you are giving, where you extrapolate your own rather radical opinions, are guaranteed to be wrong. > > C type syntax is famous for being difficult and confusing; I think most > will agree about that. Even the creators said so. I disagree with that claim. I think it is probably fair to say that advanced, complicated and multi-layer types are difficult in any programming language. It is also fair to say that the way some people write complicated types in C can be confusing - as can be the case in any language. C lets you write confusing types - it does not force you to do so. > > This was the discussion: > > BC: > > Humans have to parse it too. C must be the only non-esoteric language > where you need to use third-party tools (CDECL etc) to make sense of > type-declarations. Either that or follow complex spirular algorithms to > [decode] them. > > DB: > I have never heard of anyone other than you who views cdecl as a necessity. > > So, is that last statement true or not? Are you asking Keith to tell you about my personal experience? Yes, it is true. Why would I have said it otherwise? > I didn't say it was a necessity, > but that you need to use such tools or special methods to understand > them. And clearly, that would be the more complicated ones; people can > usually cope with 'int'. So you didn't say it was a necessity, you said people need to use them? Or are you suggesting that people who can understand what complicated C type declarations mean by reading the C code are somehow using "special methods" ? Other people might just call that knowing the language and being experienced at reading it. To be clear - I think putting a complicated type declaration on a single line makes code harder to read. Putting /anything/ complicated and composed of many parts in one condensed lump makes it harder to understand - regardless of the programming language, and regardless of whether it is programming or something else. Dividing complex things into smaller and more manageable parts is usually a good thing - within reason, of course. "An array of 10 objects each of which is a pointer to a function that takes an int parameter and returns an int" is not much clearer than "int (*A)[10](int)", and for people who are used to seeing such C declarations, the familiarity of the C version makes it much faster to parse. > > I replied to one sweeping statement with another. One "sweeping statement" was about a single person, the other was about everyone. >> You want to be treated better? Stop making deeply silly statements. > > DB was making light of the type syntax issue and pretty much dismissed > it out of hand. How should I have responded? > If you didn't make such wildly exaggerated remarks in the first place, you wouldn't have to respond to people telling you they are wildly exaggerated. No one - not me, and not anyone else in comp.lang.c - has ever claimed that C is perfect or flawless. What people have claimed is that they can understand the language, and write useful code in it, and that it is good enough for a lot of purposes. They have sometimes said why the language is the way it is, even though they think some things would have been better if done differently. > Not that it would cut any ice with him. Nothing is ever that complicated > or too onerous or too slow or too over the top or too badly designed or ... > A vast number of people have written a vast amount of code in C. Clearly it is /not/ too complicated, or onerous, or slow. Clearly the declaration syntax in C is not a "nightmare" for everyone - clearly most C programmers find it is good enough to do the job even if some people have issues with it. I write code in C. If it were too complicated, I would not do so. And often my choice to replace C is C++ - at the risk of making a sweeping generalisation, I think most programmers would agree that C++ is more complicated than C. Yet like the millions of other C++ programmers, I manage to write code in C++ too. > I suggest also that you stop taking throwaway comments too literally. > Yet, there is probably more truth in my remark than in David's. > > You might also consider that while many features of C have been copied, > I don't know of any language that has copied its type syntax. > If another language copied all of C's syntax, it would just be C. The way that types work in a language is fairly fundamental to the kind of language you have, so it's not surprising that there is a lot of variety in the syntax for types. Some languages /have/ copied the syntax, such as C++, D, and Objective-C. No doubt you will call these derivatives of C rather than new languages. You could then say the same about other type syntaxes - what languages have copied Pascal's type syntax, other than Pascal derivatives like Ada and Modula 2 ? So what if other newer languages have a different syntax for type declarations? It means their designers feel they have a better way of writing types that suit their new language. Fair enough. It doesn't imply that they think the C syntax is a "nightmare" (though of course they /may/ think that). > I wonder why? Do you think the designers had an opinion about it closer > to mine, or to David Brown's? > I have said multiple times that if I were to design a new programming language, its syntax would differ significantly from C's.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-12 17:52 +0100 |
| Message-ID | <vte5o1$umr8$1@dont-email.me> |
| In reply to | #392438 |
On 12/04/2025 14:43, David Brown wrote:
> On 12/04/2025 03:27, bart wrote:
>> C type syntax is famous for being difficult and confusing; I think
>> most will agree about that. Even the creators said so.
>
> I disagree with that claim. I think it is probably fair to say that
> advanced, complicated and multi-layer types are difficult in any
> programming language.
But a type that is a simple linear chain should be straightforward, and
usually is, just not in C. That was illustrated here:
array of 10 pointer to function taking int and returning int
1 2 3 4 5 6
The C correspond to that fantastically complicated type (an array of
function references!) is:
int (*A[10])(int);
6 3 1 2 4 5 (Not sure which bit is the '4')
The numbers below show the crazy mixed-up correspondence with the
left-to-right original. Using the made-up LTR syntax of a prior post:
[10]* fn(int)int A
1 2 3 4 5 6
The bits correspond EXACTLY.
Now I want a new type which is a pointer to such an array. In that new
syntax you just add * on the left:
*[10]* fn(int)int A
In the C, you also need to add *, but where?! It is by no means obvious.
In fact it is this (I had to employ Cdecl):
int (*(*A)[10])(int )
I had to add '*' and also '()' in a critical place. I still don't know
which of those * is which.
As I've many times, this is completely unfit for purpose. Beyond the
simplest examples, this is just gibberish.
With LTR syntax, you can create arbitrarily complex chains, and you will
always now exactly what they mean, and which * is which. Modifying them
is trivial:
C LTR style
int A[10] [10]int A # array of int
int *A[10] [10]*int A # array of pointer to int
int (*A)[10] *[10]int A # pointer to array of int
int *(*A)[] *[]*[]int A # ptr to array of ptr to int
int *(*A)[], B *[]*[]int A, B
In the last example, A and B are different types in the C column (B is a
simple int); in the LTR column, both are exactly the same type, another
advantage.
There is just no comparison. LTR style is far superior, more convenient,
more readable, easy to write, and less error prone.
> To be clear - I think putting a complicated type declaration on a single
> line makes code harder to read.
As C does it, yes. But the threshold at which it becomes gobbledygook is
too low.
> A vast number of people have written a vast amount of code in C. Clearly
> it is /not/ too complicated, or onerous, or slow.
That just means vast numbers have HAD to write complicated, onerous
code. What other choice did they have? What alternates to C were possible?
> I have said multiple times that if I were to design a new programming
> language, its syntax would differ significantly from C's.
But it would be a toy unless you could get it adopted by lots of people.
By your standards, even a DSL that you create for use in your
professional work would be a toy.
[toc] | [prev] | [next] | [standalone]
Page 8 of 35 — ← Prev page 1 … 6 7 [8] 9 10 … 35 Next page →
Back to top | Article view | comp.lang.c
csiph-web