Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #156943 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2020-12-05 08:25 -0800 |
| Last post | 2021-01-06 23:07 -0800 |
| Articles | 20 on this page of 399 — 24 participants |
Back to article view | Back to comp.lang.c
Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 08:25 -0800
Re: Programming exercise/challenge Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-12-05 17:33 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 11:58 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-30 09:40 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-30 18:20 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 01:04 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-02 22:05 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 14:48 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 19:17 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 19:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-30 21:44 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-31 02:54 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-03 09:49 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-04 00:15 +0300
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-03 21:57 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-03 23:00 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 00:00 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 07:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 22:30 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 18:42 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 21:23 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 23:41 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 16:39 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 16:58 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 17:08 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 17:11 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 17:24 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 17:52 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:30 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 19:56 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 14:51 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-05 17:49 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:34 +0000
Re: Programming exercise/challenge Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-05 19:40 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:47 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 23:19 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 23:56 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 02:26 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 16:04 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:39 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:34 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:28 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:34 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 20:05 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:03 -0800
Re: Programming exercise/challenge dfs <nospam@dfs.com> - 2020-12-05 13:58 -0500
Re: Programming exercise/challenge Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-12-05 21:37 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:13 -0800
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 18:00 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 12:31 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:26 -0800
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-05 23:32 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 17:18 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 17:51 +0100
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 22:27 +0000
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-07 09:37 +0100
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 07:36 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:49 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 17:51 +0000
Re: Programming exercise/challenge dfs <nospam@dfs.com> - 2020-12-06 13:03 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 23:53 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 19:53 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 23:38 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 00:17 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 02:09 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-07 01:03 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 12:05 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 12:25 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 13:33 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 14:18 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 14:31 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 12:58 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:03 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 07:12 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 21:55 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:59 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:55 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 07:45 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:26 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-24 12:24 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-24 17:19 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:16 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:17 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:27 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:18 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 05:15 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 13:42 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:53 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 01:49 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:35 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 21:17 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:44 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:46 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-13 12:21 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:35 -0800
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2020-12-31 00:46 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2020-12-31 00:52 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 00:34 -0800
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 08:23 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 10:09 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 11:38 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 08:24 -0800
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-07 07:03 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 02:16 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 02:39 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:18 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:17 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 00:27 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:20 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 13:44 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 14:01 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 22:16 +0000
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 15:10 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 01:07 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 00:34 +0000
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-08 18:17 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 00:56 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 02:30 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 15:14 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 15:44 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:56 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-12 13:29 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:46 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-12 13:59 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 14:17 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-13 12:58 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-13 20:57 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-14 20:44 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-23 11:15 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-23 23:45 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-23 21:36 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 09:11 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 15:30 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 23:18 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 23:56 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-28 12:01 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:31 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 14:47 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 01:59 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:26 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 19:02 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 01:15 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 20:38 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 02:19 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 11:44 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 07:32 -0500
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 14:40 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-08 06:52 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 17:31 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 20:16 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 20:48 +0000
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-08 15:34 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 02:54 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:33 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:43 +0300
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-09 01:52 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:28 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:40 +0000
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-12 13:48 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-09 01:46 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:29 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 10:45 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 17:16 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-08 06:39 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-07 17:48 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 21:03 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:02 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:02 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 16:49 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 13:33 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 19:57 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-10 01:45 +0000
Re: Programming exercise/challenge Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-12-10 02:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:24 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 21:57 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-10 03:32 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-10 08:19 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 19:34 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 02:22 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:04 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 11:59 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:11 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 00:02 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 15:12 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 10:36 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:11 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-10 23:34 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-10 20:11 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 21:06 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 03:03 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 21:21 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:50 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:16 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:32 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-09 12:21 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-02 19:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 01:54 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 22:36 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 23:07 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-22 20:27 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 13:05 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 07:45 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 16:49 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 11:22 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 16:53 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 09:55 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 21:35 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-24 18:17 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:57 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 11:28 -0800
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-08 11:30 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 20:31 +0000
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-08 22:17 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-08 22:15 +0100
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-08 13:28 -0800
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-09 12:05 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:04 +0300
Re: Programming exercise/challenge Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-12-08 21:38 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:25 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 01:00 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 03:09 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:35 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 22:57 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 23:43 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:47 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 23:27 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-13 14:44 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:47 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:36 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 14:51 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 11:35 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-10 02:33 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 00:05 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-10 14:59 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 20:32 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:45 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:24 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:17 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:23 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-09 19:31 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 12:01 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 12:25 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-23 01:00 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 14:34 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-26 23:03 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 06:29 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-28 11:52 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 00:38 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-28 15:29 +0300
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-28 17:12 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 23:54 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:26 -0600
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:37 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:59 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-30 09:17 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-31 16:54 +0300
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-31 09:16 -0600
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-31 15:56 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 02:41 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-31 13:01 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-31 14:15 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 08:03 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 07:42 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-02 21:59 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 14:52 -0500
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-02 12:30 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-02 18:17 -0500
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 19:22 -0500
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-02 17:48 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-02 22:35 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 18:02 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-03 00:42 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:12 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-04 07:04 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:22 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 04:24 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 06:22 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 08:55 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-05 20:22 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-05 20:27 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 14:20 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 17:23 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 10:18 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 18:57 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 12:58 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-05 17:31 -0500
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-05 17:50 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 19:33 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-05 23:02 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 21:00 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-06 07:42 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 08:55 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-06 13:29 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 14:09 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 22:11 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-07 03:10 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-07 06:40 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-09 06:27 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-10 04:32 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-11 06:58 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-11 14:40 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-15 09:46 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-17 04:13 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-17 14:18 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-17 18:02 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-17 15:12 -0500
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-17 21:39 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 10:57 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-21 11:37 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 00:30 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-22 09:09 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 13:47 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-22 19:00 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 19:42 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-22 21:16 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 16:41 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 17:46 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 09:51 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 18:38 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 04:52 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-23 15:45 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 09:04 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-23 23:10 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 15:39 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 15:59 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 11:40 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 09:47 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 18:32 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 17:26 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-24 01:55 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 08:40 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 20:51 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-24 02:28 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-24 03:49 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-24 15:38 +0300
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-24 14:04 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 07:26 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-25 16:58 +0100
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2021-01-25 09:14 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:32 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-27 16:24 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-28 00:11 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 12:25 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 06:18 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 16:54 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 09:15 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 20:07 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 15:58 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-29 00:07 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 16:17 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-29 00:03 +0300
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-28 03:37 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-28 22:50 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-30 23:14 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-30 20:49 +0000
Re: Programming exercise/challenge M Joshua Ryan <luser.droog@gmail.com> - 2021-01-28 00:05 -0600
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-27 11:51 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-25 17:22 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 12:21 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-25 14:27 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 19:41 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-26 04:46 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-26 06:30 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-26 15:46 +0100
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-27 03:43 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 13:43 +0100
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 17:51 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-27 11:02 -0500
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 17:03 +0100
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-27 07:21 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 17:09 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-27 17:04 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-28 10:41 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-28 18:25 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-28 10:44 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-28 21:33 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-29 10:39 +0100
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 23:52 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-26 11:37 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 08:04 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 19:16 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 23:38 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 13:43 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-28 03:16 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 06:42 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-28 13:01 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 13:35 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-06 19:27 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-06 21:25 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 00:37 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 04:34 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 11:54 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 15:28 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-05 13:27 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 15:43 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 20:10 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-06 23:07 -0800
Page 15 of 20 — ← Prev page 1 … 13 14 [15] 16 17 … 20 Next page →
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2021-01-05 20:22 +0300 |
| Message-ID | <20210105202253.653c528681be98a5c0d1d2ed@gmail.com> |
| In reply to | #158178 |
Dave Dunfield to Tim Rentsch: > > "\ "/*" > > > > is a valid string literal, the same as " > > Just shows how you can always learn something. Still don't > quite understand it though. This is because an escaped newline, or a backward slash at the end of a line, takes priority over normal tokenisation. It is natural for a compiler to process these line continuations before any other processing, so that the tokeniser "sees" joined lines, with the contiuations removed. This simple approach, however, violates Tim's requirement that *everthing* outside comments shall be left unchagned (including line continueations). -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2021-01-05 20:27 +0300 |
| Message-ID | <20210105202729.61f150f11a78b6c34cc31e91@gmail.com> |
| In reply to | #158179 |
I misquoted Tim Rentch: > "\ "/*" > > is a valid string literal, the same as " having forgotten to escape the new line espaces for my *roff processing :-) Correction: > "\\ > "/*" > > is a valid string literal, the same as "\"/*". -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-05 14:20 -0800 |
| Message-ID | <86r1mzqb55.fsf@linuxsc.com> |
| In reply to | #158179 |
Anton Shepelev <anton.txt@gmail.com> writes: > Dave Dunfield to Tim Rentsch: > >>> "\ "/*" >>> >>> is a valid string literal, the same as " >> >> Just shows how you can always learn something. Still don't >> quite understand it though. > > This is because an escaped newline, or a backward slash at > the end of a line, takes priority over normal tokenisation. > It is natural for a compiler to process these line > continuations before any other processing, so that the > tokeniser "sees" joined lines, with the contiuations > removed. > > This simple approach, however, violates Tim's requirement > that *everthing* outside comments shall be left unchagned > (including line continueations). Besides being what I asked for, I think it's a big part of what makes the problem interesting.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-05 17:23 +0000 |
| Message-ID | <20210105090706.531@kylheku.com> |
| In reply to | #158178 |
On 2021-01-05, Dave Dunfield <dave.dunfield@gmail.com> wrote:
>> I think you have missed the essential element here. The presence
>> of #define is incidental, and there is no unpaired double quote
>> (the double quote in the middle is escaped by the first \). The
>> input (after removing leading indentation)
>>
>> "\\
>> "/*"
>>
>> is a valid string literal, the same as "\"/*".
Not with the trailing spaces you added to Tim's quoted text, though.
> Just shows how you can always learn something. Still don't quite
> understand it though.
What's there to misunderstand? A backslash-newline sequence is
recognized at the second-lowest translation phase in C, below
tokenization and recognition of comments. Every such backslash-newline
sequence is effectively deleted, and causes the "logical line" to continue
with the content of the following "physical line".
So just delete the \<NL> from this:
"\\
"/*"
to get this:
"\"/*"
That's a valid string literal containing a double-quote via backslash
escaping.
> I've always thought of escapes (and hence my compiler does too) as
> in the order the characters occur, and that the escape applies to the
> NEXT character in sequence:
It does; it applies to the next character in the logical line that
exists in ISO C translation phase 3.
The backslash-newline is a form of escape, but in a separate pass.
Recognition of backslash-newline line continuations takes place without
regard for syntax whatsoever.
This is a valid definition of main:
i\
n\
t
m\
a\
i\
n
(
v\
o\
i\
d\
{
}
Here, you also have to understand my own convention ("translation phase
zero, if you will"): my two-space indentation is supposed to be deleted.
The next character after i\<NL> is not a space, but n.
> --- TCC T.C gives ---
> Turbo C Version 2.0 Copyright (c) 1987, 1988 Borland International
> t.c:
1988 was before the first C standard was ratified by ANSI.
Rick Astley's "Never Gonna Give You Up" was #4 in Billboard magazine's
year-end hot 100 singles.
> Error t.c 4: Declaration syntax error
> Error t.c 8: Unterminated string or character constant
> *** 2 errors in Compile ***
>
> Available memory 444682
That figure is not literally correct, either (I presume).
> LCC does compile the above (must've left in some crap
> when I tried it before), and prints: "/*
>
> If I remove the newline:
>
> -----------------------------
> #include <stdio.h>
>
> #define foo "\\"/*"
>
> main()
> {
> fputs(foo, stdout);
> }
> ---- I get ------------------
> cpp: t.c:3 EOF inside comment
Well, you can't just remove the jnewline and not the backslash, right?
This is obviously a "\\" literal, denoting a single backslash,
followed by a /* start of comment sequence which is not terminated.
This speaks nothing to the implementation's treatment of line
continuations.
Processing \\ in a string literal is extremely basic; failing to
do so properly would be readily identified as a showstopper bug.
An implementation of 1978 K&R C has to get this much right.
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 10:18 -0800 |
| Message-ID | <6e9df1c1-f2ab-4cf0-b72f-7c6f2a78dc65n@googlegroups.com> |
| In reply to | #158180 |
On Tuesday, January 5, 2021 at 12:23:57 PM UTC-5, Kaz Kylheku wrote: > Not with the trailing spaces you added to Tim's quoted text, though. I get trailing spaces on everything I cut/paste from Google groups. I've removed them for my testing, apologies if one got left in when I posted something I quoted (probably taken from one of my original grabbed files before I hacked it up). > It does; it applies to the next character in the logical line that > exists in ISO C translation phase 3. > > The backslash-newline is a form of escape, but in a separate pass. Thanks, that's the part I wasn't understanding. Keep in mind that my compiler "Micro-C" was also written long before standards. I later added some of the newer standard features, but never claimed it was standard complaint. The requirement to perform preprocessing in specifically defined ordered passes was not something I ever thought about because it never caused issues for me. Like I said, you can learn something new every day. Dave Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-05 18:57 +0000 |
| Message-ID | <20210105104700.123@kylheku.com> |
| In reply to | #158184 |
On 2021-01-05, Dave Dunfield <dave.dunfield@gmail.com> wrote:
> On Tuesday, January 5, 2021 at 12:23:57 PM UTC-5, Kaz Kylheku wrote:
>> Not with the trailing spaces you added to Tim's quoted text, though.
>
> I get trailing spaces on everything I cut/paste from Google groups.
> I've removed them for my testing, apologies if one got left in when I posted
> something I quoted (probably taken from one of my original grabbed files before
> I hacked it up).
>
>> It does; it applies to the next character in the logical line that
>> exists in ISO C translation phase 3.
>>
>> The backslash-newline is a form of escape, but in a separate pass.
>
> Thanks, that's the part I wasn't understanding. Keep in mind that my compiler "Micro-C" was
> also written long before standards. I later added some of the newer standard features, but never
> claimed it was standard complaint. The requirement to perform preprocessing in specifically
> defined ordered passes was not something I ever thought about because it never caused issues
> for me.
Well, consider that preprocessing originated as a text filter run in
front of a separate compiler; that all coming from Unix, pipelines being
unsurprising.
I think some early versions of the preprocessor may have been pretty
dumb, and not even tokenizing the code as far as recognizing string
literals, as is required now. In fact, the V7 Unix cpp (C preprocessor)
is like this.[1]
So backslash-newline processing would be done in the preprocessor
process, but features like backslash escapes in strings and character
literals only being recognized being in the "compiler proper".
---
[1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/cpp
See comment and accompanying example in README file:
"Macro formals are recognized even inside character constants
and quoted strings."
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 12:58 -0800 |
| Message-ID | <e138c342-f48a-4f08-97e9-7f74e185dd12n@googlegroups.com> |
| In reply to | #158180 |
Just a closing thought on this discussion:
> > I've always thought of escapes (and hence my compiler does too) as
> > in the order the characters occur, and that the escape applies to the
> > NEXT character in sequence:
> It does; it applies to the next character in the logical line that
> exists in ISO C translation phase 3.
I understand why this might occur in some implementations, and I agree that the standard
should account for it, but I disagree that it should be mandated by the standard. Like some
other things in the standard, I feel that this should be a "may" item - ie: This may occur in
some implementations and is not guaranteed by the standard.
I can't see a reason to code like this and there are other more straightforward ways to
code this without relying on this characteristic.
In addition to being caused by a particular implementation decision, it is also not fully
predicable unless you know inner technical details of the compiler. (Which a user should
not have to know). Consider:
--------------------------------------------------
#include <stdio.h>
#define foo "A\\
tB"
main()
{
fputs(foo, stdout);
}
-------------------------------------------------
As expected, the '\nl' takes precedence, so the string becomes:
"A\nl\tB"
which correctly prints as "A<tab>B"
Leading to the general idea that '\\nl' will be treated as:
"'\nl\whatever-follows"
Now consider:
"A\\
B"
(no spaces at the ends of preceding lines)
You might think this would translate to
"A\nl\nlB"
But try compiling with LCC/GCC:
cpp: t.c:3 Unterminated string or char const
cpp: t.c:5 Unterminated string or char const
Error t.c: 7 Syntax error; missing semicolon before `main'
Error t.c: 9 illegal expression
Error t.c: 9 found 'int' expected a function
Error t.c: 9 type error in argument 1 to `fputs'; found 'void' expected 'pointer to char'
Error t.c: 9 insufficient number of arguments to `fputs'
1 error
Knowing why it happens you could know that it likely won't work across
multiple newlines - but does the standard actually mandate that it can't.
A vendor could knowing that it is mandated to work the first time, detect
it and make it work over multiple newlines.
IMHO this behavior should be implementation dependent and a really
good compiler might allow it and issue a warning that you are relying on
non-standard behavior.
Please enlighten me if there is a compelling reason to rely on this behavior.
Dave
Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-05 17:31 -0500 |
| Message-ID | <WM5JH.49430$iY1.34514@fx39.iad> |
| In reply to | #158189 |
On 1/5/21 3:58 PM, Dave Dunfield wrote: > Just a closing thought on this discussion: > >>> I've always thought of escapes (and hence my compiler does too) as >>> in the order the characters occur, and that the escape applies to the >>> NEXT character in sequence: >> It does; it applies to the next character in the logical line that >> exists in ISO C translation phase 3. > > I understand why this might occur in some implementations, and I agree that the standard > should account for it, but I disagree that it should be mandated by the standard. Like some > other things in the standard, I feel that this should be a "may" item - ie: This may occur in > some implementations and is not guaranteed by the standard. > > I can't see a reason to code like this and there are other more straightforward ways to > code this without relying on this characteristic. > > In addition to being caused by a particular implementation decision, it is also not fully > predicable unless you know inner technical details of the compiler. (Which a user should > not have to know). Consider: > One of the reasons it was defined the way it was is to allow for machine code generation to be simple. IF you want the lines to have an 80 character limit, then after putting 79 characters on the line, if the next one isn't the last on the line, spit out a \ <newline> and continue on. One basic idea with the standard is that its job wasn't to make the job of writing a compiler easier, but to make the use of the system easier. Writing the implementation was a do once job, but it was going to hopefully be used many times. But there are definite limits to that. The language was designed to be mostly abled to be processed with one pass through the code (maybe multiple phases, but the output of each phase could just be piped to the next), without need for much backtracking. Also things that come with extra runtime cost (like bounds checking) were avoided.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-05 17:50 -0500 |
| Message-ID | <rt2qes$gpf$1@dont-email.me> |
| In reply to | #158189 |
On 1/5/21 3:58 PM, Dave Dunfield wrote:
> Just a closing thought on this discussion:
>
>>> I've always thought of escapes (and hence my compiler does too) as
>>> in the order the characters occur, and that the escape applies to the
>>> NEXT character in sequence:
>> It does; it applies to the next character in the logical line that
>> exists in ISO C translation phase 3.
>
> I understand why this might occur in some implementations, and I agree that the standard
> should account for it, but I disagree that it should be mandated by the standard. Like some
> other things in the standard, I feel that this should be a "may" item - ie: This may occur in
> some implementations and is not guaranteed by the standard.
It's been mandated by all versions of the C standard since 1990. While
it might seem odd in this particular context, the rules about how
translation phases 2 and 3 interact are important in other contexts such
as multi-line macros - you shouldn't expect any relaxation of those rules.
> I can't see a reason to code like this and there are other more straightforward ways to
> code this without relying on this characteristic.
>
> In addition to being caused by a particular implementation decision, it is also not fully
> predicable unless you know inner technical details of the compiler. (Which a user should
> not have to know). Consider:
>
> --------------------------------------------------
> #include <stdio.h>
>
> #define foo "A\\
> tB"
There's considerable room for confusion here. I'm going to write
character strings in standard C notation, that represent what the source
code looks like inside the compiler before translation phase 2:
"\"A\\\\\ntB\""
That string literal is equivalent to an 8 element array of char with the
following initializers:
{'"', 'A', '\\', '\\', '\n', 't', 'B', '"'}
> main()
> {
> fputs(foo, stdout);
> }
> -------------------------------------------------
>
> As expected, the '\nl' takes precedence, so the string becomes:
> "A\nl\tB"
You're misunderstanding something. At the end of translation phase 2,
"\\\n" gets removed, so it becomes
"\"A\\tB\""
> which correctly prints as "A<tab>B"
That, on the other hand, is correct.
> Leading to the general idea that '\\nl' will be treated as:
> "'\nl\whatever-follows"
No, that's not the correct idea. The general idea is that "\\\n" will be
treated as "".
> Now consider:
> "A\\
>
> B"
A string equivalent to that source code after it has been read into the
compiler could be written as
"\""A\\\\\n\nB\"".
> (no spaces at the ends of preceding lines)
>
> You might think this would translate to
> "A\nl\nlB"
No, at the end of translation phase 2 it would become
"\""A\\\nlB\""
The second '\\' and the newline that follow it both get removed, leaving
the first '\\' followed immediately by a newline. However, that
combination is NOT removed, because the relevant rule says "Only the
last backslash on any physical source line shall be eligible for being
part of such a splice."
The resulting sequence of characters is a syntax error, since strings
are not allowed to contain newline characters. Newline escape sequences
which get converted into newline characters are allowed, but newline
characters themselves are not.
...
> Knowing why it happens you could know that it likely won't work across
> multiple newlines - but does the standard actually mandate that it can't.
Because you seem to be misunderstanding something here, I'm not quite
sure what that question means. It might be related to the text mentioned
above, which restricts line splicing to that last backslash on each
physical source code line.
> A vendor could knowing that it is mandated to work the first time, detect
> it and make it work over multiple newlines.
>
> IMHO this behavior should be implementation dependent and a really
> good compiler might allow it and issue a warning that you are relying on
> non-standard behavior.
I'm fairly certain that any such change would break multi-line macros,
which are fairly commonly used. However, since you seem to be
misunderstanding something, I'm not sure precisely what you're
suggesting. I'll quote the relevant text from the standard below. Please
indicate how you think it should be modified:
"The precedence among the syntax rules of translation is specified by
the following phases.
...
2. Each instance of a backslash character (\) immediately followed by a
new-line character is deleted, splicing physical source lines to form
logical source lines. Only the last backslash on any physical source
line shall be eligible for being part of such a splice. A source file
that is not empty shall end in a new-line character, which shall not be
immediately preceded by a backslash character before any such splicing
takes place.
3. The source file is decomposed into preprocessing tokens 7) and
sequences of white-space characters (including comments).
...
" (5.1.1.2)
"preprocessing-token:
header-name
identifier
pp-number
character-constant
string-literal
punctuator
each non-white-space character that cannot be one of the above" (6.4p1)
"escape-sequence:
simple-escape-sequence
octal-escape-sequence
hexadecimal-escape-sequence
universal-character-name
simple-escape-sequence: one of
\' \" \? \\
\a \b \f \n \r \t \v
octal-escape-sequence:
\ octal-digit
\ octal-digit octal-digit
\ octal-digit octal-digit octal-digit
hexadecimal-escape-sequence:
\x hexadecimal-digit
hexadecimal-escape-sequence hexadecimal-digit" (6.4.4.4p1)
"string-literal:
encoding-prefix opt " s-char-sequence opt "
encoding-prefix:
u8
u
U
L
s-char-sequence:
s-char
s-char-sequence s-char
s-char:
any member of the source character set except
the double-quote ", backslash \, or new-line character
escape-sequence" (6.4.5p1)
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 19:33 -0800 |
| Message-ID | <78fdc5df-a4e2-40f0-ae4e-48741d331faen@googlegroups.com> |
| In reply to | #158199 |
I don't see much point continuing... but in "short" response: > > #define foo "A\\ > > tB" > > ... discussion about this code ... > > which correctly prints as "A<tab>B" > That, on the other hand, is correct. > No, that's not the correct idea. The general idea is that "\\\n" will be > treated as "". Since we had no discussion of three '\' characters, I'm guessing that the above is the same as my: \\nl where 'nl' is an actual newline character (end of line) So applying that rule, the #define becomes: #define foo "AB" but it prints as "A<tab>B" and: #define foo "\\ "/*" prints as: "/* (assuming GCC is generating correct code) Suggesting that if the '\nl' at the end of the line takes precedence the preceding '\' carries over to the 't' or '"' on the next line when \nl becomes "" and the lines are effectively joined, which was what I was trying to say. > > IMHO this behavior should be implementation dependent and a really > > good compiler might allow it and issue a warning that you are relying on > > non-standard behavior. > I'm fairly certain that any such change would break multi-line macros, > which are fairly commonly used. "allowing it" and Issuing a warning would break existing code? And why is this a significant issue? Which brings me back to a question I previously asked that nobody has bothered to actual answer: Is there a compelling reason to code : ...otherstuff...\\nl if as you say a trailing: \\nl becomes "" then why not use: ...otherstuff...\nl which does the same thing, is there ever an actual reason to use: ...\\nl If as I had guessed, the preceding '\' applies to the first character on the next line (after the last-on-line '\nl' becomes "") - which it seems to, they why not use: ...otherstuff...\nl \..nextlinestuff... Is there ever any reason to move the '\' from the beginning of the second line (ie: from immediately before the character it applies to) to before the '\nl' of the first line other than to break the idea that '\' applies to the very next character. (I do understand that this might happen due to the way the preprocessor joins lines, which is why I suggested a warning instead of a mandate). In other words, I've written LOTS of multi-line macro's without resorting to ending lines with: \\nl for me '\nl' gets removed effectively joining the lines, it I want an actual newline in a string, I use: ...\n\nl can you give an example of where you would actually require: ...\\nl Dave Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-05 23:02 -0500 |
| Message-ID | <2DaJH.72833$kZ1.12267@fx37.iad> |
| In reply to | #158204 |
On 1/5/21 10:33 PM, Dave Dunfield wrote: > I don't see much point continuing... but in "short" response: > >>> #define foo "A\\ >>> tB" >>> ... discussion about this code ... >>> which correctly prints as "A<tab>B" >> That, on the other hand, is correct. > >> No, that's not the correct idea. The general idea is that "\\\n" will be >> treated as "". > > Since we had no discussion of three '\' characters, I'm guessing that the above > is the same as my: \\nl > where 'nl' is an actual newline character (end of line) > > So applying that rule, the #define becomes: #define foo "AB" > but it prints as "A<tab>B" > > and: > > #define foo "\\ > "/*" > > prints as: "/* > > (assuming GCC is generating correct code) > > Suggesting that if the '\nl' at the end of the line takes precedence the preceding > '\' carries over to the 't' or '"' on the next line when \nl becomes "" and the lines are > effectively joined, which was what I was trying to say. > >>> IMHO this behavior should be implementation dependent and a really >>> good compiler might allow it and issue a warning that you are relying on >>> non-standard behavior. >> I'm fairly certain that any such change would break multi-line macros, >> which are fairly commonly used. > > "allowing it" and Issuing a warning would break existing code? > > And why is this a significant issue? Which brings me back to a question I previously > asked that nobody has bothered to actual answer: > > Is there a compelling reason to code : ...otherstuff...\\nl > > if as you say a trailing: \\nl > becomes "" then why not use: ...otherstuff...\nl > which does the same thing, is there ever an actual reason to use: ...\\nl > > If as I had guessed, the preceding '\' applies to the first character on the next line > (after the last-on-line '\nl' becomes "") - which it seems to, they why not use: > > ...otherstuff...\nl > \..nextlinestuff... > > Is there ever any reason to move the '\' from the beginning of the second line > (ie: from immediately before the character it applies to) to before the '\nl' of the > first line other than to break the idea that '\' applies to the very next character. > (I do understand that this might happen due to the way the preprocessor joins lines, > which is why I suggested a warning instead of a mandate). > > In other words, I've written LOTS of multi-line macro's without resorting to ending > lines with: \\nl > for me '\nl' gets removed effectively joining the lines, it I want an actual newline in a > string, I use: ...\n\nl > can you give an example of where you would actually require: ...\\nl > > Dave > Search "Dave's Old Computers" see "my personal" at bottom! > My guess we got here as that is what the first implementations did, so to preserve compatibility that is how the rules were written. Also, it does become handy to allow simpler mechanical code generation, only needing to see if the 80th character on the line will be the last or not, and if not, output \ <nl> To make \\<nl> pull the slashes together (assuming your in a string) would require the output generator to be a bit more complex and if the 79th was a \ see if the 80th was going to be the last character on the line, and if not send out the new line and a slash, (or would that only apply if in a string?, which requires the output generator to keep track of even more).
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 21:00 -0800 |
| Message-ID | <86d52273-f9eb-45a3-8a8d-5a106679d1c8n@googlegroups.com> |
| In reply to | #158205 |
> My guess we got here as that is what the first implementations did, so > to preserve compatibility that is how the rules were written. That's kinda what I've been thinking. > Also, it does become handy to allow simpler mechanical code generation, > only needing to see if the 80th character on the line will be the last > or not, and if not, output \ <nl> > > To make \\<nl> pull the slashes together (assuming your in a string) > would require the output generator to be a bit more complex and if the > 79th was a \ see if the 80th was going to be the last character on the > line, and if not send out the new line and a slash, (or would that only > apply if in a string?, which requires the output generator to keep track > of even more). It doesn't have to be complex, It's been quite a few years since I looked at any of this code in detail, but I just dug it out and Micro-C's preprocessor only handles '\nl' but it always passes the next character after '\' through UNLESS is it 'nl', which is why '\\nl' is not recognized by MCP '\\' gets passed "as is". All other escape sequences are handled by the compiler itself. (and '\\' becomes "\"). But this does not have to be big/complex: (remember these are 16 bit executables, originally written in the 80's). MCP - the preprovessor Source: 14.3k, 898 lines. MCP.EXE (DOS executable) = 14k MCP.DVM (DVM executable) = 6.1k ** The compiler is a bit harder to quantify, as there are 12 different variations targeting different processor families. main compile module: Source: 56.4k, 2336 lines. There is also a very small IO module and a more complex code generator which differs by processor, but these have nothing to do with the understanding of the language. MCC.EXE (DOS/8086) = 26.1k MCC.DVM (DVM) = 17.3k ** ** DVM is "Dunfield Virtual Machine" which runs a lot of my original code on more modern platforms (such as Win64). It is based on C-FLEA, a processor/instruction set I designed a number of years back which is very suitable for C and code is quite easily generated by my compiler. More information on these things can be found on my personal site if anyone wants to "know more" (see information below). Dave Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-06 07:42 -0500 |
| Message-ID | <zeiJH.13295$5s2.12914@fx18.iad> |
| In reply to | #158207 |
On 1/6/21 12:00 AM, Dave Dunfield wrote: >> My guess we got here as that is what the first implementations did, so >> to preserve compatibility that is how the rules were written. > > That's kinda what I've been thinking. > >> Also, it does become handy to allow simpler mechanical code generation, >> only needing to see if the 80th character on the line will be the last >> or not, and if not, output \ <nl> >> >> To make \\<nl> pull the slashes together (assuming your in a string) >> would require the output generator to be a bit more complex and if the >> 79th was a \ see if the 80th was going to be the last character on the >> line, and if not send out the new line and a slash, (or would that only >> apply if in a string?, which requires the output generator to keep track >> of even more). > > It doesn't have to be complex, It's been quite a few years since I looked > at any of this code in detail, but I just dug it out and Micro-C's > preprocessor only handles '\nl' but it always passes the next character > after '\' through UNLESS is it 'nl', which is why '\\nl' is not recognized > by MCP '\\' gets passed "as is". > > All other escape sequences are handled by the compiler itself. (and '\\' > becomes "\"). > > But this does not have to be big/complex: > (remember these are 16 bit executables, originally written in the > 80's). > > MCP - the preprovessor > Source: 14.3k, 898 lines. > MCP.EXE (DOS executable) = 14k > MCP.DVM (DVM executable) = 6.1k ** > > The compiler is a bit harder to quantify, as there are 12 different > variations targeting different processor families. > > main compile module: > Source: 56.4k, 2336 lines. > There is also a very small IO module and a more complex > code generator which differs by processor, but these have nothing > to do with the understanding of the language. > MCC.EXE (DOS/8086) = 26.1k > MCC.DVM (DVM) = 17.3k ** > > ** DVM is "Dunfield Virtual Machine" which runs a lot of my original > code on more modern platforms (such as Win64). It is based on C-FLEA, > a processor/instruction set I designed a number of years back which is > very suitable for C and code is quite easily generated by my compiler. > > More information on these things can be found on my personal site if > anyone wants to "know more" (see information below). > > Dave > Search "Dave's Old Computers" see "my personal" at bottom! > You have your rules backwards, just because there is an easy way to do it wrong (for the implementation) doesn't provide a reason that it should be 'right' (allowed for the implementation to do it that way). The developement of the C Language/Standard was NEVER about making the writing of an implemenation as easy as possible. The designers realized that writing the complier was an infrequent action, while using it was much more common. They DID make sure to cap the complexity of the language, so it has things like needing limited look ahead, so a valid implementation could be fairly simple, but it did need SOME care to do it right. I remember one of the mantras of the Standards Committee was that "Existing Programs were important, Existing Implementations were not", which meant that a languag change that broke existing programs was to be avoided when possible, including those using implementation defined behavior or extensions. But they didn't really care if a change required totally rewriting the compiler. This is one reason some things are still undefined or implementation defined behavior, because implementations differed on how they did things, so to define it one way would break the programs that depended on the implementation definition of some other way (like what does malloc(0) return). When one side of such a divergence dies out, they will sometimes pull back and define that behavior, but that is a slow process.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-06 08:55 -0800 |
| Message-ID | <97ebd421-8f0f-4621-bdb9-96d655ba9d9an@googlegroups.com> |
| In reply to | #158215 |
>You have your rules backwards, just because there is an easy way to do
>it wrong (for the implementation) doesn't provide a reason that it
>should be 'right' (allowed for the implementation to do it that way).
Not in any way the idea behind my comment/postings.
In fact this makes more of a case for it than against it.
In C the sequence \something is an escape sequence which causes
some special action defined by 'something', some examples:
(I am using <N> to indicate a newline character which indicates
the end of a source line)
'\n' = insert a newline character
'\r' = insert a return character
'\t' = insert a tab character
'\b' = insert a backspace character
'\\' = insert a '\' character
\v where 'v' is up to 3 octal digits - Insert character with octal value v
\xv where v is up to 2 hexadecimal digits = Insert character with hex value v
\<N> where <N> is a newline (end of line) = Ignore the newline and logically
join the line you and ending to the next line.
>The developement of the C Language/Standard was NEVER about making the
>writing of an implementation as easy as possible. The designers realized
>that writing the complier was an infrequent action, while using it was
>much more common.
Exactly, except that somewhere along the way, somebody realized that to
properly handle many of the escape actions they had to be done after the
line was tokenized, eg: \" wouldn't let you insert a '"' in a string if
all the compiler saw in either case was a source input of '"'.
But... lines had to be read before they were tokenized so '\n' was a
special case that had to be done earlier -- so as they read each line they
looked for '\' at the end to handle line continuations.
This caused the side affect that for lines ending with: \\<N>
the '\<N>' is removed and the line is joined to the next line causing
the first '\' to be applied to the first character on the next line as
the line is tokenized.
My thought is this this is undesirable because it voids the otherwise
valid notion that a \ escape applies to what immediately follows it
(in this case another '\'). But .. to coin your phrase this made
"writing of an implementation as easy as possible".
And apparently this became part of the standard.
If it weren't for this side affect, lines ending with: \\<N>
would become '\\','\n' without regard to whatever is on the next
line. To me this is more what I think a non-compiler writer might expect.
(Q: when is \\ not '\' - A: when it occurs immediately before a newline).
>I remember one of the mantras of the Standards Committee was that
>"Existing Programs were important, Existing Implementations were not",
>which meant that a language change that broke existing programs was to be
>avoided when possible, including those using implementation defined
>behavior or extensions. But they didn't really care if a change required
>totally rewriting the compiler.
which leads to the question... Did people actually significantly use this
behavior where the first \ in \\<N> applies to the first character of
the next line -- enough to standardize it?
There are certainly more obvious ways to code an escape at the start
of a line... and I've yet to see an example where the sequence: \\<N>
would be needed (or even more useful).
The point I was trying to make in my last post was that making it work
as you would expect rather that what someone found easy would not have
been at all difficult:
// Idea presented as a code segment, which is untested
// does not handle EOF conditions etc. - not real code
c = getc(infile);
if(c == '\\') {
c = getc(infile);
if(c == '\n') {
handle_joining_line(); }
else {
process_input_char('\\');
process_input_char(c); } }
else {
process_input_char(c); }
Dave
Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-06 13:29 -0500 |
| Message-ID | <IknJH.13301$5s2.3361@fx18.iad> |
| In reply to | #158220 |
On 1/6/21 11:55 AM, Dave Dunfield wrote:
>> You have your rules backwards, just because there is an easy way to do
>> it wrong (for the implementation) doesn't provide a reason that it
>> should be 'right' (allowed for the implementation to do it that way).
>
> Not in any way the idea behind my comment/postings.
>
> In fact this makes more of a case for it than against it.
>
> In C the sequence \something is an escape sequence which causes
> some special action defined by 'something', some examples:
>
> (I am using <N> to indicate a newline character which indicates
> the end of a source line)
>
> '\n' = insert a newline character
> '\r' = insert a return character
> '\t' = insert a tab character
> '\b' = insert a backspace character
> '\\' = insert a '\' character
> \v where 'v' is up to 3 octal digits - Insert character with octal value v
> \xv where v is up to 2 hexadecimal digits = Insert character with hex value v
> \<N> where <N> is a newline (end of line) = Ignore the newline and logically
> join the line you and ending to the next line.
>
>> The developement of the C Language/Standard was NEVER about making the
>> writing of an implementation as easy as possible. The designers realized
>> that writing the complier was an infrequent action, while using it was
>> much more common.
>
> Exactly, except that somewhere along the way, somebody realized that to
> properly handle many of the escape actions they had to be done after the
> line was tokenized, eg: \" wouldn't let you insert a '"' in a string if
> all the compiler saw in either case was a source input of '"'.
>
> But... lines had to be read before they were tokenized so '\n' was a
> special case that had to be done earlier -- so as they read each line they
> looked for '\' at the end to handle line continuations.
>
> This caused the side affect that for lines ending with: \\<N>
> the '\<N>' is removed and the line is joined to the next line causing
> the first '\' to be applied to the first character on the next line as
> the line is tokenized.
>
> My thought is this this is undesirable because it voids the otherwise
> valid notion that a \ escape applies to what immediately follows it
> (in this case another '\'). But .. to coin your phrase this made
> "writing of an implementation as easy as possible".
> And apparently this became part of the standard.
>
> If it weren't for this side affect, lines ending with: \\<N>
> would become '\\','\n' without regard to whatever is on the next
> line. To me this is more what I think a non-compiler writer might expect.
> (Q: when is \\ not '\' - A: when it occurs immediately before a newline).
>
>
>> I remember one of the mantras of the Standards Committee was that
>> "Existing Programs were important, Existing Implementations were not",
>> which meant that a language change that broke existing programs was to be
>> avoided when possible, including those using implementation defined
>> behavior or extensions. But they didn't really care if a change required
>> totally rewriting the compiler.
>
> which leads to the question... Did people actually significantly use this
> behavior where the first \ in \\<N> applies to the first character of
> the next line -- enough to standardize it?
>
> There are certainly more obvious ways to code an escape at the start
> of a line... and I've yet to see an example where the sequence: \\<N>
> would be needed (or even more useful).
>
> The point I was trying to make in my last post was that making it work
> as you would expect rather that what someone found easy would not have
> been at all difficult:
>
> // Idea presented as a code segment, which is untested
> // does not handle EOF conditions etc. - not real code
> c = getc(infile);
> if(c == '\\') {
> c = getc(infile);
> if(c == '\n') {
> handle_joining_line(); }
> else {
> process_input_char('\\');
> process_input_char(c); } }
> else {
> process_input_char(c); }
>
> Dave
> Search "Dave's Old Computers" see "my personal" at bottom!
>
You are again making a mistake about the goal in the language design.
You seem to be assuming that one goal is to make a language as simple as
possible to be understood and for a beginner to write. It wasn't. It was
always assumed that someone writing in C would be a seasoned programmer,
and thus the language didn't need to hold someones hand.
Also your question on the behavior of \\<nl> is a bit backwards, I
suspect that first time it came up wasn't asking how to seperate the
slash from the character after it, but was how to make sure the first
slash didn't mess up the second slash being part of the line continuation.
Hand generated code would not contain the \\<nl> sequence, either the
program would put up the next character to this line, like \"\<nl> or
would move the first slash to the next line, so no need to set that for
a human programmer.
The thing that would generate that sequence would be some program
outputting C code and wanting to keep line lengths under a limit so they
could be printed in a listing. In that case a line ending in \\<nl>
would clearly not want the first slash to eat the second and quote it,
as that would almost certainly create a syntax error, so forcing that
interpretation would just make the programmer writing the code generator
to do more work. Since this sort of machine generated code isn't that
readable to start with, the parsing difficulties of the human reader
isnt that important.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-06 14:09 -0800 |
| Message-ID | <de2dba77-e273-484f-aeef-e01ffd374b88n@googlegroups.com> |
| In reply to | #158226 |
>You seem to be assuming that one goal is to make a language as simple as >possible to be understood and for a beginner to write. It wasn't. It was >always assumed that someone writing in C would be a seasoned programmer, >and thus the language didn't need to hold someones hand. Rookie or level of proficiency has nothing to do with it. I just "personally" find that a reduction in variations on a "rule" is usually better. I find what in regard to: <ESC><A><B><C> Being able to think this means: (special function)<A> irregardless of <B> or <C> (unless of course one of them is another <ESC>) seems more intuitive "to me" than: (special function)<A> except in cases depending on <A> and <B> where it really means: (an action based on <A> and <B>) and also (special function)<C> - note: <B> is NOT <ESC> This lack of consistency I think of as a moderate downside. And yes, I do know the difference between a line continuation and an escaped string character -- it's more about the meaning of the character '\' being different when performing a special function, regardless of where it occurs. >Also your question on the behavior of \\<nl> is a bit backwards, I >suspect that first time it came up wasn't asking how to seperate the >slash from the character after it, but was how to make sure the first >slash didn't mess up the second slash being part of the line continuation. No, I've never coded it this way (or even thought about it before), this discussion came from a problem about removing comments from C source in 25 lines, and one of the examples given to try was: #define foo "// "*/" I just commented that I didn't think it was a wonderful thing, and got told how "wrong" I was - which started this discussion. >The thing that would generate that sequence would be some program >outputting C code and wanting to keep line lengths under a limit so they >could be printed in a listing. In that case a line ending in \\<nl> >would clearly not want the first slash to eat the second and quote it, >as that would almost certainly create a syntax error, so forcing that >interpretation would just make the programmer writing the code generator >to do more work. Since this sort of machine generated code isn't that >readable to start with, the parsing difficulties of the human reader >isnt that important. Finally a use that makes some sense. Easily detected and worked around without this "feature", which would make me consider the lack of this "feature" a fairly small downside. (That and the fact that a program printed with this type of coding might be somewhat less legible). Slightly more of an issue if for some reason you wanted to make all lines a specific length, but doing that might need enough extra logic that it wouldn't matter. I personally think that the moderate downside of the former outweighs the small downside of the latter. But that just my opinion. But clearly there are a lot of people who think otherwise and who am I to suggest something is not perfect. And subsequent posters have explained the logic and reasoning behind it well enough that I would now concede that either approach would have advantages (and disadvantages). So I am going to bow out of this discussion. It has been many years since I participated in usenet and COMP.LANG.C was probably not a great place to start back - I had forgotten how negative participants can be to other opinions. Dave Search "Dave's Old Computers" see my "persona" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-06 22:11 -0500 |
| Message-ID | <rt5u48$ej6$1@dont-email.me> |
| In reply to | #158234 |
On 1/6/21 5:09 PM, Dave Dunfield wrote: ... > I just "personally" find that a reduction in variations on a "rule" > is usually better. I find what in regard to: > > <ESC><A><B><C> > > Being able to think this means: (special function)<A> > irregardless of <B> or <C> (unless of course one of them is > another <ESC>) > > seems more intuitive "to me" than: > (special function)<A> except in cases depending on <A> and <B> > where it really means: (an action based on <A> and <B>) and also > (special function)<C> - note: <B> is NOT <ESC> > > This lack of consistency I think of as a moderate downside. > > And yes, I do know the difference between a line continuation and > an escaped string character -- it's more about the meaning of the > character '\' being different when performing a special function, > regardless of where it occurs. The rule is really quite simple: escaped newlines are removed during translation phase 2. Other escape sequences are parsed after phase 2. Any way of thinking about it that makes it more complicated to understand than that is the wrong way of thinking about it. Note that Tim's challenge makes this more complicated, by requiring that escaped newlines that are not inside of comments should be retained. That turns out to be significantly more difficult, which probably explains why the C standard handles that issue differently than his challenge does.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-07 03:10 -0800 |
| Message-ID | <f74bd34d-0c8c-4d94-ba83-1cddf210084en@googlegroups.com> |
| In reply to | #158234 |
One "final final" thought. I meant to include this in my "last" posting yesterday but it slipped my mind. >I wrote a long explanation before I realized that I'm not sure what >you're suggesting. You're saying that ...otherstuff...\nl would be a >better alternative to something involving \\nl, but it's not clear to me >what that something is. Presumably it involves otherstuff, but I'm not >sure where otherstuff is supposed to be relative to the \\nl. > I actually would prefer that: \\<nl> cause a compile error except possibly in very exceptional cases where the construct '\\', <nl> is part of legit code. But I also think that error messages are not always bad. Given that I still don't see a reason to manually code: ...\\<nl> this would almost certainly be a typo in my source. So if \\<nl> is a typo for \<nl> in the following line: "Source contains ISO \"feature\" which you likely didn't intend to use.\n\\ but may go undetected, causing subtle working error you might not notice." which do you think would be the better result: Compiles OK, string: "... use.<nl><bs>ut may ..." or: Compile error: cpp: tst.c:4 Unterminated string or char const note: the line with the typo is 4 - error shows exactly where typo is. I know this won't be a concern for those of you who never make mistakes, but unfortunately, despite having been programming since the 70's, I still occasionally do... Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-07 06:40 -0500 |
| Message-ID | <tqCJH.89549$192.58679@fx47.iad> |
| In reply to | #158249 |
On 1/7/21 6:10 AM, Dave Dunfield wrote: > One "final final" thought. I meant to include this in my "last" > posting yesterday but it slipped my mind. > >> I wrote a long explanation before I realized that I'm not sure what >> you're suggesting. You're saying that ...otherstuff...\nl would be a >> better alternative to something involving \\nl, but it's not clear to me >> what that something is. Presumably it involves otherstuff, but I'm not >> sure where otherstuff is supposed to be relative to the \\nl. > > > I actually would prefer that: \\<nl> > cause a compile error except possibly in very exceptional cases > where the construct '\\', <nl> is part of legit code. > > But I also think that error messages are not always bad. > Given that I still don't see a reason to manually code: ...\\<nl> > this would almost certainly be a typo in my source. But there isn't a good reason to manually enter \\<nl> in code, but there is very good reason for it to occur in programattically generated code. It also simplifies the rules needed to describe the langauge. > > So if \\<nl> is a typo for \<nl> in the following line: > > "Source contains ISO \"feature\" which you likely didn't intend to use.\n\\ > but may go undetected, causing subtle working error you might not notice." > > which do you think would be the better result: > > Compiles OK, string: "... use.<nl><bs>ut may ..." > > or: > > Compile error: cpp: tst.c:4 Unterminated string or char const Or, if this actually turns out to be a common enough problem to be worth detecting, the compiler is ALWAYS allowed to generate a warning for this, which in a 'non-conforming' mode could be upgraded to an error. > > note: the line with the typo is 4 - error shows exactly where typo is. > > I know this won't be a concern for those of you who never make mistakes, > but unfortunately, despite having been programming since the 70's, I still > occasionally do... > > Dave > Search "Dave's Old Computers" see my "personal" at bottom! >
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-09 06:27 -0800 |
| Message-ID | <f57a787a-4790-4e00-9662-bcf35ef69e05n@googlegroups.com> |
| In reply to | #158249 |
> One "final final" though ... :-)
// Amazing what you brain does while you are "sleeping"...
// Woke up with the idea that actually handling: \\<nl>
// wouldn't be that hard at all - of course the 25 line limit makes the
// implementation a bit "odd", If I needed this program I would likely
// have implemented it all in one larger function (and there might have
// been a "goto" or two).
//
// Other than a few cursory runs to see that the changes seem work,
// this version not really tested...
/*
* whole line comments could easily be absent and should not
* could against to 25 lime function body limit.
*
* Assumes a valid 'C' program as input, will not detect
* certain errors affecting comments, quotes or escapes.
*/
#include <stdio.h>
unsigned // at least 16 bits to insure '& 0xFF00' works
C0; // Last character read
unsigned char
C1, // Previous character read
Bbn, // BackslashBackslashNewline tracker
Imode; // Input mode
unsigned char rdchar(void)
{
for(;;) {
C1 = C0;
// Assumes 8-bit char set, not including 0 and EOF is >255
if((C0 = getc(stdin)) & 0xFF00)
return 0;
// changing this to multiple 'if's could eliminate the 'switch' line
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C0 == '/')) {
Imode = 0;
C0=' '; } // Replace /*...*/ with single space
continue;
case '/' : // Inside '//' comment
if(C0 == '\n')
Imode = 0;
continue;
case 0 : // No special mode
// could be considered as two lines in one, although it's a construct I
// sometimes use if a single 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C0) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C0;
continue; } }
return C1; }
}
void handle_esc(void)
{
switch(rdchar()) {
case '\\': // Escape
putc(C1, stdout);
Bbn = rdchar();
case 0 :
return;
case '"':
case'\'':
if(Bbn != 0x80) {
if(Imode == C1)
Imode = 0;
else if(!Imode)
Imode = C1; }
break;
case '\n':
if(Bbn == '\\') {
fputs("?\\\\n\n", stderr); // a warning-not needed for chal
Bbn = 0x80; // Inhibit quote processing on next char
return; } }
Bbn = 0;
}
int main(void)
{
rdchar(); // First call to rdchar will return 0;
do {
handle_esc();
putc(C1, stdout);
} while(!(C0 & 0xFF00)); // Till EOF has ben read
}
// Dave
// Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
Page 15 of 20 — ← Prev page 1 … 13 14 [15] 16 17 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web