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 2 of 35 — ← Prev page 1 [2] 3 4 … 35 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-06 05:47 -0700 |
| Message-ID | <86ldsdfocs.fsf@linuxsc.com> |
| In reply to | #392018 |
Thiago Adams <thiago.adams@gmail.com> writes:
> Em 4/4/2025 5:48 PM, Tim Rentsch escreveu:
>
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> What do you think of this control block?
>>>
>>> do
>>> {
>>> FILE f = fopen("file.txt", "r");
>>>
>>> if (f == NULL) quit; /*goes to else part*/
>>>
>>> /*success here*/
>>> for (int i =0; i < 10; i++){
>>> ...
>>> if (error) quit;
>>> }
>>>
>>> }
>>> else
>>> {
>>> /*some error*/
>>> }
>>
>> I think it doesn't belong in comp.lang.c.
>>
>> I also think you have been participating in comp.lang.c
>> long enough to know better. Kindly take your language
>> fantasies somewhere else.
>
> I think the only reason you're saying that is because it's not
> implemented in GCC, Clang, or maybe even MSVC.
You are wrong. I responded because there is nothing in
your posting that is suitable for comp.lang.c.
> I've never seen you complain about any GCC extensions here.
I don't remember seeing any posting in comp.lang.c that
discusses a gcc extension and nothing else. There are
plenty of postings that mention gcc extensions in passing,
along with other material that talks about C, but never
one that discusses gcc extensions exclusively.
Furthermore, even if there had been a posting that concerns
only a gcc extension and nothing else, and is one I didn't
respond to, that doesn't excuse your action. It isn't like
this is the first time you have posted something here that
is not about C but only about your fantasy language, and
also not the first time the unsuitability of such postings
has been pointed out. You're a repeat offender. So stop
pretending you are being picked on for no reason.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-06 16:13 +0300 |
| Message-ID | <20250406161323.00005809@yahoo.com> |
| In reply to | #392123 |
On Sun, 06 Apr 2025 05:47:47 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
> > Em 4/4/2025 5:48 PM, Tim Rentsch escreveu:
> >
> >> Thiago Adams <thiago.adams@gmail.com> writes:
> >>
> >>> What do you think of this control block?
> >>>
> >>> do
> >>> {
> >>> FILE f = fopen("file.txt", "r");
> >>>
> >>> if (f == NULL) quit; /*goes to else part*/
> >>>
> >>> /*success here*/
> >>> for (int i =0; i < 10; i++){
> >>> ...
> >>> if (error) quit;
> >>> }
> >>>
> >>> }
> >>> else
> >>> {
> >>> /*some error*/
> >>> }
> >>
> >> I think it doesn't belong in comp.lang.c.
> >>
> >> I also think you have been participating in comp.lang.c
> >> long enough to know better. Kindly take your language
> >> fantasies somewhere else.
> >
> > I think the only reason you're saying that is because it's not
> > implemented in GCC, Clang, or maybe even MSVC.
>
> You are wrong. I responded because there is nothing in
> your posting that is suitable for comp.lang.c.
>
> > I've never seen you complain about any GCC extensions here.
>
> I don't remember seeing any posting in comp.lang.c that
> discusses a gcc extension and nothing else. There are
> plenty of postings that mention gcc extensions in passing,
> along with other material that talks about C, but never
> one that discusses gcc extensions exclusively.
>
> Furthermore, even if there had been a posting that concerns
> only a gcc extension and nothing else, and is one I didn't
> respond to, that doesn't excuse your action. It isn't like
> this is the first time you have posted something here that
> is not about C but only about your fantasy language, and
> also not the first time the unsuitability of such postings
> has been pointed out. You're a repeat offender. So stop
> pretending you are being picked on for no reason.
Could you recommend a more appropriate place for Thiago and others where
they can discuss C-like fantasy languages?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-06 07:32 -0700 |
| Message-ID | <86ecy5fjin.fsf@linuxsc.com> |
| In reply to | #392124 |
Michael S <already5chosen@yahoo.com> writes:
> On Sun, 06 Apr 2025 05:47:47 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> Em 4/4/2025 5:48 PM, Tim Rentsch escreveu:
>>>
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>
>>>>> What do you think of this control block?
>>>>>
>>>>> do
>>>>> {
>>>>> FILE f = fopen("file.txt", "r");
>>>>>
>>>>> if (f == NULL) quit; /*goes to else part*/
>>>>>
>>>>> /*success here*/
>>>>> for (int i =0; i < 10; i++){
>>>>> ...
>>>>> if (error) quit;
>>>>> }
>>>>>
>>>>> }
>>>>> else
>>>>> {
>>>>> /*some error*/
>>>>> }
>>>>
>>>> I think it doesn't belong in comp.lang.c.
>>>>
>>>> I also think you have been participating in comp.lang.c
>>>> long enough to know better. Kindly take your language
>>>> fantasies somewhere else.
>>>
>>> I think the only reason you're saying that is because it's not
>>> implemented in GCC, Clang, or maybe even MSVC.
>>
>> You are wrong. I responded because there is nothing in
>> your posting that is suitable for comp.lang.c.
>>
>>> I've never seen you complain about any GCC extensions here.
>>
>> I don't remember seeing any posting in comp.lang.c that
>> discusses a gcc extension and nothing else. There are
>> plenty of postings that mention gcc extensions in passing,
>> along with other material that talks about C, but never
>> one that discusses gcc extensions exclusively.
>>
>> Furthermore, even if there had been a posting that concerns
>> only a gcc extension and nothing else, and is one I didn't
>> respond to, that doesn't excuse your action. It isn't like
>> this is the first time you have posted something here that
>> is not about C but only about your fantasy language, and
>> also not the first time the unsuitability of such postings
>> has been pointed out. You're a repeat offender. So stop
>> pretending you are being picked on for no reason.
>
> Could you recommend a more appropriate place for Thiago and others
> where they can discuss C-like fantasy languages?
The newsgroup comp.lang.misc seems like a natural candidate.
I don't know if comp.lang.misc has an official charter, but at
least to me new features of any widely used programming language
would appear to fall under the umbrella of comp.lang.misc.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-06 19:03 +0300 |
| Message-ID | <20250406190321.000001dc@yahoo.com> |
| In reply to | #392128 |
On Sun, 06 Apr 2025 07:32:16 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Sun, 06 Apr 2025 05:47:47 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> > >> Furthermore, even if there had been a posting that concerns > >> only a gcc extension and nothing else, and is one I didn't > >> respond to, that doesn't excuse your action. It isn't like > >> this is the first time you have posted something here that > >> is not about C but only about your fantasy language, and > >> also not the first time the unsuitability of such postings > >> has been pointed out. You're a repeat offender. So stop > >> pretending you are being picked on for no reason. > > > > Could you recommend a more appropriate place for Thiago and others > > where they can discuss C-like fantasy languages? > > The newsgroup comp.lang.misc seems like a natural candidate. > I don't know if comp.lang.misc has an official charter, but at > least to me new features of any widely used programming language > would appear to fall under the umbrella of comp.lang.misc. My question was not completely abstract. I did consider starting a discussion about possibility of inclusion of stackless co-routines into one of the future editions of C. Naturally, my ideas at this state are extremely in-concrete, much more so then the post of Thiago Adams that started this thread. So, if I ever come to it, which by itself is not very likely, do you think that comp.lang.misc would be better place than comp.lang.c ?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-07 05:45 -0700 |
| Message-ID | <86plhodtsw.fsf@linuxsc.com> |
| In reply to | #392136 |
Michael S <already5chosen@yahoo.com> writes: > On Sun, 06 Apr 2025 07:32:16 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Sun, 06 Apr 2025 05:47:47 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Furthermore, even if there had been a posting that concerns >>>> only a gcc extension and nothing else, and is one I didn't >>>> respond to, that doesn't excuse your action. It isn't like >>>> this is the first time you have posted something here that >>>> is not about C but only about your fantasy language, and >>>> also not the first time the unsuitability of such postings >>>> has been pointed out. You're a repeat offender. So stop >>>> pretending you are being picked on for no reason. >>> >>> Could you recommend a more appropriate place for Thiago and others >>> where they can discuss C-like fantasy languages? >> >> The newsgroup comp.lang.misc seems like a natural candidate. >> I don't know if comp.lang.misc has an official charter, but at >> least to me new features of any widely used programming language >> would appear to fall under the umbrella of comp.lang.misc. > > My question was not completely abstract. > I did consider starting a discussion about possibility of inclusion of > stackless co-routines into one of the future editions of C. > Naturally, my ideas at this state are extremely in-concrete, much more > so then the post of Thiago Adams that started this thread. > So, if I ever come to it, which by itself is not very likely, do you > think that comp.lang.misc would be better place than comp.lang.c ? Before giving an answer I would like to ask some questions. * How much does the (still fuzzy) idea depend on running in a C environment? Is it very specific to C, or might it be applicable to other procedural/imperative languages (for example, Pascal)? * How much does the current C language impact what you expect to propose? Which aspects of C need to be taken into consideration in forming the proposal, and how strongly do those considerations affect the specifics of what would be proposed? * Assuming a proposed extension has been fully worked out, how broad or how narrow do you think the interest would be in the general C community for a future C standard to incorporate the proposed extension? * Assuming you get to a point where you are happy with the details of a proposed extension, how likely is it that you would write a proposal for the C standard committee, and make the effort needed to shepherd it through the process of being accepted for a future C standard? I realize you probably don't have firm answers for some or all of these questions. As part of figuring everything out, you might want to start a discussion both of the general idea and also about what the answers to these questions might be. I think comp.lang.misc is a good place to have such a discussion, even if your ideas are still in the process of being formed; the discussion could then serve the dual purpose of getting the idea fleshed out and of determining how strongly the idea should be considered as part of a future C standard.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-07 21:02 +0300 |
| Message-ID | <20250407210248.00006457@yahoo.com> |
| In reply to | #392148 |
On Mon, 07 Apr 2025 05:45:19 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Sun, 06 Apr 2025 07:32:16 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> On Sun, 06 Apr 2025 05:47:47 -0700 > >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >>> > >>>> Furthermore, even if there had been a posting that concerns > >>>> only a gcc extension and nothing else, and is one I didn't > >>>> respond to, that doesn't excuse your action. It isn't like > >>>> this is the first time you have posted something here that > >>>> is not about C but only about your fantasy language, and > >>>> also not the first time the unsuitability of such postings > >>>> has been pointed out. You're a repeat offender. So stop > >>>> pretending you are being picked on for no reason. > >>> > >>> Could you recommend a more appropriate place for Thiago and others > >>> where they can discuss C-like fantasy languages? > >> > >> The newsgroup comp.lang.misc seems like a natural candidate. > >> I don't know if comp.lang.misc has an official charter, but at > >> least to me new features of any widely used programming language > >> would appear to fall under the umbrella of comp.lang.misc. > > > > My question was not completely abstract. > > I did consider starting a discussion about possibility of inclusion > > of stackless co-routines into one of the future editions of C. > > Naturally, my ideas at this state are extremely in-concrete, much > > more so then the post of Thiago Adams that started this thread. > > So, if I ever come to it, which by itself is not very likely, do you > > think that comp.lang.misc would be better place than comp.lang.c ? > > Before giving an answer I would like to ask some questions. > > * How much does the (still fuzzy) idea depend on running in a C > environment? Is it very specific to C, or might it be applicable > to other procedural/imperative languages (for example, Pascal)? > > * How much does the current C language impact what you expect to > propose? Which aspects of C need to be taken into consideration > in forming the proposal, and how strongly do those considerations > affect the specifics of what would be proposed? > Of course, proposals for similar feature in other procedural/imperative language would not be totally different. Pascal is more similar to C than many other procedural languages, so solution for Pascal would likely be more similar to C than for example, stackless co-routines that already exist in such languages like C# (that started current wave of popularity of the feature) or Python. However Pascal and C have enough not in common for significant difference in proposed syntax and implementation. Specifically, in Pascal: - heap management is built-n in the language - non-local goto is built-n in the language - nested procedures - everything related to separated compilation of the translation units is handwaved in the docs rather than strictly specified. May be it's not so in Extended Pascal standard, I never read it. Most importantly, Pascal in its hay days had different (from C) attitude with regard to standardization. Implementors, especially bigger ones, freely made very significant mutually incompatible extensions and nobody in community was upset about it. C way is more centralized. > * Assuming a proposed extension has been fully worked out, how > broad or how narrow do you think the interest would be in the > general C community for a future C standard to incorporate the > proposed extension? > My own interest is for microcontrollers, primarily 32-bit microcontrollers. Environments of interest are either without multitasking library at all (my favorite) or with relatively simple multitasking known as Real-time executives. In recent time the one which is pushed by MCU vendors, which helps popularity rather immensely, is called FreeRTOS. These environments are characterized by not especially tight code footprint but rather tight (writable) RAM footprint. I don't believe that the feature is interesting for application programming on "big" computers/OSes. IMHO, on "big" computers the same objectives can be achieved in cleaner way through full (==stackfull) coroutines or even by threads. Stackfull coroutines do not require integration into programming language, esp. into relatively low-level language, like C. They tend to be widely available for several decades on majority of widely used OSes. And they tend to be ignored by C programmers. Which, to me, suggests that the same would happen to more limited stackless variant. Anyway, application programming in C on "big" computers/OSes is a dying field, and probably deservingly so. WG14 Committee should acknowledge the fact by putting their needs at lowest priority. Unlike that programming MCUs in C is as healthy as ever. So should be prioritized higher. The 3rd field is kernel programming. I wrote my fare share of kernel drivers for Windows and a couple for Linux, but it never was my passion. Kernel programming always felt to me as unpleasant programming experience. I know that other people feel very differently about it. So, despite 1st hand experience, I don't consider myself qualified to judge if stackless coroutines can fit here or not. Although my unqualified opinion is "not". > * Assuming you get to a point where you are happy with the details > of a proposed extension, how likely is it that you would write a > proposal for the C standard committee, and make the effort needed > to shepherd it through the process of being accepted for a future > C standard? > Not likely. I would have to somehow convince somebody else to do it. > I realize you probably don't have firm answers for some or all of > these questions. As part of figuring everything out, you might want > to start a discussion both of the general idea and also about what > the answers to these questions might be. I think comp.lang.misc is > a good place to have such a discussion, even if your ideas are still > in the process of being formed; the discussion could then serve the > dual purpose of getting the idea fleshed out and of determining how > strongly the idea should be considered as part of a future C > standard.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-07 19:31 +0100 |
| Message-ID | <vt15lq$bjs0$3@dont-email.me> |
| In reply to | #392156 |
On 07/04/2025 19:02, Michael S wrote: > On Mon, 07 Apr 2025 05:45:19 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Sun, 06 Apr 2025 07:32:16 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>> On Sun, 06 Apr 2025 05:47:47 -0700 >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>>> >>>>>> Furthermore, even if there had been a posting that concerns >>>>>> only a gcc extension and nothing else, and is one I didn't >>>>>> respond to, that doesn't excuse your action. It isn't like >>>>>> this is the first time you have posted something here that >>>>>> is not about C but only about your fantasy language, and >>>>>> also not the first time the unsuitability of such postings >>>>>> has been pointed out. You're a repeat offender. So stop >>>>>> pretending you are being picked on for no reason. >>>>> >>>>> Could you recommend a more appropriate place for Thiago and others >>>>> where they can discuss C-like fantasy languages? >>>> >>>> The newsgroup comp.lang.misc seems like a natural candidate. >>>> I don't know if comp.lang.misc has an official charter, but at >>>> least to me new features of any widely used programming language >>>> would appear to fall under the umbrella of comp.lang.misc. >>> >>> My question was not completely abstract. >>> I did consider starting a discussion about possibility of inclusion >>> of stackless co-routines into one of the future editions of C. >>> Naturally, my ideas at this state are extremely in-concrete, much >>> more so then the post of Thiago Adams that started this thread. >>> So, if I ever come to it, which by itself is not very likely, do you >>> think that comp.lang.misc would be better place than comp.lang.c ? >> >> Before giving an answer I would like to ask some questions. >> >> * How much does the (still fuzzy) idea depend on running in a C >> environment? Is it very specific to C, or might it be applicable >> to other procedural/imperative languages (for example, Pascal)? >> >> * How much does the current C language impact what you expect to >> propose? Which aspects of C need to be taken into consideration >> in forming the proposal, and how strongly do those considerations >> affect the specifics of what would be proposed? >> > > Of course, proposals for similar feature in other procedural/imperative > language would not be totally different. Pascal is more similar to C > than many other procedural languages, so solution for Pascal would > likely be more similar to C than for example, stackless co-routines > that already exist in such languages like C# (that started current wave > of popularity of the feature) or Python. > However Pascal and C have enough not in common for significant > difference in proposed syntax and implementation. Specifically, in > Pascal: > - heap management is built-n in the language > - non-local goto is built-n in the language That's news to me. But then I only used an educational version. > - nested procedures > - everything related to separated compilation of the translation units > is handwaved in the docs rather than strictly specified. I don't think it's that strictly specified in C. Isn't it vaguely left to the implementation? Much of how different units share macros, types, structs and enums isn't part of the language at all AFAICS: it's just a by-product of different modules happening to include the same header files. But it could also be done by repeating declarations in each module; it's rather ad hoc. The Pascal I used only worked with one module; more recent versions do seem to have formal interfaces which are part of the language. So it is more rigorous than C. > May be it's > not so in Extended Pascal standard, I never read it. > > Most importantly, Pascal in its hay days had different (from C) > attitude with regard to standardization. Implementors, especially > bigger ones, freely made very significant mutually incompatible > extensions and nobody in community was upset about it. C way is more > centralized. I have a feeling that there were WAY more variations of C than Pascal, largely because C was more popular and more widespread. You still see this know when you delve into systems and applications headers which are often a mess of '#ifdef' blocks which special-case specific compiler versions which all have different characteristics.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-08 10:12 +0200 |
| Message-ID | <vt2lp6$1qtjd$1@dont-email.me> |
| In reply to | #392160 |
On 07/04/2025 20:31, bart wrote: > On 07/04/2025 19:02, Michael S wrote: >> On Mon, 07 Apr 2025 05:45:19 -0700 >> Of course, proposals for similar feature in other procedural/imperative >> language would not be totally different. Pascal is more similar to C >> than many other procedural languages, so solution for Pascal would >> likely be more similar to C than for example, stackless co-routines >> that already exist in such languages like C# (that started current wave >> of popularity of the feature) or Python. >> However Pascal and C have enough not in common for significant >> difference in proposed syntax and implementation. Specifically, in >> Pascal: >> - heap management is built-n in the language >> - non-local goto is built-n in the language > > That's news to me. But then I only used an educational version. > >> - nested procedures >> - everything related to separated compilation of the translation units >> is handwaved in the docs rather than strictly specified. > > I don't think it's that strictly specified in C. Isn't it vaguely left > to the implementation? > No. > Much of how different units share macros, types, structs and enums isn't > part of the language at all AFAICS: it's just a by-product of different > modules happening to include the same header files. > Linkage is explained in 6.2.2 - only identifiers with external linkage are shared amongst translation units. Macros, types, enums are all have no linkage and are therefore never shared. The only way to make new non-standard types in C is with "struct", "union" or "enum". Section 6.2.7 of the standard sets out simply and clearly what is required for two types in different translation units to be compatible. (It doesn't make sense to say they are the "same type" in C lingo, since types have no linkage, but compatibility is the important point.) Sharing a definition in a header file is normally the easiest way to ensure that the types used in different translation files are compatible, but it is not required. > But it could also be done by repeating declarations in each module; it's > rather ad hoc. It is not remotely "ad hoc" - as far as the language is concerned, including a header file /is/ repeating the declaration in the different translation units. The way C handles this kind of thing is arguably weaker than in languages that have proper modules (like Ada, or Modula 2), and much more open to mistakes. On the other hand, it is very flexible and simple to understand, and does not need additional specialised object files or "interface" files. It is possible to write C code in an "ad hoc" manner (such as declaring an "extern" identifier within a C file rather than a header file), but the language definition is not "ad hoc". > > The Pascal I used only worked with one module; more recent versions do > seem to have formal interfaces which are part of the language. So it is > more rigorous than C. > Yes, most Pascal versions suitable for real development (rather than the older teaching versions) have more formal interfaces. Personally, I prefer more formal interfaces - more formality and stronger typing reduce flexibility but also reduce the risk of some kinds of errors, and can make a language more amenable to analysis. > >> May be it's >> not so in Extended Pascal standard, I never read it. >> >> Most importantly, Pascal in its hay days had different (from C) >> attitude with regard to standardization. Implementors, especially >> bigger ones, freely made very significant mutually incompatible >> extensions and nobody in community was upset about it. C way is more >> centralized. > > I have a feeling that there were WAY more variations of C than Pascal, > largely because C was more popular and more widespread. > I suspect you are wrong here. There are certainly far more C compilers than Pascal compilers, and there are minor variations between the C compilers, but even prior to K&R's book the differences between C compilers was smaller than between the different Pascal versions. Pascal was standardised, but standard Pascal was too limited for most commercial use and different vendors build on it - with Borland's line being the most relevant. Comparing modern Delphi and standard Pascal is a bit like comparing C# with K&R C. > You still see this know when you delve into systems and applications > headers which are often a mess of '#ifdef' blocks which special-case > specific compiler versions which all have different characteristics. > Certainly there are variations in the details - in particular, there are lots of things in C (and Pascal) that are "implementation defined". It is the similarity between C compilers that means that often all you need is some #ifdef's for low-level or library code shared between C compilers on significantly different systems or targets. If you want to write a low-level library for Free Pascal, Delphi, GNU Pascal, and Pascal-P, you write four versions of it.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 12:35 +0100 |
| Message-ID | <vt31m5$2513i$1@dont-email.me> |
| In reply to | #392185 |
On 08/04/2025 09:12, David Brown wrote:
> On 07/04/2025 20:31, bart wrote:
>> On 07/04/2025 19:02, Michael S wrote:
>>> On Mon, 07 Apr 2025 05:45:19 -0700
>
>>> Of course, proposals for similar feature in other procedural/imperative
>>> language would not be totally different. Pascal is more similar to C
>>> than many other procedural languages, so solution for Pascal would
>>> likely be more similar to C than for example, stackless co-routines
>>> that already exist in such languages like C# (that started current wave
>>> of popularity of the feature) or Python.
>>> However Pascal and C have enough not in common for significant
>>> difference in proposed syntax and implementation. Specifically, in
>>> Pascal:
>>> - heap management is built-n in the language
>>> - non-local goto is built-n in the language
>>
>> That's news to me. But then I only used an educational version.
>>
>>> - nested procedures
>>> - everything related to separated compilation of the translation units
>>> is handwaved in the docs rather than strictly specified.
>>
>> I don't think it's that strictly specified in C. Isn't it vaguely left
>> to the implementation?
>>
>
> No.
C simply has the requirement for separate compilation of modules. Where
does it specify how the implementation does that?
>> Much of how different units share macros, types, structs and enums
>> isn't part of the language at all AFAICS: it's just a by-product of
>> different modules happening to include the same header files.
>>
>
> Linkage is explained in 6.2.2 - only identifiers with external linkage
> are shared amongst translation units. Macros, types, enums are all have
> no linkage and are therefore never shared.
From the programmer point of view, they are shared. But the language
provides no specific mechanism for that.
> The only way to make new non-standard types in C is with "struct",
> "union" or "enum". Section 6.2.7 of the standard sets out simply and
> clearly what is required for two types in different translation units to
> be compatible. (It doesn't make sense to say they are the "same type"
> in C lingo, since types have no linkage, but compatibility is the
> important point.)
>
> Sharing a definition in a header file is normally the easiest way to
> ensure that the types used in different translation files are
> compatible, but it is not required.
>
>> But it could also be done by repeating declarations in each module;
>> it's rather ad hoc.
>
> It is not remotely "ad hoc" - as far as the language is concerned,
> including a header file /is/ repeating the declaration in the different
> translation units.
The programmer can achieve the objective in multiple ways; that's what's
ad hoc. The implementation itself works by crossing its fingers and
hoping that the multiple declarations of the common entity X that are
seen by the different translation unit are fully compatible.
But this need not be the case. For example this is module A:
--------------------------
#include <stdio.h>
typedef struct point {float a; float b;} Point;
float dist(Point);
int main(void) {
Point p = {3, 4};
printf("%f\n", dist(p));
}
--------------------------
And this is module B that defines 'dist':
--------------------------
#include <math.h>
typedef float length;
typedef struct _tag {length x, y;} vector;
length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
--------------------------
The types involved are somewhat different, but are compatible enough for
it to work.
However, they could also be different enough (in a more elaborate
example) for things to superficially work.
This is what I mean by 'ad hoc'.
This is how it looks when there is language support; first module A:
--------------------------
module b # (imports b)
proc main=
point p := (3, 4)
println dist(p)
end
--------------------------
Module B:
--------------------------
global record point = (real32 x, y)
global fun dist(point p)real32 = sqrt(sqr(p.x) + sqr(p.y))
--------------------------
(Example from one of mine, which uses whole-program compilation) Here,
unlike C, you need to decide which module owns and exports the type.
Then, there is only that one version which is shared.
However similar problems to C can occur when sharing across /programs/,
which could be written in different languages (eg. libraries).
I don't know if or how the C standard addresses that, since it can only
talk about the C language. For that matter, a single program with
independently compiled modules might have only some of those in C.
So there is even more scope for ad hoc-ness.
> The way C handles this kind of thing is arguably
> weaker than in languages that have proper modules (like Ada, or Modula
> 2), and much more open to mistakes. On the other hand, it is very
> flexible and simple to understand,
The preprocessor mechanisms available to work with source code are
fairly easy to grasp (but may be complex in practice with multiple
nested headers spread over a file system).
But I had, and do still have, difficulty with how exactly you import and
export entities, even ones with linkage.
How compilers deal with it have changed. But right now, if I put this in
a header shared by A and B modules:
int abc;
I get 'multiple definition' of abc (from some compilers; others have no
problem).
If I stick 'extern' in front, I get 'undefined reference' of abc. To
make it work, 'extern int abc' is shared, and one module must see 'int abc'.
However if I need to initialise the variable:
extern int table[]; // shared
int table[] = (10, 20, 30)
then other modules can't pick up length of the array.
and does not need additional
> specialised object files or "interface" files. It is possible to write
> C code in an "ad hoc" manner (such as declaring an "extern" identifier
> within a C file rather than a header file), but the language definition
> is not "ad hoc".
So, what are the rules again for mixing 'extern' and 'static'
declarations? Since this passes gcc:
static int def;
static int def;
extern int def;
static int def;
but this doesn't:
extern int def;
static int def;
static int def;
static int def;
Are you sure they aren't ad hoc? Simply saying that the C standard
enumerates the legal combinations doesn't make them not so!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-08 16:50 +0200 |
| Message-ID | <vt3d4g$2djqe$1@dont-email.me> |
| In reply to | #392194 |
On 08/04/2025 13:35, bart wrote:
> On 08/04/2025 09:12, David Brown wrote:
>> On 07/04/2025 20:31, bart wrote:
>>> On 07/04/2025 19:02, Michael S wrote:
>>>> On Mon, 07 Apr 2025 05:45:19 -0700
>>
>>>> Of course, proposals for similar feature in other procedural/imperative
>>>> language would not be totally different. Pascal is more similar to C
>>>> than many other procedural languages, so solution for Pascal would
>>>> likely be more similar to C than for example, stackless co-routines
>>>> that already exist in such languages like C# (that started current wave
>>>> of popularity of the feature) or Python.
>>>> However Pascal and C have enough not in common for significant
>>>> difference in proposed syntax and implementation. Specifically, in
>>>> Pascal:
>>>> - heap management is built-n in the language
>>>> - non-local goto is built-n in the language
>>>
>>> That's news to me. But then I only used an educational version.
>>>
>>>> - nested procedures
>>>> - everything related to separated compilation of the translation units
>>>> is handwaved in the docs rather than strictly specified.
>>>
>>> I don't think it's that strictly specified in C. Isn't it vaguely
>>> left to the implementation?
>>>
>>
>> No.
>
> C simply has the requirement for separate compilation of modules. Where
> does it specify how the implementation does that?
The details of how a compiler (and linker) run are not part of a
language specification. But how separately compiled units interact is
in the standard.
>
>>> Much of how different units share macros, types, structs and enums
>>> isn't part of the language at all AFAICS: it's just a by-product of
>>> different modules happening to include the same header files.
>>>
>>
>> Linkage is explained in 6.2.2 - only identifiers with external linkage
>> are shared amongst translation units. Macros, types, enums are all
>> have no linkage and are therefore never shared.
>
> From the programmer point of view, they are shared. But the language
> provides no specific mechanism for that.
>
No, of course not. A language specification says what the language
/means/, not how tools make that happen. That is a good thing - if the
C standards had specified that translation units get compiled to object
files and then a linker is used, you couldn't have link-time
optimisation or whole-program compilation.
>
>
>> The only way to make new non-standard types in C is with "struct",
>> "union" or "enum". Section 6.2.7 of the standard sets out simply and
>> clearly what is required for two types in different translation units
>> to be compatible. (It doesn't make sense to say they are the "same
>> type" in C lingo, since types have no linkage, but compatibility is
>> the important point.)
>>
>> Sharing a definition in a header file is normally the easiest way to
>> ensure that the types used in different translation files are
>> compatible, but it is not required.
>>
>>> But it could also be done by repeating declarations in each module;
>>> it's rather ad hoc.
>>
>> It is not remotely "ad hoc" - as far as the language is concerned,
>> including a header file /is/ repeating the declaration in the
>> different translation units.
>
> The programmer can achieve the objective in multiple ways; that's what's
> ad hoc.
As I said - the C standards and the language are not ad hoc. But it is
possible to write ad hoc code.
> The implementation itself works by crossing its fingers and
> hoping that the multiple declarations of the common entity X that are
> seen by the different translation unit are fully compatible.
>
Nope. You are just making stuff up in your never-ending quest to
misunderstand C and pretend everything about it is terrible.
But it is certainly true that the inter-unit interaction in C is less
rigid and controlled than in some other languages. That keeps the
language and its definition simpler, allows simpler implementations, and
gives more programmer flexibility (especially if they are happy with
non-portable code). The flip side is that it also allows more abuse or
accidental mistakes, and requires more advanced tools to diagnose
problems (such as using link-time optimising compilers or whole-program
analysis tools).
> But this need not be the case. For example this is module A:
>
> --------------------------
> #include <stdio.h>
>
> typedef struct point {float a; float b;} Point;
>
> float dist(Point);
>
> int main(void) {
> Point p = {3, 4};
> printf("%f\n", dist(p));
> }
> --------------------------
>
> And this is module B that defines 'dist':
>
>
> --------------------------
> #include <math.h>
>
> typedef float length;
> typedef struct _tag {length x, y;} vector;
>
> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
> --------------------------
>
> The types involved are somewhat different, but are compatible enough for
> it to work.
The two types are entirely compatible. "typedef" does not introduce a
new type, and struct types in different modules are compatible if they
are build from the same compatible field types in the same order.
>
> However, they could also be different enough (in a more elaborate
> example) for things to superficially work.
Not in C.
>
> This is what I mean by 'ad hoc'.
If that's what you meant by "ad hoc", you were wrong about C being "ad hoc".
>
>> The way C handles this kind of thing is arguably weaker than in
>> languages that have proper modules (like Ada, or Modula 2), and much
>> more open to mistakes. On the other hand, it is very flexible and
>> simple to understand,
>
>
> The preprocessor mechanisms available to work with source code are
> fairly easy to grasp (but may be complex in practice with multiple
> nested headers spread over a file system).
That's like complaining that integer addition is complex because someone
might want to add 26 digit numbers. Stop being silly.
>
> But I had, and do still have, difficulty with how exactly you import and
> export entities, even ones with linkage.
That sounds very much like a "Bart" problem. If you /genuinely/ want to
know, and you can't figure it out with a quick google search, reading
the page in the standards, or looking at an introduction to C book, then
please ask. If you are just trying to claim opportunities to say it's
all so difficult and confusing, then don't bother.
>
> How compilers deal with it have changed.
As a general rule, they have not.
But it is true that some compilers have by default supported an
extension that was designed to make interoperability with Fortran
programs easier - and that extension allows C programmers to make
mistakes if they don't understand the very simple rule of defining
objects only once in a C program. (I pushed for this extension to be
disabled by default in gcc.)
> But right now, if I put this in
> a header shared by A and B modules:
>
> int abc;
>
> I get 'multiple definition' of abc (from some compilers; others have no
> problem).
It is an error to link these translation units in C - but some compilers
accepted it.
You know how linkers work with assembly, so it is easiest to explain it
in terms of a typical implementation (though the C standard does not
require any of this). When you write "int abc;" at file scope, without
"static", the compiler will put the symbol in ".bss" if it is
zero-initialised, and in ".data" if it is explicitly initialised. At
link time, if the linker sees the same symbol defined more than once, it
complains.
The exception is that if the linker sees identically named symbols in a
section called ".common", they are merged without complaint - that is
the way Fortran handles linkage. So some compilers put uninitialised
data in a ".common" section rather than ".bss", allowing them to be linked.
This is, of course, a terrible idea, and a flaw in those compilers.
>
> If I stick 'extern' in front, I get 'undefined reference' of abc. To
> make it work, 'extern int abc' is shared, and one module must see 'int
> abc'.
Yes. One definition in the program as a whole, and as many declarations
as you like. Simple.
>
> However if I need to initialise the variable:
>
> extern int table[]; // shared
> int table[] = (10, 20, 30)
>
> then other modules can't pick up length of the array.
>
Correct.
>
> and does not need additional
>> specialised object files or "interface" files. It is possible to
>> write C code in an "ad hoc" manner (such as declaring an "extern"
>> identifier within a C file rather than a header file), but the
>> language definition is not "ad hoc".
>
> So, what are the rules again for mixing 'extern' and 'static'
> declarations? Since this passes gcc:
>
> static int def;
> static int def;
> extern int def;
> static int def;
>
> but this doesn't:
>
> extern int def;
> static int def;
> static int def;
> static int def;
The rules are given in 6.2.2 of the standard under "Linkages of
identifiers", as I mentioned earlier. Of course people don't mix
storage class specifiers like this - while the language rules make it
clear what happens as far as the semantics of C are concerned, such
duplications would be confusing or at best redundant.
>
> Are you sure they aren't ad hoc? Simply saying that the C standard
> enumerates the legal combinations doesn't make them not so!
>
The C standard gives clear rules here that make sense. That does not
mean they are the /only/ set of rules a language could have that makes
sense, but they are not "ad hoc". That would imply that combinations
like this could have unpredictable meanings.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 17:28 +0100 |
| Message-ID | <vt3iqh$2ka99$1@dont-email.me> |
| In reply to | #392198 |
On 08/04/2025 15:50, David Brown wrote:
> On 08/04/2025 13:35, bart wrote:
>> But this need not be the case. For example this is module A:
>>
>> --------------------------
>> #include <stdio.h>
>>
>> typedef struct point {float a; float b;} Point;
>>
>> float dist(Point);
>>
>> int main(void) {
>> Point p = {3, 4};
>> printf("%f\n", dist(p));
>> }
>> --------------------------
>>
>> And this is module B that defines 'dist':
>>
>>
>> --------------------------
>> #include <math.h>
>>
>> typedef float length;
>> typedef struct _tag {length x, y;} vector;
>>
>> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
>> --------------------------
>>
>> The types involved are somewhat different, but are compatible enough
>> for it to work.
>
> The two types are entirely compatible.
Are they? So why does gcc report an error here (the two types are from
my example):
typedef struct point {float a; float b;} Point;
typedef float length;
typedef struct _tag {length x, y;} vector;
Point p;
vector v;
p=v;
c.c:14:5: error: incompatible types when assigning to type 'Point' {aka
'struct point'} from type
ector' {aka 'struct _tag'}
14 | p=v;
| ^
> "typedef" does not introduce a
> new type, and struct types in different modules are compatible if they
> are build from the same compatible field types in the same order.
>
>>
>> However, they could also be different enough (in a more elaborate
>> example) for things to superficially work.
>
> Not in C.
Really? I could have added a dozen extra fields to one (or a pile of
incompatible fields to both), and it can still work (especially if I
pass the struct by reference).
>> The preprocessor mechanisms available to work with source code are
>> fairly easy to grasp (but may be complex in practice with multiple
>> nested headers spread over a file system).
> That's like complaining that integer addition is complex because someone
> might want to add 26 digit numbers. Stop being silly.
You're missing the point: the concept may be simple, but as typically
used in C, it is can be much more complex than necessary. Doing:
#include "lib.h"
is not enough; there may be a dozen different header locations (from
nested includes) that need to be made known to the compiler, so you need
to figure them out first!
A program may comprise 100 .c files, but use 37 different headers in
mixed, possible nested combinations across those 100 modules. You can't
in general tie one .c file to a specific .h file; /that/ would be simpler.
So the usual thing applies in C: the language lays down some vague
rules, beyond that it's a free-for-all.
You choose to call that 'being flexible'; I might call it something else.
>
>>
>> But I had, and do still have, difficulty with how exactly you import
>> and export entities, even ones with linkage.
>
> That sounds very much like a "Bart" problem.
You really think that I wouldn't know how to do this if the language
provided genuinely simple and well-thought-out and consistent rules?
Here are some rules from another of my languages; this time it's an
assembler:
L1: # local label
L2:: # exported label
call puts* # imported symbol
call fred # name defined in this file (which may be
# local or exported depending on : or ::)
There are no explicit sets of declarations (eg. 'extern puts' as in
other products); no forward declarations are needed.
Simple, yes?
> If you /genuinely/ want to
> know, and you can't figure it out with a quick google search, reading
> the page in the standards, or looking at an introduction to C book, then
> please ask. If you are just trying to claim opportunities to say it's
> all so difficult and confusing, then don't bother.
Ah yes, the Microsoft approach: provide huge amounts of resources,
manuals, training courses etc, rather than making something actually simple!
>>
>> How compilers deal with it have changed.
>
> As a general rule, they have not.
>
> But it is true that some compilers have by default supported an
> extension that was designed to make interoperability with Fortran
> programs easier
Which means a pile of badly written programs.
>> However if I need to initialise the variable:
>>
>> extern int table[]; // shared
>> int table[] = (10, 20, 30)
>>
>> then other modules can't pick up length of the array.
>>
>
> Correct.
And the workaround is...?
(Maybe you can appreciate one of many reasons why I normally generate C
code for a project as one source file.)
> The C standard gives clear rules here that make sense.
What's the rational for allowing both static and extern versions of the
same entity in the same file? And if that is allowed, why does the order
matter?
(In my compiler I gave up trying to make sense of it, and just ended up
allow any combination unless it was clearly wrong.)
That does not
> mean they are the /only/ set of rules a language could have that makes
> sense, but they are not "ad hoc". That would imply that combinations
> like this could have unpredictable meanings.
I don't mean 'ad hoc' to be 'indeterminate'. More like, 'mess', or
'free-for-all'.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-08 10:32 -0700 |
| Message-ID | <868qoaeezc.fsf@linuxsc.com> |
| In reply to | #392203 |
bart <bc@freeuk.com> writes:
> On 08/04/2025 15:50, David Brown wrote:
>
>> On 08/04/2025 13:35, bart wrote:
>>
>>> But this need not be the case. For example this is module A:
>>>
>>> --------------------------
>>> #include <stdio.h>
>>>
>>> typedef struct point {float a; float b;} Point;
>>>
>>> float dist(Point);
>>>
>>> int main(void) {
>>> Point p = {3, 4};
>>> printf("%f\n", dist(p));
>>> }
>>> --------------------------
>>>
>>> And this is module B that defines 'dist':
>>>
>>>
>>> --------------------------
>>> #include <math.h>
>>>
>>> typedef float length;
>>> typedef struct _tag {length x, y;} vector;
>>>
>>> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
>>> --------------------------
>>>
>>> The types involved are somewhat different, but are compatible
>>> enough for it to work.
>>
>> The two types are entirely compatible.
>
> Are they?
No, they are not. The type names 'Point' and 'vector' name two
distinct types, and those types are not compatible, because
the two struct tags are different.
Because the two types are not compatible, even just calling the
function dist() is undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 19:04 +0100 |
| Message-ID | <vt3oeo$2oq3p$1@dont-email.me> |
| In reply to | #392206 |
On 08/04/2025 18:32, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> On 08/04/2025 15:50, David Brown wrote:
>>
>>> On 08/04/2025 13:35, bart wrote:
>>>
>>>> But this need not be the case. For example this is module A:
>>>>
>>>> --------------------------
>>>> #include <stdio.h>
>>>>
>>>> typedef struct point {float a; float b;} Point;
>>>>
>>>> float dist(Point);
>>>>
>>>> int main(void) {
>>>> Point p = {3, 4};
>>>> printf("%f\n", dist(p));
>>>> }
>>>> --------------------------
>>>>
>>>> And this is module B that defines 'dist':
>>>>
>>>>
>>>> --------------------------
>>>> #include <math.h>
>>>>
>>>> typedef float length;
>>>> typedef struct _tag {length x, y;} vector;
>>>>
>>>> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
>>>> --------------------------
>>>>
>>>> The types involved are somewhat different, but are compatible
>>>> enough for it to work.
>>>
>>> The two types are entirely compatible.
>>
>> Are they?
>
> No, they are not. The type names 'Point' and 'vector' name two
> distinct types, and those types are not compatible, because
> the two struct tags are different.
>
> Because the two types are not compatible, even just calling the
> function dist() is undefined behavior.
I get an incompatible error (from the example you snipped) even when I
remove both struct tags.
I can't use the same struct tag in the same scope as one will clash with
the other. But if I have the second in an inner scope, then I again get
the error.
It doesn't seem to be anything to do with struct tags.
Two typedefs for same struct layout appear to create distinct types;
this fails:
typedef struct {float x, y;} Point;
typedef struct {float x, y;} vector;
Point p;
vector v;
p=v;
But this works:
typedef struct {float x, y;} Point, vector;
Point p;
vector v;
p=v;
So it seems to depend on whether Point and vector share the same
internal descriptor for the struct.
In my original example, the structs were defined in separate translation
unit, so the compiler has to take things on trust.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-08 14:18 -0700 |
| Message-ID | <86mscqcpy1.fsf@linuxsc.com> |
| In reply to | #392211 |
bart <bc@freeuk.com> writes:
> On 08/04/2025 18:32, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> On 08/04/2025 15:50, David Brown wrote:
>>>
>>>> On 08/04/2025 13:35, bart wrote:
>>>>
>>>>> But this need not be the case. For example this is module A:
>>>>>
>>>>> --------------------------
>>>>> #include <stdio.h>
>>>>>
>>>>> typedef struct point {float a; float b;} Point;
>>>>>
>>>>> float dist(Point);
>>>>>
>>>>> int main(void) {
>>>>> Point p = {3, 4};
>>>>> printf("%f\n", dist(p));
>>>>> }
>>>>> --------------------------
>>>>>
>>>>> And this is module B that defines 'dist':
>>>>>
>>>>>
>>>>> --------------------------
>>>>> #include <math.h>
>>>>>
>>>>> typedef float length;
>>>>> typedef struct _tag {length x, y;} vector;
>>>>>
>>>>> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
>>>>> --------------------------
>>>>>
>>>>> The types involved are somewhat different, but are compatible
>>>>> enough for it to work.
>>>>
>>>> The two types are entirely compatible.
>>>
>>> Are they?
>>
>> No, they are not. The type names 'Point' and 'vector' name two
>> distinct types, and those types are not compatible, because
>> the two struct tags are different.
>>
>> Because the two types are not compatible, even just calling the
>> function dist() is undefined behavior.
>
> I get an incompatible error (from the example you snipped) even when I
> remove both struct tags.
>
> I can't use the same struct tag in the same scope as one will clash
> with the other. But if I have the second in an inner scope, then I
> again get the error.
If you want to make a point or ask a question about C code,
SHOW THE CODE. And show all of it. Don't make people guess
by showing only some of the code or by giving just a description.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 23:38 +0100 |
| Message-ID | <vt48go$35hh3$2@dont-email.me> |
| In reply to | #392221 |
On 08/04/2025 22:18, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>
>> On 08/04/2025 18:32, Tim Rentsch wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>> On 08/04/2025 15:50, David Brown wrote:
>>>>
>>>>> On 08/04/2025 13:35, bart wrote:
>>>>>
>>>>>> But this need not be the case. For example this is module A:
>>>>>>
>>>>>> --------------------------
>>>>>> #include <stdio.h>
>>>>>>
>>>>>> typedef struct point {float a; float b;} Point;
>>>>>>
>>>>>> float dist(Point);
>>>>>>
>>>>>> int main(void) {
>>>>>> Point p = {3, 4};
>>>>>> printf("%f\n", dist(p));
>>>>>> }
>>>>>> --------------------------
>>>>>>
>>>>>> And this is module B that defines 'dist':
>>>>>>
>>>>>>
>>>>>> --------------------------
>>>>>> #include <math.h>
>>>>>>
>>>>>> typedef float length;
>>>>>> typedef struct _tag {length x, y;} vector;
>>>>>>
>>>>>> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
>>>>>> --------------------------
>>>>>>
>>>>>> The types involved are somewhat different, but are compatible
>>>>>> enough for it to work.
>>>>>
>>>>> The two types are entirely compatible.
>>>>
>>>> Are they?
>>>
>>> No, they are not. The type names 'Point' and 'vector' name two
>>> distinct types, and those types are not compatible, because
>>> the two struct tags are different.
>>>
>>> Because the two types are not compatible, even just calling the
>>> function dist() is undefined behavior.
>>
>> I get an incompatible error (from the example you snipped) even when I
>> remove both struct tags.
>>
>> I can't use the same struct tag in the same scope as one will clash
>> with the other. But if I have the second in an inner scope, then I
>> again get the error.
>
> If you want to make a point or ask a question about C code,
> SHOW THE CODE. And show all of it. Don't make people guess
> by showing only some of the code or by giving just a description.
I'm showing the code but you keep snipping it! If you want testable
code, just wrap it with 'int main() { ... }'. (I assumed you could
figure that out.)
Here I was responding to your remark that the types are incompatible
because the struct tags are different. If by that you mean 'struct X' vs
'struct Y', then I said that isn't the case, as my example without such
tags showed.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-08 16:27 -0700 |
| Message-ID | <86iknecjz8.fsf@linuxsc.com> |
| In reply to | #392225 |
bart <bc@freeuk.com> writes:
> On 08/04/2025 22:18, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> On 08/04/2025 18:32, Tim Rentsch wrote:
>>>
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> On 08/04/2025 15:50, David Brown wrote:
>>>>>
>>>>>> On 08/04/2025 13:35, bart wrote:
>>>>>>
>>>>>>> But this need not be the case. For example this is module A:
>>>>>>>
>>>>>>> --------------------------
>>>>>>> #include <stdio.h>
>>>>>>>
>>>>>>> typedef struct point {float a; float b;} Point;
>>>>>>>
>>>>>>> float dist(Point);
>>>>>>>
>>>>>>> int main(void) {
>>>>>>> Point p = {3, 4};
>>>>>>> printf("%f\n", dist(p));
>>>>>>> }
>>>>>>> --------------------------
>>>>>>>
>>>>>>> And this is module B that defines 'dist':
>>>>>>>
>>>>>>>
>>>>>>> --------------------------
>>>>>>> #include <math.h>
>>>>>>>
>>>>>>> typedef float length;
>>>>>>> typedef struct _tag {length x, y;} vector;
>>>>>>>
>>>>>>> length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
>>>>>>> --------------------------
>>>>>>>
>>>>>>> The types involved are somewhat different, but are compatible
>>>>>>> enough for it to work.
>>>>>>
>>>>>> The two types are entirely compatible.
>>>>>
>>>>> Are they?
>>>>
>>>> No, they are not. The type names 'Point' and 'vector' name two
>>>> distinct types, and those types are not compatible, because
>>>> the two struct tags are different.
>>>>
>>>> Because the two types are not compatible, even just calling the
>>>> function dist() is undefined behavior.
>>>
>>> I get an incompatible error (from the example you snipped) even when I
>>> remove both struct tags.
>>>
>>> I can't use the same struct tag in the same scope as one will clash
>>> with the other. But if I have the second in an inner scope, then I
>>> again get the error.
>>
>> If you want to make a point or ask a question about C code,
>> SHOW THE CODE. And show all of it. Don't make people guess
>> by showing only some of the code or by giving just a description.
>
> I'm showing the code but you keep snipping it! [...]
No, I don't. Don't be so obtuse. I included the code I was
originally commenting on, in my first followup. My comment about
showing code was about your second posting. Let me repeat the two
important paragraphs (quoted above) taken from that posting:
>>> I get an incompatible error (from the example you snipped) even when I
>>> remove both struct tags.
The phrase "even when I remove both struct tags" describes code, it
doesn't show the code.
>>> I can't use the same struct tag in the same scope as one will clash
>>> with the other. But if I have the second in an inner scope, then I
>>> again get the error.
The phrase "if I have the second in an inner scope" describes code,
it doesn't show the code.
And don't accuse me of something I haven't done.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-09 01:02 +0100 |
| Message-ID | <vt4del$3a9sk$1@dont-email.me> |
| In reply to | #392226 |
On 09/04/2025 00:27, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
>>> If you want to make a point or ask a question about C code,
>>> SHOW THE CODE. And show all of it. Don't make people guess
>>> by showing only some of the code or by giving just a description.
>>
>> I'm showing the code but you keep snipping it! [...]
>
> No, I don't. Don't be so obtuse. I included the code I was
> originally commenting on, in my first followup. My comment about
> showing code was about your second posting. Let me repeat the two
> important paragraphs (quoted above) taken from that posting:
>
>>>> I get an incompatible error (from the example you snipped) even when I
>>>> remove both struct tags.
>
> The phrase "even when I remove both struct tags" describes code, it
> doesn't show the code.
I showed this example a few lines later which has both struct tags omitted:
BC:
> Two typedefs for same struct layout appear to create distinct types;
> this fails:
>
> typedef struct {float x, y;} Point;
> typedef struct {float x, y;} vector;
>
> Point p;
> vector v;
>
> p=v;
But before I get there, I say:
> I can't use the same struct tag in the same scope as one will clash with
> the other.
That would be something like this:
typedef struct tag {float x, y;} Point;
typedef struct tag {float x, y;} vector;
I suggested:
> But if I have the second in an inner scope, then I again get
> the error.
That would be something like this where both 'struct tag' can co-exist:
typedef struct tag {float x, y;} Point;
{
typedef struct tag {float x, y;} vector;
... rest of example that assigns v to p
}
You asserted that the incompabilities are due to the struct tags. I
tried various tests but couldn't find any evidence for that. The structs
are incompatible, even though they have identical layout, member names
and structs, because they distinct, as demonstrated by the first example
in this post. (That needs to be inside any function to see that error.)
That makes sense to me, since different structs even with the same
members could be intended for any number of unrelated purposes:
typedef struct (float a, b, c;} rgbfloat;
typedef struct (float a, b, c;} point;
typedef struct (float a, b, c;} vector;
typedef struct (float a, b, c;} circle;
typedef struct (float a, b, c;} poly;
You wouldn't want instances to these to be assigned to each other
willy-nilly, or passed to functions expectong one of the other functions.
Yes, you'd probably use better names, but AFAIK your choice of member
names shouldn't play a part in determining compatibility.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-04-08 22:55 -0700 |
| Message-ID | <vt5254$nsu$1@dont-email.me> |
| In reply to | #392227 |
On 4/8/2025 5:02 PM, bart wrote:
> On 09/04/2025 00:27, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>
>>>> If you want to make a point or ask a question about C code,
>>>> SHOW THE CODE. And show all of it. Don't make people guess
>>>> by showing only some of the code or by giving just a description.
>>>
>>> I'm showing the code but you keep snipping it! [...]
>>
>> No, I don't. Don't be so obtuse. I included the code I was
>> originally commenting on, in my first followup. My comment about
>> showing code was about your second posting. Let me repeat the two
>> important paragraphs (quoted above) taken from that posting:
>>
>>>>> I get an incompatible error (from the example you snipped) even when I
>>>>> remove both struct tags.
>>
>> The phrase "even when I remove both struct tags" describes code, it
>> doesn't show the code.
>
> I showed this example a few lines later which has both struct tags omitted:
>
> BC:
> > Two typedefs for same struct layout appear to create distinct types;
> > this fails:
> >
> > typedef struct {float x, y;} Point;
> > typedef struct {float x, y;} vector;
> >
> > Point p;
> > vector v;
> >
> > p=v;
>
>
> But before I get there, I say:
>
> > I can't use the same struct tag in the same scope as one will clash with
> > the other.
>
> That would be something like this:
>
> typedef struct tag {float x, y;} Point;
> typedef struct tag {float x, y;} vector;
>
> I suggested:
>
>
> > But if I have the second in an inner scope, then I again get
> > the error.
>
> That would be something like this where both 'struct tag' can co-exist:
>
> typedef struct tag {float x, y;} Point;
> {
> typedef struct tag {float x, y;} vector;
> ... rest of example that assigns v to p
> }
don't forget vec4
[...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-04-08 22:56 -0700 |
| Message-ID | <vt527b$nsu$2@dont-email.me> |
| In reply to | #392227 |
On 4/8/2025 5:02 PM, bart wrote:
> On 09/04/2025 00:27, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>
>>>> If you want to make a point or ask a question about C code,
>>>> SHOW THE CODE. And show all of it. Don't make people guess
>>>> by showing only some of the code or by giving just a description.
>>>
>>> I'm showing the code but you keep snipping it! [...]
>>
>> No, I don't. Don't be so obtuse. I included the code I was
>> originally commenting on, in my first followup. My comment about
>> showing code was about your second posting. Let me repeat the two
>> important paragraphs (quoted above) taken from that posting:
>>
>>>>> I get an incompatible error (from the example you snipped) even when I
>>>>> remove both struct tags.
>>
>> The phrase "even when I remove both struct tags" describes code, it
>> doesn't show the code.
>
> I showed this example a few lines later which has both struct tags omitted:
>
> BC:
> > Two typedefs for same struct layout appear to create distinct types;
> > this fails:
> >
> > typedef struct {float x, y;} Point;
> > typedef struct {float x, y;} vector;
> >
> > Point p;
> > vector v;
> >
> > p=v;
>
>
> But before I get there, I say:
>
> > I can't use the same struct tag in the same scope as one will clash with
> > the other.
>
> That would be something like this:
>
> typedef struct tag {float x, y;} Point;
> typedef struct tag {float x, y;} vector;
>
> I suggested:
>
>
> > But if I have the second in an inner scope, then I again get
> > the error.
>
> That would be something like this where both 'struct tag' can co-exist:
>
> typedef struct tag {float x, y;} Point;
> {
> typedef struct tag {float x, y;} vector;
> ... rest of example that assigns v to p
> }
>
>
>
> You asserted that the incompabilities are due to the struct tags. I
> tried various tests but couldn't find any evidence for that. The structs
> are incompatible, even though they have identical layout, member names
> and structs, because they distinct, as demonstrated by the first example
> in this post. (That needs to be inside any function to see that error.)
>
> That makes sense to me, since different structs even with the same
> members could be intended for any number of unrelated purposes:
>
> typedef struct (float a, b, c;} rgbfloat;
> typedef struct (float a, b, c;} point;
> typedef struct (float a, b, c;} vector;
> typedef struct (float a, b, c;} circle;
> typedef struct (float a, b, c;} poly;
>
> You wouldn't want instances to these to be assigned to each other willy-
> nilly, or passed to functions expectong one of the other functions.
>
> Yes, you'd probably use better names, but AFAIK your choice of member
> names shouldn't play a part in determining compatibility.
>
>
>
If your lang can support something akin to GLM out of the box, that
would be fun. Akin to GLSL shaders...
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-09 15:07 -0700 |
| Message-ID | <86o6x5at05.fsf@linuxsc.com> |
| In reply to | #392227 |
bart <bc@freeuk.com> writes: > On 09/04/2025 00:27, Tim Rentsch wrote: > >> bart <bc@freeuk.com> writes: >> >>>> If you want to make a point or ask a question about C code, >>>> SHOW THE CODE. And show all of it. Don't make people guess >>>> by showing only some of the code or by giving just a description. >>> >>> I'm showing the code but you keep snipping it! [...] >> >> No, I don't. Don't be so obtuse. I included the code I was >> originally commenting on, in my first followup. My comment about >> showing code was about your second posting. Let me repeat the two >> important paragraphs (quoted above) taken from that posting: >> >>>>> I get an incompatible error (from the example you snipped) even when I >>>>> remove both struct tags. >> >> The phrase "even when I remove both struct tags" describes code, it >> doesn't show the code. > > I showed this example a few lines later [in an earlier posting] > which has both struct tags omitted: There is a simple lesson that you need to learn: When someone is responding to a post, they are responding ONLY to the content in the posting they are responing to; not to some earlier posting in the same thread, not to a different posting submitted two weeks ago, not to what you meant to say but didn't, not to thoughts in your head but that you didn't say, but ONLY TO WHAT IS SAID IN THE POSTING BEING RESPONDED TO. If you can learn to follow this simple rule everyone in the newsgroup will be better off, including you.
[toc] | [prev] | [next] | [standalone]
Page 2 of 35 — ← Prev page 1 [2] 3 4 … 35 Next page →
Back to top | Article view | comp.lang.c
csiph-web