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 4 of 35 — ← Prev page 1 2 3 [4] 5 6 … 35 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-11 15:02 +0200 |
| Subject | Re: Endless complaints [was Re: do { quit; } else { }] |
| Message-ID | <vtb3ti$1i742$1@dont-email.me> |
| In reply to | #392372 |
On 11/04/2025 13:32, bart wrote: > On 11/04/2025 09:14, David Brown wrote: >> On 11/04/2025 01:10, bart wrote: >>> On 10/04/2025 23:18, Janis Papanagnou wrote: >> >>>> >>>> *If* you're really interested in the topic, and since all the other >>>> posters obviously gave up to continue explaining their sight to you, >>>> why don't you accept that suggestion and read the standard document >>>> to have clarity about the topic? [FYI; this was a rhetoric question.] >>> >> >> I had certainly given up and moved on. >> >>> I've read the document, or the relevant section. >> >> Finally! Now you too can move on. >> >>> According to that, DB was wrong, and TR was half-right. >>> >> >> Yes, it seems I was inaccurate about the compatibility - the names of >> the struct and fields need to match across translation units, not just >> the types of the fields. That's why it is important that /you/ read >> the standard. > > But no one, absolutely no one, said outright that you were wrong. Only > Keith eventually agreed that one of you (and Tim) was right, but didn't > care who, and the next day admitted that one of you might be wrong, but > still didn't want to commit himself as to who it might be. Some people (certainly Kaz) gave accurate explanations without bothering to say explicitly who was right or wrong. Others posted with fewer details - presumably because they didn't want to go to the effort of establishing exactly what the rules are. After all, none of this is of any concern to most serious C programmers - we all know that "struct" (and "union") create types, "typedef" creates type aliases, if you want to use the same type in several places in one translation unit you re-use the same type, and if you want to do so across translation units you declare the type in a shared header. The precise compatibility rules are typically only relevant if you are dealing with jumbled and poorly structured code. > > On the other hand, I was the only one not to make a bold claim one way > or another (I said types were compatible enough for my test to work), > but Keith had no hesitation in telling me I was 100% wrong! "Type compatibility" is a specific term in C with a specific meaning. It is a binary relationship - two types are compatible, or they are not compatible. You can't have "compatible enough". It is true that some compilers are laxer than others in regards to type compatibility. It is possible that some compilers do not issue the required diagnostics when you mix incompatible types in ways that violate constraint requirements. It is certainly the case that some compilers do not do any kind of analysis for optimisation based type compatibility (known as "type-based alias analysis" or "strict aliasing") - in which case, as long as you use casts or other conversions you can pretend that types with identical representations are compatible in non-portable code for those specific tools. However, it is also certainly true that some compilers /do/ make use of the type compatibility rules to generate more optimal code, or for better static analysis. It is also certainly true that some programmers make use of incompatible types to ensure that some kinds of mistakes in their code result in compile-time errors, thus reducing the risk of errors. And it is always the case that some things may "just work" even though the behaviour is undefined in C or the code breaks constraints or other requirements. That is never a good thing to rely on, unless you understand exactly why the code is problematic, and exactly why it works in the given situation despite the issues, and if you are happy with the non-portable code. > > That is what is very worrying to me, and makes this a toxic environment > (see my last post here where I remark on the contrast with how KT treats > me and how he treats TR.) My impression of KT is that he always tries to argue the case, not the person - thus he has had agreements and disagreements with Tim, and has sometimes answered your questions as well as he could while at other times he expresses his frustration at your determined misunderstanding of C and refusal to learn about it or read relevant parts of the standards. > >> Tim was, as usual in these matters, entirely correct as far as I can >> see. I don't see how he could be considered "half-right" here. Tim >> has a communication style that some people find grating (to put it >> mildly), but there is no question that his knowledge of the C >> standards is outstanding. > > I said half-right because as he put it, it sounded as though > compatibility depended entirely on struct tags. He did not say that, and I as I read his post, I don't interpret it as implying that. There are a number of criteria needed for two structs to be compatible across translation units. Your example there failed the first criterium, and I suppose Tim didn't feel the need to go any further. Perhaps it would have been more helpful if he had, or if he had at least indicated that other things were important, but the post was not wrong or even half-wrong. > > (Which I then proceeded to put to the test with examples where there > were no tags, and those where the tags were the same (but defined in > different scopes). But these were examples where both structs were > visible to the compiler. > > In my original example, the compiler could only see one at a time, as > they were in different translation units.) Testing can only prove the existence of bugs, not their absence.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-11 10:03 -0700 |
| Subject | Re: Endless complaints |
| Message-ID | <86y0w6aawo.fsf@linuxsc.com> |
| In reply to | #392372 |
bart <bc@freeuk.com> writes: > On 11/04/2025 09:14, David Brown wrote: > >> On 11/04/2025 01:10, bart wrote: >> >>> According to [the C standard?], DB was wrong, and TR was half-right. >> >> Yes, it seems I was inaccurate about the compatibility - the names >> of the struct and fields need to match across translation units, >> not just the types of the fields. That's why it is important that >> /you/ read the standard. > > But no one, absolutely no one, said outright that you were wrong. > Only Keith eventually agreed that one of you (and Tim) was right, > but didn't care who, and the next day admitted that one of you > might be wrong, but still didn't want to commit himself as to who > it might be. > > On the other hand, I was the only one not to make a bold claim one > way or another (I said types were compatible enough for my test to > work), but Keith had no hesitation in telling me I was 100% wrong! > > That is what is very worrying to me, and makes this a toxic > environment (see my last post here where I remark on the contrast > with how KT treats me and how he treats TR.) If your comments and style were more like mine, you might find that how Keith Thompson treats you would be different. Incidentally, Keith doesn't always respond to my postings with kid gloves. If something I say offends his sensibilities he isn't shy about calling me out on it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-11 12:26 -0700 |
| Subject | Re: Endless complaints [was Re: do { quit; } else { }] |
| Message-ID | <87a58msdo1.fsf@nosuchdomain.example.com> |
| In reply to | #392372 |
bart <bc@freeuk.com> writes:
> On 11/04/2025 09:14, David Brown wrote:
>> On 11/04/2025 01:10, bart wrote:
>>> On 10/04/2025 23:18, Janis Papanagnou wrote:
>>>> *If* you're really interested in the topic, and since all the other
>>>> posters obviously gave up to continue explaining their sight to you,
>>>> why don't you accept that suggestion and read the standard document
>>>> to have clarity about the topic? [FYI; this was a rhetoric question.]
>>>
>> I had certainly given up and moved on.
>>
>>> I've read the document, or the relevant section.
>> Finally! Now you too can move on.
>>
>>> According to that, DB was wrong, and TR was half-right.
>>
>> Yes, it seems I was inaccurate about the compatibility - the names
>> of the struct and fields need to match across translation units, not
>> just the types of the fields. That's why it is important that /you/
>> read the standard.
>
> But no one, absolutely no one, said outright that you were wrong. Only
> Keith eventually agreed that one of you (and Tim) was right, but
> didn't care who, and the next day admitted that one of you might be
> wrong, but still didn't want to commit himself as to who it might be.
Somebody made a mistake. It wasn't immediately caught. It happens.
This is a very long thread, and IIRC by the time the two posters made
their contradictory posts, it wasn't clear exactly which code they were
referring to. I for one was not willing to dig through the thread to
find it.
Understanding the rules for type compatibility is important.
Determining whether two types posted in a long Usenet thread are
compatible is less so, and likely not worth the effort.
Later, you posted a summary of the relevant code and a paraphrase of
the statements about it. At that point, all the information was in one
place, and I commented.
I eventually made a post saying that the two types (in your summary) are
clearly not compatible.
> On the other hand, I was the only one not to make a bold claim one way
> or another (I said types were compatible enough for my test to work),
> but Keith had no hesitation in telling me I was 100% wrong!
You claimed that people were saying that both contradictory claims were
right. Nobody said that. You have not withdrawn your claim.
I told you that you were wrong because the term "compatible enough"
doesn't make sense. I've explained that at some length. I think what
you meant is that the types (almost certainly) have the same
representation. That's a perfectly valid observation, but you explained
it incorrectly.
Do you now understand the difference between two types being compatible
and two types having the same representation?
> That is what is very worrying to me, and makes this a toxic
> environment (see my last post here where I remark on the contrast with
> how KT treats me and how he treats TR.)
>
>> Tim was, as usual in these matters, entirely correct as far as I can
>> see. I don't see how he could be considered "half-right" here. Tim
>> has a communication style that some people find grating (to put it
>> mildly), but there is no question that his knowledge of the C
>> standards is outstanding.
>
> I said half-right because as he put it, it sounded as though
> compatibility depended entirely on struct tags.
That's your misinterpretation of what he wrote. The difference in tags
is *sufficient but not necessary* to determine that the types are
incompatible. Reread what he wrote with that in mind.
Your misinterpretation is understandable (his explanation was rather
terse), but it was an error on your part. Do you understand that?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-10 15:27 -0700 |
| Subject | Re: Endless complaints [was Re: do { quit; } else { }] |
| Message-ID | <87o6x34pqa.fsf@nosuchdomain.example.com> |
| In reply to | #392323 |
bart <bc@freeuk.com> writes:
> On 10/04/2025 15:33, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
[...]
>>> I said they were compatible enough. David said they were entirely
>>> compatible. Tim said "No they are not". Three different opinions.
>> If you pretend not to understand the C standard, you can argue
>> about it forever.
>> It's been explained to you more than once, but really, just read
>> the flippin standard and stop arguing.
>
> Fucking hell.
>
> Three people have said three different things. They can't all be right.
Correct.
> But according to you, only one of them is wrong: me, even though the
> other two have made exactly opposite claims!
Wrong again, bart. Nobody said that they're both right. You made
that up.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-10 15:23 -0700 |
| Message-ID | <87semf4pw5.fsf@nosuchdomain.example.com> |
| In reply to | #392319 |
bart <bc@freeuk.com> writes:
> On 10/04/2025 12:28, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> Someone, not anyone but the all-knowing Tim, said: "and those types
>>> are not compatible, because the two struct tags are different."
>>>
>>> Do you agree with that? Or is there something more to making two types
>>> be incompatible?
>> I don't recall the exact discussion
>
> It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
> +0200". (About half way down there is some quoted code of mine.)
>
> It concerned two struct types in different translations units, which
> needed to be compatible for the test program to work corectly.
>
> I said they were compatible enough. David said they were entirely
> compatible. Tim said "No they are not". Three different opinions.
Either David or Tim was right; I don't much care which. You were
wrong. There is no such thing as "compatible enough"; two types
either are compatible or are not compatible. I won't speculate on what
you might have meant by "compatible enough".
The most reliable way to determine whether two types are compatible
is to read the standard see whether they satisfy the requirements.
If you have not done so, nothing you say about C type compatibility
is of any interest.
A good way to determine whether a compiler treats two types as
compatible is to define pointers to both of them and try assigning
them, then compiling the code in conforming mode. For example :
type1 *ptr1 = NULL;
type2 *ptr2;
ptr2 = type1;
If type1 and type2 are compatible, then type1* and type2* are
compatible, and there should be no diagnostic for the assignment.
If they're not compatible, then type1* and type2* are not compatible
*and* there is no implicit conversion betwen them, and a conforming
compiler must give a diagnostic. Don't forget to run the compiler
in conforming mode.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-11 00:49 +0100 |
| Message-ID | <vt9let$4au3$1@dont-email.me> |
| In reply to | #392342 |
On 10/04/2025 23:23, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 10/04/2025 12:28, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>> [...] >>>> Someone, not anyone but the all-knowing Tim, said: "and those types >>>> are not compatible, because the two struct tags are different." >>>> >>>> Do you agree with that? Or is there something more to making two types >>>> be incompatible? >>> I don't recall the exact discussion >> >> It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56 >> +0200". (About half way down there is some quoted code of mine.) >> >> It concerned two struct types in different translations units, which >> needed to be compatible for the test program to work corectly. >> >> I said they were compatible enough. David said they were entirely >> compatible. Tim said "No they are not". Three different opinions. > > Either David or Tim was right; I don't much care which. No? BUT YOU CARE VERY MUCH THAT I AM WRONG! > You were wrong. See?! Funny that isn't it; two people both make strong unequivocal statements that are at odds with each other, such that one is likely to be wrong, but you don't care about putting THEM right. Yet I make a minor observation, and everyone comes down on me like a ton of bricks. > There is no such thing as "compatible enough"; two types > either are compatible or are not compatible. I won't speculate on what > you might have meant by "compatible enough". You must have seen the example, and based on my lifetime experience in low level coding, those types ARE compatible enough: one consists of two consecutive 32-bit floats, so does the other. What more is needed? I don't buy the nonsense in the standard that the member names must match; what possible difference can that make? I will admit it might not meet /those/ standards for compatibility, that's why I said it was compatible enough. That is, for all practical purposes. And this was my original point: the C language can't force a sharing of a particular type; compatibility between the versions seen in different translations is on trust. This is the reason for member names having to be the same, to make it less likely that the structs match by chance, and to encourage people to share the same definition via a header. This is why my example chose different tags and different names (and wrapped one set of member types in a typedef): it DELIBERATELY created two structs which were compatible at the machine level (ie. both being the tuple (f32, f32)), but likely intended for different purposes. And that was to back up my point that C could not detect the usage of such a mix of types. Do you understand now WHY I said 'compatible enough'? Are you are utterly incapable of understanding anything outside of the 'the standard'? > Either David or Tim was right; I don't much care which. This is now of most interest to me; somebody might be wrong on some detail of the C standard, but you don't care?! I don't buy it. I don't know what's going on here but it stinks.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-10 17:59 -0700 |
| Message-ID | <87zfgn344c.fsf@nosuchdomain.example.com> |
| In reply to | #392349 |
bart <bc@freeuk.com> writes:
> On 10/04/2025 23:23, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 10/04/2025 12:28, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> Someone, not anyone but the all-knowing Tim, said: "and those types
>>>>> are not compatible, because the two struct tags are different."
>>>>>
>>>>> Do you agree with that? Or is there something more to making two types
>>>>> be incompatible?
>>>> I don't recall the exact discussion
>>>
>>> It stems from this, a reply from DB dated: "Tue, 8 Apr 2025 16:50:56
>>> +0200". (About half way down there is some quoted code of mine.)
>>>
>>> It concerned two struct types in different translations units, which
>>> needed to be compatible for the test program to work corectly.
>>>
>>> I said they were compatible enough. David said they were entirely
>>> compatible. Tim said "No they are not". Three different opinions.
>> Either David or Tim was right; I don't much care which.
>
> No? BUT YOU CARE VERY MUCH THAT I AM WRONG!
You were wrong because you said something that doesn't make sense.
>> You were wrong.
>
> See?! Funny that isn't it; two people both make strong unequivocal
> statements that are at odds with each other, such that one is likely
> to be wrong, but you don't care about putting THEM right.
Correct.
> Yet I make a minor observation, and everyone comes down on me like a
> ton of bricks.
You make a minor nonsensical observation, and continue to double down on
it when we point out that it doesn't make sense.
>> There is no such thing as "compatible enough"; two types
>> either are compatible or are not compatible. I won't speculate on what
>> you might have meant by "compatible enough".
>
> You must have seen the example, and based on my lifetime experience in
> low level coding, those types ARE compatible enough: one consists of
> two consecutive 32-bit floats, so does the other. What more is needed?
An understanding of what "compatible types" means. You claim to have
read that part of the standard, but you still seem to be insisting that
type compatibility has something to do with type representation. It
doesn't. Two compatible types will have the same representation, but
two types with the same representation may or may not be compatible.
char, signed char, and unsigned char are all mutually incompatible, even
though two of them are guaranteed to have the same representation.
If you want to talk about types having the same representation, feel
free to do so, but please don't use the defined technical term
"compatible" to do so.
> I don't buy the nonsense in the standard that the member names must
> match; what possible difference can that make?
Too bad. That's what the standard says. And it make sense if you
understand that compatibility isn't (just) about representation.
If you write:
int main(void) {
struct { double x_in_feet; double y_in_feet; } u = { 1.0, 1.0 };
struct { double x_in_meters; double y_in_meters; } m;
m = u;
}
do you think a compiler should accept the assignment without complaint?
(In practice I'd use distinct tags for both types, but the standard has
to specify what happens if the tags aren't given.)
[...]
>> Either David or Tim was right; I don't much care which.
>
> This is now of most interest to me; somebody might be wrong on some
> detail of the C standard, but you don't care?!
>
> I don't buy it. I don't know what's going on here but it stinks.
OK, I'll explain what's going on. There was a discussion about two
C types. Two people disagreed about whether they're compatible
or not. I care about how C defines type compatibility, but I do
not care about those specific two types. Why should I?
People make mistakes. It happens. It certainly happens to me.
If I did care, I could dig through the thread and find the exact
types they were talking about, but I couldn't be 100% certain that
I was looking at the same types, in the same context, that they
were discussing.
I usually don't spend this much time talking about things I don't
care about (again, those specific two types, not the meaning of
compatibility), but in this case you insist that I should care and
have made up something about someone saying they were both right.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-11 14:26 +0300 |
| Message-ID | <20250411142636.00006c00@yahoo.com> |
| In reply to | #392353 |
On Thu, 10 Apr 2025 17:59:15 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > An understanding of what "compatible types" means. Bart didn't say that types are compatible or non-compatible. He said that they are 'compatible enough'. That is not terminology of C Standard, but terminology of his own. And he seems to understand it. In my own translation, 'compatible enough' means that when these structs are accessed then any sane or even semi-sane compiler will generate code that will have the same effect as in case of access through structures with literally identical declarations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-11 16:11 +0200 |
| Message-ID | <vtb7ul$1plb2$1@dont-email.me> |
| In reply to | #392371 |
On 11/04/2025 13:26, Michael S wrote: > On Thu, 10 Apr 2025 17:59:15 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> >> An understanding of what "compatible types" means. > > Bart didn't say that types are compatible or non-compatible. > He said that they are 'compatible enough'. That is not terminology of C > Standard, but terminology of his own. And he seems to understand it. > > In my own translation, 'compatible enough' means that when these structs > are accessed then any sane or even semi-sane compiler will generate code > that will have the same effect as in case of access through structures > with literally identical declarations. > With that kind of thing, you always have to consider future-proofing for more advanced compilers. With separately compile units that are then linked with a traditional linker, the compiler has no information about the details of struct definitions in different units. Thus you can be sure that it everything will work even if the two different structs are defined with different tags and field names - indeed, as long as you stick to a common prefix with fields with the same representation and alignments, I have great difficulty imagining how it might possible fail to work just as if the struct types had actually been compatible. However, compilers don't have to work that way. Once you introduce link-time optimisation or other whole-program analysis, or compile the two units in one compile command, or allow more advanced object file formats that pass type details on to the linker, such assumptions don't hold. A compiler with LTO can quite reasonably optimise code on the assumption that a pointer to one type could not alias a pointer to an incompatible type, even if those types were otherwise extremely similar.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-04-11 17:22 +0000 |
| Message-ID | <20250411102119.431@kylheku.com> |
| In reply to | #392371 |
On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
> On Thu, 10 Apr 2025 17:59:15 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>>
>> An understanding of what "compatible types" means.
>
> Bart didn't say that types are compatible or non-compatible.
> He said that they are 'compatible enough'. That is not terminology of C
> Standard, but terminology of his own. And he seems to understand it.
>
> In my own translation, 'compatible enough' means that when these structs
> are accessed then any sane or even semi-sane compiler will generate code
> that will have the same effect as in case of access through structures
> with literally identical declarations.
so struct { long x; } and struct { int x; } are compatible enough,
in situations that are portable enough.
A sphere and a cow are similar enough, ...
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-11 20:46 +0100 |
| Message-ID | <vtbriv$2e8u2$1@dont-email.me> |
| In reply to | #392400 |
On 11/04/2025 18:22, Kaz Kylheku wrote:
> On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
>> On Thu, 10 Apr 2025 17:59:15 -0700
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>>
>>> An understanding of what "compatible types" means.
>>
>> Bart didn't say that types are compatible or non-compatible.
>> He said that they are 'compatible enough'. That is not terminology of C
>> Standard, but terminology of his own. And he seems to understand it.
>>
>> In my own translation, 'compatible enough' means that when these structs
>> are accessed then any sane or even semi-sane compiler will generate code
>> that will have the same effect as in case of access through structures
>> with literally identical declarations.
>
> so struct { long x; } and struct { int x; } are compatible enough,
> in situations that are portable enough.
What about struct {long x;} and struct {int64_t x;}?
Whether they are compatible seems to be depend on platform.
Or rather, whether or not int64_t happens to defined on top of 'long' or
'long long'.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-11 14:10 -0700 |
| Message-ID | <87o6x2qu9g.fsf@nosuchdomain.example.com> |
| In reply to | #392411 |
bart <bc@freeuk.com> writes:
[...]
> What about struct {long x;} and struct {int64_t x;}?
>
> Whether they are compatible seems to be depend on platform.
>
> Or rather, whether or not int64_t happens to defined on top of 'long'
> or 'long long'.
Correct. If long is 32 bits, they're not compatible. If long
is 64 bits and int64_t is a typedef for long, they're compatible.
If long is 64 bits and int64_t is a typedef for long long (or for
a 64-bit extended integer type) they're not compatible.
Again, type compatibility isn't just about representation.
And again, I am describing how C is defined, not advocating or
defending it.
If you're working with code where the compatibility of those two
types matters, it's probably best to modify the code to use a
single type, defined in a shared header if it's used in more than
one translation unit. If that's not practical and you're sure the
types have the same representation, you can probably work around it
with some kind of type-punning (pointer casts, unions, memcpy()),
though some such workarounds might involve undefined behavior.
Or you can just copy the x member from an object of one type to an
object of the other type (there's an implicit conversion between
long and int64_t whether they're compatible or not).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-13 20:45 +0300 |
| Message-ID | <20250413204521.0000238e@yahoo.com> |
| In reply to | #392400 |
On Fri, 11 Apr 2025 17:22:37 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
> > On Thu, 10 Apr 2025 17:59:15 -0700
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >
> >>
> >> An understanding of what "compatible types" means.
> >
> > Bart didn't say that types are compatible or non-compatible.
> > He said that they are 'compatible enough'. That is not terminology
> > of C Standard, but terminology of his own. And he seems to
> > understand it.
> >
> > In my own translation, 'compatible enough' means that when these
> > structs are accessed then any sane or even semi-sane compiler will
> > generate code that will have the same effect as in case of access
> > through structures with literally identical declarations.
>
> so struct { long x; } and struct { int x; } are compatible enough,
> in situations that are portable enough.
>
I wish they would be, but according to C Standard they are not, ene
when both represent 32-bt signed integer. That's because of misfeature
called 'strong aliasing rules'.
IMO, C would become better without this misfeature.
> A sphere and a cow are similar enough, ...
>
Bad attempt of analogy.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-05-11 19:05 -0700 |
| Message-ID | <861psuziq2.fsf@linuxsc.com> |
| In reply to | #392465 |
Michael S <already5chosen@yahoo.com> writes:
> On Fri, 11 Apr 2025 17:22:37 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>
>> On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
>>
>>> On Thu, 10 Apr 2025 17:59:15 -0700
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> An understanding of what "compatible types" means.
>>>
>>> Bart didn't say that types are compatible or non-compatible.
>>> He said that they are 'compatible enough'. That is not terminology
>>> of C Standard, but terminology of his own. And he seems to
>>> understand it.
>>>
>>> In my own translation, 'compatible enough' means that when these
>>> structs are accessed then any sane or even semi-sane compiler will
>>> generate code that will have the same effect as in case of access
>>> through structures with literally identical declarations.
>>
>> so struct { long x; } and struct { int x; } are compatible enough,
>> in situations that are portable enough.
>
> I wish they would be, but according to C Standard they are not,
> ene when both represent 32-bt signed integer. That's because of
> misfeature called 'strong aliasing rules'.
> IMO, C would become better without this misfeature.
I think this reaction is rather shortsighted. Making this change
would incur several downsides, and offers no significant upside
that I can see.
First it would greatly complicate the language semantics.
Whether a program is meaningful, and if so what the meaning is,
would be much harder to state than it is now.
Second it would imply that whether a program is well-defined is a
lot more dependent on implementation-specific choices than it is
now.
Third, as a consequence of that, it would be harder to write
program verification tools, because they would need to take these
more extensive implementation dependencies into consideration.
Fourth, there would be consequences for program optimization, and
it is hard to dismiss those. Some people may not care about the
optimizations losses, but certainly many people want the benefits
of those optimizations.
Fifth, related to the previous point, as a practical matter it would
make getting the optimization benefits back again be nearly
impossible. As things are now, it's easy to have a compiler option
to disable the consequences of strong typing rules, and the result
can still be a conforming implementation. But if the C standard
would prescribe the semantics of cross-type access, then any option
to ignore the implications of that prescription would necessarily
make using said option result in a non-conforming implementation.
To say the last point another way, with things as they are now
developers can choose whether they want to observe the cross-type
access restrictions, or ignore them, and still get a C compiler.
If the effective type rules were discarded, there is no way to
choose the more-optimizing path without getting something that
is not a C compiler.
Given that you can always get what you want either by choosing
an appropriate compiler option (if available) or by using one of
the well-known legal workarounds, I think it's hard to make a
case that getting rid of the effective type restrictions is a
good idea.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-12 16:37 +0200 |
| Message-ID | <vvt13g$14otk$1@dont-email.me> |
| In reply to | #393335 |
On 12/05/2025 04:05, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>> On Fri, 11 Apr 2025 17:22:37 -0000 (UTC)
>> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>
>>> On 2025-04-11, Michael S <already5chosen@yahoo.com> wrote:
>>>
>>>> On Thu, 10 Apr 2025 17:59:15 -0700
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>
>>>>> An understanding of what "compatible types" means.
>>>>
>>>> Bart didn't say that types are compatible or non-compatible.
>>>> He said that they are 'compatible enough'. That is not terminology
>>>> of C Standard, but terminology of his own. And he seems to
>>>> understand it.
>>>>
>>>> In my own translation, 'compatible enough' means that when these
>>>> structs are accessed then any sane or even semi-sane compiler will
>>>> generate code that will have the same effect as in case of access
>>>> through structures with literally identical declarations.
>>>
>>> so struct { long x; } and struct { int x; } are compatible enough,
>>> in situations that are portable enough.
>>
>> I wish they would be, but according to C Standard they are not,
>> ene when both represent 32-bt signed integer. That's because of
>> misfeature called 'strong aliasing rules'.
>> IMO, C would become better without this misfeature.
I am in two minds about this. I think there are good reasons for
wanting compatibility between different integer types of the same size.
But I prefer stronger separation between user-defined types - structs in C.
In particular, I think it would be a big step backwards if independent
struct types with the same fields were compatible - that would mean
variables of those types could be assigned to each other, or used as
parameters to functions, or pointers to those types could be intermixed.
C does not make it convenient to have strong types, in comparison to
many other languages - reducing the protections they give would make it
far easier for coding errors to slip through.
For plain integer types, however, I think the argument for making
equal-sized types compatible is a lot stronger. Some compilers
specifically say that they allow aliasing between such types (MSVC,
according to what I have read, have said they never intend to support
"strict aliasing" optimisations). Many software projects (such as
Linux) use "-fno-strict-aliasing". And countless C programmers
mistakenly believe that identically sized integer types are compatible
(though I am not advocating for a weaker language simply because some
users misunderstand the rules).
>
> I think this reaction is rather shortsighted. Making this change
> would incur several downsides, and offers no significant upside
> that I can see.
>
> First it would greatly complicate the language semantics.
> Whether a program is meaningful, and if so what the meaning is,
> would be much harder to state than it is now.
The semantics I would recommend are extremely simple - arithmetic types
which have identical sizes, values, and representations, should be
compatible.
As an alternative wording, I think it would be fine to leave the type
compatibility rules as they are and make this change to the "effective
type" rules in 6.5p7.
>
> Second it would imply that whether a program is well-defined is a
> lot more dependent on implementation-specific choices than it is
> now.
It would make some programs that are currently incorrect, correct. And
yes, it would mean that if code mixes up types and pointers, code may
not then be portable - for example, code that passed the address of an
"int" to a function requesting a "pointer to long" would compile on
64-bit Windows and not on 64-bit Linux. But a lot of code is already
non-portable, and I do not think this suggestion would make the
situation significantly different.
In particular, in situations where this change would allow code that
previously had a constraint error, the code would now work as expected.
The alternative solution currently used in many cases where the
programmer knows that the type sizes are the same even though they are
incompatible, is to use a cast - that will "keep the compiler happy" but
will often not actually be well-defined behaviour. Making identically
sized and represented integer types compatible would mean the compiler
is already happy, and the code is well-defined.
One place where it would help, however, is for code that uses fixed-size
integer types. Whether "int32_t" is compatible with "int", "long", or
other types, is already implementation-specific and the situation is
often surprising to developers. It seems "obvious" that "int32_t" would
be compatible with "int" on a 32-bit target - but on some targets, that
is not the case.
>
> Third, as a consequence of that, it would be harder to write
> program verification tools, because they would need to take these
> more extensive implementation dependencies into consideration.
I cannot see a basis for that. Compilers and other code analysis and
verification tools can add whatever extra checks and controls they want.
And I suspect it will be easier to check that code is correct
according to the suggested updated rules than to spot some kinds of
subtle mistakes using the existing rules.
>
> Fourth, there would be consequences for program optimization, and
> it is hard to dismiss those. Some people may not care about the
> optimizations losses, but certainly many people want the benefits
> of those optimizations.
It is certainly the case that there are some optimisation opportunities
due to the "strict aliasing" rules - the compiler knows that an "int *"
pointer and a "long *" pointer do not point to the same data even if
"int" and "long" are the same size on that platform. Analysis (I have
read reports on this, but do not have references for them) of code
generation by compilers with "strict aliasing" optimisation has,
however, shown that it is rare that such optimisations make much
difference - and often you would much better results from using
"restrict". Also, with my suggested changes, compilers would retain the
knowledge of no aliasing between integer types and floating point types,
or between struct types.
>
> Fifth, related to the previous point, as a practical matter it would
> make getting the optimization benefits back again be nearly
> impossible. As things are now, it's easy to have a compiler option
> to disable the consequences of strong typing rules, and the result
> can still be a conforming implementation. But if the C standard
> would prescribe the semantics of cross-type access, then any option
> to ignore the implications of that prescription would necessarily
> make using said option result in a non-conforming implementation.
>
Almost anyone interested in serious optimisation is already going to be
using non-portable and compiler or target specific features. That
objection is a complete non-issue.
> To say the last point another way, with things as they are now
> developers can choose whether they want to observe the cross-type
> access restrictions, or ignore them, and still get a C compiler.
> If the effective type rules were discarded, there is no way to
> choose the more-optimizing path without getting something that
> is not a C compiler.
>
> Given that you can always get what you want either by choosing
> an appropriate compiler option (if available) or by using one of
> the well-known legal workarounds, I think it's hard to make a
> case that getting rid of the effective type restrictions is a
> good idea.
I have now made a case for a limited change to the aliasing rules
(whether the change is made by type compatibility rules, constraints on
assignment, or "effective type" rules). I did not think it was
particularly hard to do so.
Of course opinions will differ as to how good such arguments are, and
any real changes would be based on far more serious thoughts and
discussions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-12 13:25 -0700 |
| Message-ID | <87ecwt37b9.fsf@nosuchdomain.example.com> |
| In reply to | #393351 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> For plain integer types, however, I think the argument for making
> equal-sized types compatible is a lot stronger. Some compilers
> specifically say that they allow aliasing between such types (MSVC,
> according to what I have read, have said they never intend to support
> "strict aliasing" optimisations). Many software projects (such as
> Linux) use "-fno-strict-aliasing". And countless C programmers
> mistakenly believe that identically sized integer types are compatible
> (though I am not advocating for a weaker language simply because some
> users misunderstand the rules).
I think that a lot of C programmers misunderstand what "compatible
types" means. Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
In fact type compatibility is a much stricter concept than that.
Two types are compatible if they are *the same type*, and in a few
other circumstances. For example, char, signed char, and unsigned
char are all incompatible with each other, even though two of them
are guaranteed to have the same representation.
A good way to think about it is that pointers to two types can be
assigned without a cast if and only if the two types are compatible.
For example, int and long objects can be assigned to each other
without a cast, but int* and long* objects cannot.
And changing the language to make int and long conditionally
compatible would (a) make it too easy to write code that's valid
in one implementation but violates a constraint in another, and (b)
would break existing code. For example, a generic selection cannot
have two associations with compatible types. _Generic with "int:"
and "long:" would become invalid for implementations that make int
and long compatible.
(I wouldn't mind seeing a new form of generic association that
selects the *first* matching type, but that's another can of worms.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-05-13 11:40 +0200 |
| Message-ID | <vvv43b$1o3o0$1@dont-email.me> |
| In reply to | #393359 |
On 12/05/2025 22:25, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> For plain integer types, however, I think the argument for making >> equal-sized types compatible is a lot stronger. Some compilers >> specifically say that they allow aliasing between such types (MSVC, >> according to what I have read, have said they never intend to support >> "strict aliasing" optimisations). Many software projects (such as >> Linux) use "-fno-strict-aliasing". And countless C programmers >> mistakenly believe that identically sized integer types are compatible >> (though I am not advocating for a weaker language simply because some >> users misunderstand the rules). > > I think that a lot of C programmers misunderstand what "compatible > types" means. Many seem to think that two types are compatible if > they have the same representation and can be assigned without a cast. > Yes. Basically, most C programmers are not particularly aware of the technical definitions of some of the terms in C standards where they differ from common usage. The word "compatible" in English means that the things in question can work together or fit together. Thus there are a number of ways to view types as "compatible" in C in normal English, but only one definition of "compatible type" as a specific term in the C standard. (This sort of thing is, I think, inevitable in a language standard unless you want to invent new terms without a normal language meaning - such as "lvalue".) > In fact type compatibility is a much stricter concept than that. > Two types are compatible if they are *the same type*, and in a few > other circumstances. For example, char, signed char, and unsigned > char are all incompatible with each other, even though two of them > are guaranteed to have the same representation. > > A good way to think about it is that pointers to two types can be > assigned without a cast if and only if the two types are compatible. > For example, int and long objects can be assigned to each other > without a cast, but int* and long* objects cannot. > Yes. That is also a good way for people to check if types are compatible, if they want to use "try it on a compiler and see" as an aid. > And changing the language to make int and long conditionally > compatible would (a) make it too easy to write code that's valid > in one implementation but violates a constraint in another, and (b) > would break existing code. Speaking as someone who uses the fixed-size types often, and sees it in other code, there is already a lot of such code that is valid in one implementation or target and not on others, primarily because "int32_t" may be typedef'ed to "int" or "long", and "int64_t" may be "long" or "long long". But I can see that making "long" compatible to either "int" or "long long", according to implementation, might cause more issues. I think a better change to consider is not changing the rules of type compatibility, but slightly loosening the rules for what types of lvalue expressions can be used to access objects in 6.5p7. (It is possible this could be done by changing the "effective type" rules in 6.5p6, but that might be more complicated.) Basically, we retain the restriction that an int* and a long* (for 32-bit int and long) cannot be assigned to each other without a cast, but that an int* lvalue /can/ be used to access a long object, and vice versa. The same would apply to any pairs of scalar types that have identical values and representations. I believe that change would not break any existing code, but would certainly fix some existing broken code. And it would allow compilers to continue to use most "strict aliasing" optimisations. > For example, a generic selection cannot > have two associations with compatible types. _Generic with "int:" > and "long:" would become invalid for implementations that make int > and long compatible. > While that is true, I suspect that _Generic is used so little in practice that few if any would notice it! > (I wouldn't mind seeing a new form of generic association that > selects the *first* matching type, but that's another can of worms.) > If I were looking to improve _Generic, I'd want a way to add new types to an existing _Generic macro (for new overloads). This could easily by done if the preprocessor had a #redefine directive that let you give a new definition of a macro name while using the old definition when expanding the new macro. That would be a whole barrel of worms :-)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-05-13 20:17 -0400 |
| Message-ID | <1000ne2$2323t$1@dont-email.me> |
| In reply to | #393370 |
On 5/13/25 05:40, David Brown wrote: > On 12/05/2025 22:25, Keith Thompson wrote: ... >> I think that a lot of C programmers misunderstand what "compatible >> types" means. Many seem to think that two types are compatible if >> they have the same representation and can be assigned without a cast. >> > > Yes. Basically, most C programmers are not particularly aware of the > technical definitions of some of the terms in C standards where they > differ from common usage. The word "compatible" in English means that > the things in question can work together or fit together. That's pretty much what it means in C. Two C types are compatible in C if the C standard *guarantees* that they can work together - that you can use the types interchangeably. The tricky part is the definition of which pairs of types the C standard makes those guarantees for. The key point is that the undefined behavior of code which treats incompatible types as if they were compatible could also be that they work together, too, depending upon the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-13 17:51 -0700 |
| Message-ID | <87wmakaubu.fsf@nosuchdomain.example.com> |
| In reply to | #393388 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 5/13/25 05:40, David Brown wrote:
>> On 12/05/2025 22:25, Keith Thompson wrote:
> ...
>>> I think that a lot of C programmers misunderstand what "compatible
>>> types" means. Many seem to think that two types are compatible if
>>> they have the same representation and can be assigned without a cast.
>>
>> Yes. Basically, most C programmers are not particularly aware of the
>> technical definitions of some of the terms in C standards where they
>> differ from common usage. The word "compatible" in English means that
>> the things in question can work together or fit together.
>
> That's pretty much what it means in C. Two C types are compatible in C
> if the C standard *guarantees* that they can work together - that you
> can use the types interchangeably. The tricky part is the definition of
> which pairs of types the C standard makes those guarantees for.
> The key point is that the undefined behavior of code which treats
> incompatible types as if they were compatible could also be that they
> work together, too, depending upon the implementation.
I suggest that the phrase "work together" is too vague. It's
perfectly reasonable to say that two types that can be assigned to
each other without casts can "work together", and I might even call
them "compatible" if the standard didn't already define the term.
To a first approximation, two types are compatible if they're the
same type. The standard's section on compatible types points to
additional rules for some cases. IMHO the English word "compatible"
suggests a much looser relationship, but we're stuck with the
standard's terminology (and I'm not sure what would be better).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-05-13 22:23 -0400 |
| Message-ID | <1000urk$25bh3$1@dont-email.me> |
| In reply to | #393389 |
On 5/13/25 20:51, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 5/13/25 05:40, David Brown wrote: ... >>> Yes. Basically, most C programmers are not particularly aware of the >>> technical definitions of some of the terms in C standards where they >>> differ from common usage. The word "compatible" in English means that >>> the things in question can work together or fit together. >> >> That's pretty much what it means in C. Two C types are compatible in C >> if the C standard *guarantees* that they can work together - that you >> can use the types interchangeably. The tricky part is the definition of >> which pairs of types the C standard makes those guarantees for. >> The key point is that the undefined behavior of code which treats >> incompatible types as if they were compatible could also be that they >> work together, too, depending upon the implementation. > > I suggest that the phrase "work together" is too vague. I was trying to match the wording of the text I was responding to. What I meant can be made far more precise: the C standard guarantees that two compatible types will work together, in the sense that every case where the C standard mandates that two types must be compatible in order for something to work, it will work for them.
[toc] | [prev] | [next] | [standalone]
Page 4 of 35 — ← Prev page 1 2 3 [4] 5 6 … 35 Next page →
Back to top | Article view | comp.lang.c
csiph-web