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 2 of 20 — ← Prev page 1 [2] 3 4 … 20 Next page →
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-04 18:42 +0000 |
| Message-ID | <20210103160134.362@kylheku.com> |
| In reply to | #158125 |
On 2021-01-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>
>> On 2020-12-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>> I think it's not honest to say that your program doesn't use goto.
>> It just disguises it using tail calls.
>
> Well let's see. Some people say:
>
> A 'break' statement is just a goto in disguise.
> A 'continue' statement is just a goto in disguise.
> A 'while' (or do/while) is just a goto in disguise.
> A 'for' is just a (syntactically sugared?) goto in disguise.
> A 'switch' is just a (computed?) goto in disguise.
> An 'if' is just a goto in disguise.
>
> And now we should add to that list:
>
> Some function calls are just gotos in disguise?
My point is actually more subtle that the above reductionisms.
We can easily convert between tail calls and goto *in both directions*.
Just as I was able to text-filter your program into a goto-based one,
I can filter mine to produce a tail-call based one.
Thus I could also say the reverse: that, also, goto is tail calling in
disguise.
Whereas I would not say that goto is while, for or switch in disguise.
The filter is not a compiler or anything. It doesn't have to parse the code
deeply. It doesn't even have to even invent machine-generated identifiers.
There is a 1:1 mapping between the identifiers and other elements
on both sides. The program borrows the function names for the goto
labels, and the parameter Count n for the state variable.
If I have such a filter in the goto->tail direction, then I can use the
goto-based program as the specification which I maintain, and translate
it for execution via transformation to tail calls.
Hence, because of this, I was very amused/pleased that when you finally
revealed your program, it was using tail calls. Of all the submissions, I see
yours as being the closest to my program's design approach.
(I just disguised my tail calls using goto, that's all.)
> I don't think so. My original posting said "Use no 'goto'
> statements" and that is exactly what I meant. Using 'while' or
> 'break' or 'continue', or any other "disguised" goto, follows
> both the letter and the spirit of the stipulation, as does
> using tail recursion.
Well, I don't know about the spirit part there.
> Furthermore tail calls have a distinction (and advantage) that
> other kinds of "disguised" gotos do not. If a 'break' or 'while'
> or 'continue', etc., is used, the program state ends up within the
> same function, including the state of variables in the function.
Code based on control structures like while, break and continue can be
translated into a tail calling network which is no easier to undersatnd.
The state of the variables is all there; it is transferred among the
functions, and so the reasoning about it is the same.
> To understand what's going on we must look for and understand how
> any such variables are used and modified. But tail calls don't
> have that problem: each function in the net of routines starts
> with a clean slate, and may confidently be read in isolation of
> all the others.
> So the idea that a tail call is just "a goto
> in disguise" doesn't hold even a tiny amount of water.
The thing is that any mess of variable assignments and goto can be
translated into a hornet's nest of mutually tail-calling functions,
which is just as hard to understand, having the same structure.
For each label in the goto structure, there can be a function of the
same name in the tail call structure.
The functions will not start "in a clean slate", because they
will take numerous argument values that have to be reasoned about.
For instance, suppose we have a function with 26 local variables a-z,
and a tangle of gotos.
Supppose somewhere there is a block like this:
whatever:
p = 42;
goto bar;
That might translate to the tail call:
bar(a, b, c, ..., m, n, o, 42, q, r ..., y, z);
Bar may be a separate lexical scope, but it's not a clean slate;
it's receiving p = 42, plus copies of 25 variables that we
have to also reason about. What is bar doing with a, b, c, ...?
Suppose bar does nothing with most of those variables but pass them on
Suppose the original goto-based bar is:
bar:
q++;
goto baz;
Then it looks like:
void bar(int a, int b, ... int y, int z)
{
baz(a, b, c, ..., p, q + 1, ... y, z);
}
The "clean slate" aspect of it being a function with formal parameters and its
own lexical scope doesn't amount to much once the parameters proliferate like
this. We have no idea what it means to pass parameter a to bar; it's
just passed to baz as-is, which passes it on. If instead we pass a + 1
to bar, we have no idea what happens without analyzing a chain of calls.
This is no different from following the original goto.
Basically, you have to compare equivalent goto and tail structures (such as one
that has been generated from the other).
If one has 17 state variables, the other should have tail calls with 17
parameters, so that it is apples to apples.
>> That entire tail-call-network section of the program beginning with
>> the start function down to before the I/O helpers could be turned
>> into a big function with labeled goto blocks. Moreover, the
>> structure would be essentially the same, about equally easy to
>> follow.
>
> So you say. I have seen your programs that take the 'goto'
> approach, and I don't think so.
Shall I do the grunt-work and machine-translate that program to tail calls?
>> There is a clear disadvantage. If there is no tail call elimination
>> in the compiler (which is not required by the standard) the program
>> needs automatic storage proprortional to the number of characters of
>> the input. This could happen even if the compiler supports tail
>> calls as an optimization, but the program is compiled without
>> optimization. [...]
>
> People who use substandard tools deserve what they get. Setting
> optimization levels is one reason projects are distributed with
> makefiles.
Properly written makefiles honor user's CFLAGS environment variable or command
line argument, using some other internal variable to inject their necessary
options, like language dialect selection and whatnot.
A good practice is:
CFLAGS ?= -O2 ... # conditionally set to -O2, if not coming from user
Pretty much any modern, mainstream GNU/Linux distro is built by a system which
dictates optimization and code generation flags on a global scale; projects are
expected to respect the distro build's CFLAGS and LDFLAGS and whatnot.
(One pet peeve of distro maintainers is badly behaved programs which ignore
the incoming CFLAGS and have to be patched.)
>> The dogged adherence to the functional style
>
> This is a mischaracterization. I chose to write in a functional
Sorry about that, and let me offer the observation that I also stick
to that style myself (when I choose to do so, not "doggedly" everywhere), and
use tricks like stuffing side effects into a comma expression to avoid breaking
out of it.
Here is a sample of my work which illustrates this:
static val me_interp_macro(val expander, val form, val menv)
{
val arglist = rest(form);
val env = car(expander);
val params = cadr(expander);
val body = cddr(expander);
val saved_de = set_dyn_env(make_env(nil, nil, dyn_env));
val exp_env = bind_macro_params(env, menv, params, arglist, nil, form);
val result = eval_progn(body, exp_env, body);
set_dyn_env(saved_de);
set_origin(result, form);
return result;
}
(set_dyn_env has a side effect!)
I believe this is a good thing. A function in C is "nice" when most of its
content consists of successive declarations, and most of it is free of side
effects.
When you do choose to some style, particularly in order to explore it, it in
fact behooves you to do it consistently, otherwise what is the point.
> You strike me as someone whose mind is stuck in a rut of always
> thinking of programs in terms of what goes on at the level of
> machine language.
Right, that must be why I wrote a program that transliterated your tail calling
code into goto, using techniques like pattern matching and object-orientation?
> Incidently, I note that none of the programs you posted made any
> effort to follow either of the two stated requirements (no goto
> statements, no overly long functions). If you never venture
Your note is not necessary because from the very beginning I reacted to
the challenge by promising to post an alternative program which flouts
the rules. When I proceeded to do exactly that, it should have been
unsurprising.
I anticipated that other entries would follow the rules, in which case
the situation would be left without any contrasting content.
Not that I'm offering it as a perfect analogy, but if we ran some sort of
study, we would want a control group, right? We wouldn't run a drug trial by
giving all subjects the pill being tested.
In the context of conducting a mini study based around avoiding goto, it's
useful to have some samples that don't avoid goto.
Had I written something with nested while loops, it might have ended up looking
like Jacob Navia's code or something. Basically, it wouldn't add anything.
I'm surprised, by the way, that you don't seem to recognize that the programs
are successive revisions one work, which is why they are consistent in
their approach. (I used git to track the changes, in fact.) The silly
first program I rushed out was quite incorrect, requiring an immediate
follow-up. A revision was required at some point to meet the requirement
for preserving line continuations outside of comments, and I also put
out a final revision in which switches replaced ifs.
$ git log --oneline
8e92b69 (HEAD -> master) Switch to switch.
da8dcf4 Use counting to reproduce continuations.
aec175d Preserve continuations that are not in comments.
d01897c Bugfix: getchar call should be s2getc.
b48482f Recognize continuations.
56e6cfe Add missing backslash output.
9e081e7 Comment eater.
> outside of your rut, very probably your views will never change.
> My hope is that other people will do better.
Your interpretation is odd. You seem to be under the impression that I
code with nothing but goto, and hence that is why I ignored the rules,
just to persist with, or promote, my favorite way of writing code.
You may believe so if you wish, but in fact that was by far the greatest
number of gotos I have ever concentrated in one place.
Sticking with the original requiremens of the task is "the rut", because
the requirements are more or less aligned with industry-wide best
practices that we all know and follow day in, day out.
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-04 21:23 +0000 |
| Message-ID | <20210104122140.777@kylheku.com> |
| In reply to | #158158 |
On 2021-01-04, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> On 2021-01-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> To understand what's going on we must look for and understand how
>> any such variables are used and modified. But tail calls don't
>> have that problem: each function in the net of routines starts
>> with a clean slate, and may confidently be read in isolation of
>> all the others.
>> So the idea that a tail call is just "a goto
>> in disguise" doesn't hold even a tiny amount of water.
>
> The thing is that any mess of variable assignments and goto can be
> translated into a hornet's nest of mutually tail-calling functions,
> which is just as hard to understand, having the same structure.
Here is a program I wrote to illustrate this idea. The program contains
a function which scans a vector of vector of integers to find the first
odd integer in row-major order. Except that 7 doesn't count; it is
skipped.
I then translated this using a mechanical (but manual) approach into
separate functions that tail call.
Both programs appear at the end of this article.
The original program uses nested for loops. The problem is defined such
that break and continue are required. This is to show how we translate
all those kinds of things into tail calls.
Improvements can be made in the tail call version, but I have not made
any. I note that making improvements is assisted by the ability to
reason about the function calls, and be able to make transformations
like manual inlining with confidence.
For instance, when the result is found, there is no need to go through
additional function calls to return the result. However, an early
return also be performed made in the original. The point is to compare
exactly the same logic.
In my opinion, the tail-call-based program is difficult to follow. This
is precisely because its structure is equivalent to an intermediate
goto-based program, devoid of the for loop control structures which make
he original readable. The tail calling approach disposes of control
structures; switching among several tail calls to arbitrary
destinations (passing to them the entire state vector) is the only
control construct.
However, in regardless of being able to understanding the
tail-call-based program, it's possible to make behavior-preserving
changes to its source code with confidence, based on reasoning like
manually inlining calls according to sound substitution principles, and
elimination of unused parameters.
I also have the observation that a language benefits from nested
functions in support of the tail calling style. The parameters a, h, and
w are repeated in all the function calls. In a language like Scheme, or
even Pascal, we would make these tail calls local functions enclosed
within the parent. The local functions would reference the a, h and w of
the parent, and not have to carry those parameters at all. This is yet
another way in which standard C is poorly suited for this type of
programming. GNU C is better in this regard; I'm not sure how good is
its tail call support for inner functions, though.
I also ran into the following tooling issue. Initially I neglected the
following declaration which makes find_odd_not_7 static:
static struct coord find_odd_not_7(int **a, size_t h, size_t w);
Without this static, GCC 7.5 on Ubuntu 18 refuses to treat the
tail calls. The compiled program ends up with three active functions:
main, top and itop. main makes a call to top, and top and itop mutually
recurse using subroutine calls rather than tail calls! A translation of
find_odd_not_7 is present in the image, but nothing calls it.
If I make that function static, it disappears. Then top and itop also
disappear. main calls a generated function called itop.constprop.5,
which calls nothing else; it contains all the tail calls as local
branches.
ORIGINAL:
#include <stdio.h>
struct coord { int r, c; };
struct coord find_odd_not_7(int **a, size_t h, size_t w)
{
int r, c;
for (r = 0; r < h; r++)
{
for (c = 0; c < w; c++)
{
int v = a[r][c];
if (v == 7)
continue;
if (v % 2 != 0)
break;
}
if (c < w)
break;
}
if (r == h && c == w)
return (struct coord) { -1, -1 };
return (struct coord) { r, c };
}
int main(void)
{
int r0[] = { 2, 4, 7 };
int r1[] = { 6, 5, 4 };
int *a0[3] = { r0, r1 };
int *a1[3] = { r0, r0 };
struct coord find0 = find_odd_not_7(a0, 2, 3);
struct coord find1 = find_odd_not_7(a1, 2, 3);
printf("find0 = { .r = %d, .c = %d }\n", find0.r, find0.c);
printf("find1 = { .r = %d, .c = %d }\n", find1.r, find1.c);
return 0;
}
TAIL CALLS:
#include <stdio.h>
struct coord { int r, c; };
static struct coord out(int **a, size_t h, size_t w, int r, int c);
static struct coord after(int **a, size_t h, size_t w, int r, int c);
static struct coord contin(int **a, size_t h, size_t w, int r, int c);
static struct coord iafter(int **a, size_t h, size_t w, int r, int c);
static struct coord icontin(int **a, size_t h, size_t w, int r, int c);
static struct coord body(int **a, size_t h, size_t w, int r, int c);
static struct coord itop(int **a, size_t h, size_t w, int r, int c);
static struct coord top(int **a, size_t h, size_t w, int r, int c);
static struct coord find_odd_not_7(int **a, size_t h, size_t w);
struct coord top(int **a, size_t h, size_t w, int r, int c)
{
return (r >= h)
? after(a, h, w, r, c)
: itop(a, h, w, r, 0);
}
struct coord itop(int **a, size_t h, size_t w, int r, int c)
{
return (c >= w) ? contin(a, h, w, r, c)
: body(a, h, w, r, c);
}
struct coord body(int **a, size_t h, size_t w, int r, int c)
{
int v = a[r][c];
return v == 7 ? icontin(a, h, w, r, c)
: v % 2 != 0 ? iafter(a, h, w, r, c)
: icontin(a, h, w, r, c);
}
struct coord icontin(int **a, size_t h, size_t w, int r, int c)
{
return itop(a, h, w, r, c + 1);
}
struct coord iafter(int **a, size_t h, size_t w, int r, int c)
{
return (c < w) ? after(a, h, w, r, c)
: contin(a, h, w, r, c);
}
struct coord contin(int **a, size_t h, size_t w, int r, int c)
{
return top(a, h, w, r + 1, c);
}
struct coord after(int **a, size_t h, size_t w, int r, int c)
{
return r != h || c != w ? out(a, h, w, r, c)
: out(a, h, w, -1, -1);
}
struct coord out(int **a, size_t h, size_t w, int r, int c)
{
return (struct coord) { r, c };
}
struct coord find_odd_not_7(int **a, size_t h, size_t w)
{
return top(a, h, w, 0, 0);
}
int main(void)
{
int r0[] = { 2, 4, 7 };
int r1[] = { 6, 5, 4 };
int *a0[3] = { r0, r1 };
int *a1[3] = { r0, r0 };
struct coord find0 = find_odd_not_7(a0, 2, 3);
struct coord find1 = find_odd_not_7(a1, 2, 3);
printf("find0 = { .r = %d, .c = %d }\n", find0.r, find0.c);
printf("find1 = { .r = %d, .c = %d }\n", find1.r, find1.c);
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-04 23:41 +0000 |
| Message-ID | <20210104152650.243@kylheku.com> |
| In reply to | #158160 |
On 2021-01-04, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> However, in regardless of being able to understanding the
> tail-call-based program, it's possible to make behavior-preserving
> changes to its source code with confidence, based on reasoning like
> manually inlining calls according to sound substitution principles, and
> elimination of unused parameters.
I did that now. I inlined some of the intermediate functions and
eliminated unnecessary condition testing arising from that. I also
eliminated as many unused parameters as I could. I also folded two
cases in the body function into one case, because they make the same
tail call.
This was a mechanical procedure, not requiring the understanding of the
entire program, only making local semantics-preserving changes.
The resulting program is quite a bit simpler.
So, in summary,
1. I wrote a program containing a subroutine that scanned through a
vector of arrays of integers using nested for loops, with conditions
requiring a continue in the inner loop, or a possible double break.
2. I converted the program manually from using for loops, break
and continue into a goto graph.
3. I converted the goto graph into a program using a number of
funtions which tail-call each other.
4. I passed over that program, making several kinds of
semantics-preserving reductions, which were easy to do, requiring
only local reasoning.
The resulting program can be turned back into a "tighter" goto graph,
which makes the whole technique useful even if a tail call version isn't
deployed.
#include <stdio.h>
struct coord { int r, c; };
static struct coord out(int r, int c);
static struct coord body(int **a, size_t h, size_t w, int r, int c);
static struct coord itop(int **a, size_t h, size_t w, int r, int c);
static struct coord top(int **a, size_t h, size_t w, int r);
static struct coord find_odd_not_7(int **a, size_t h, size_t w);
struct coord top(int **a, size_t h, size_t w, int r)
{
return (r >= h)
? out(-1, -1)
: itop(a, h, w, r, 0);
}
struct coord itop(int **a, size_t h, size_t w, int r, int c)
{
return (c >= w) ? top(a, h, w, r + 1)
: body(a, h, w, r, c);
}
struct coord body(int **a, size_t h, size_t w, int r, int c)
{
int v = a[r][c];
return v != 7 && v % 2 != 0 ? out(r, c)
: itop(a, h, w, r, c + 1);
}
struct coord out(int r, int c)
{
return (struct coord) { r, c };
}
struct coord find_odd_not_7(int **a, size_t h, size_t w)
{
return top(a, h, w, 0);
}
int main(void)
{
int r0[] = { 2, 4, 7 };
int r1[] = { 6, 5, 4 };
int *a0[3] = { r0, r1 };
int *a1[3] = { r0, r0 };
struct coord find0 = find_odd_not_7(a0, 2, 3);
struct coord find1 = find_odd_not_7(a1, 2, 3);
printf("find0 = { .r = %d, .c = %d }\n", find0.r, find0.c);
printf("find1 = { .r = %d, .c = %d }\n", find1.r, find1.c);
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 16:39 +0000 |
| Message-ID | <20201205083810.0@kylheku.com> |
| In reply to | #156943 |
On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > as it's sensible. Use no 'goto' statements. Limit function > bodies to no more than 25 lines. How about versions, A and B, of this exercise: A - Use no goto statements. B - Use nothing but goto statements (and essential function calls). -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 16:58 +0000 |
| Message-ID | <20201205085002.243@kylheku.com> |
| In reply to | #156946 |
On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> as it's sensible. Use no 'goto' statements. Limit function
>> bodies to no more than 25 lines.
>
> How about versions, A and B, of this exercise:
>
> A - Use no goto statements.
>
> B - Use nothing but goto statements (and essential function calls).
B attempt. Obviously, this flouts the 25 line rule which makes more
sense for A solutions.
Notes: I cranked this out almost as fast as I can type.
All the time I was thinking, wow this is easy! I'm no wasting any brain
cycles on 'how do I shoehorn this obvious flowchart into control
structures?'"
Furthermore, my code compiled the first time with no diagnostics under
gcc -W -Wall -ansi -pedantic and had only one obvious flaw at that time:
it completely deleted /*..*/ comments. I fixed that by adding the code
to output a space character. I will read and test it more carefully to
find any other problems.
I have to say, if you're under extreme time pressure to get something
working with minimal debugging effort, consider using nothing but goto.
Whether the resulting code is easy to understand may be another story.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int ch;
start:
ch = getchar();
if (ch == EOF)
goto end;
if (ch == '/')
goto slash;
outstart:
putchar(ch);
goto start;
slash:
ch = getchar();
if (ch == EOF)
goto end;
if (ch == '*')
goto slashstar;
if (ch == '/')
goto slashslash;
goto outstart;
slashstar:
ch = getchar();
if (ch == EOF)
goto badend;
if (ch == '*')
goto maybeend;
goto slashstar;
maybeend:
ch = getchar();
if (ch == EOF)
goto badend;
if (ch == '/') {
putchar(' ');
goto start;
}
goto slashstar;
slashslash:
ch = getchar();
if (ch == EOF)
goto badend;
if (ch == '\n')
goto outstart;
goto slashslash;
end:
return EXIT_SUCCESS;
badend:
return EXIT_FAILURE;
}
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 17:08 +0000 |
| Message-ID | <20201205085850.754@kylheku.com> |
| In reply to | #156948 |
On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
>> On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> as it's sensible. Use no 'goto' statements. Limit function
>>> bodies to no more than 25 lines.
>>
>> How about versions, A and B, of this exercise:
>>
>> A - Use no goto statements.
>>
>> B - Use nothing but goto statements (and essential function calls).
>
> B attempt. Obviously, this flouts the 25 line rule which makes more
> sense for A solutions.
>
> Notes: I cranked this out almost as fast as I can type.
>
> All the time I was thinking, wow this is easy! I'm no wasting any brain
> cycles on 'how do I shoehorn this obvious flowchart into control
> structures?'"
>
> Furthermore, my code compiled the first time with no diagnostics under
> gcc -W -Wall -ansi -pedantic and had only one obvious flaw at that time:
> it completely deleted /*..*/ comments. I fixed that by adding the code
> to output a space character. I will read and test it more carefully to
> find any other problems.
Next less obvious flaw: there is a case where the machine has to output a slash
which turned out not to be the start of a comment. to be a comment. I had it
in the back of my mind when I was coding, but in the end forgot to add the
logic.
The thought occured while I was coding the goto which jumps to the slash label.
"When I code the recognizer for the comment start sequence, either /* or
//, if that doesn't match on the second character, it has to output the slash
and then the mismatching character." But when it came time to code the slash
block, I neglected to do that, being so carried away with how easy it is
to code with nothing but goto that I could hardly pause to think any more.
Patch:
diff --git a/comments.c b/comments.c
index ad648b4..07374f5 100644
--- a/comments.c
+++ b/comments.c
@@ -23,6 +23,7 @@ int main(void)
goto slashstar;
if (ch == '/')
goto slashslash;
+ putchar('/');
goto outstart;
slashstar:
Complete code:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int ch;
start:
ch = getchar();
if (ch == EOF)
goto end;
if (ch == '/')
goto slash;
outstart:
putchar(ch);
goto start;
slash:
ch = getchar();
if (ch == EOF)
goto end;
if (ch == '*')
goto slashstar;
if (ch == '/')
goto slashslash;
putchar('/');
goto outstart;
slashstar:
ch = getchar();
if (ch == EOF)
goto badend;
if (ch == '*')
goto maybeend;
goto slashstar;
maybeend:
ch = getchar();
if (ch == EOF)
goto badend;
if (ch == '/') {
putchar(' ');
goto start;
}
goto slashstar;
slashslash:
ch = getchar();
if (ch == EOF)
goto badend;
if (ch == '\n')
goto outstart;
goto slashslash;
end:
return EXIT_SUCCESS;
badend:
return EXIT_FAILURE;
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-05 17:11 +0000 |
| Message-ID | <xbPyH.263214$qLy7.132437@fx45.ams4> |
| In reply to | #156948 |
On 05/12/2020 16:58, Kaz Kylheku wrote:
> On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
>> On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> as it's sensible. Use no 'goto' statements. Limit function
>>> bodies to no more than 25 lines.
>>
>> How about versions, A and B, of this exercise:
>>
>> A - Use no goto statements.
>>
>> B - Use nothing but goto statements (and essential function calls).
>
> B attempt. Obviously, this flouts the 25 line rule which makes more
> sense for A solutions.
>
> Notes: I cranked this out almost as fast as I can type.
>
> All the time I was thinking, wow this is easy! I'm no wasting any brain
> cycles on 'how do I shoehorn this obvious flowchart into control
> structures?'"
>
> Furthermore, my code compiled the first time with no diagnostics under
> gcc -W -Wall -ansi -pedantic and had only one obvious flaw at that time:
> it completely deleted /*..*/ comments. I fixed that by adding the code
> to output a space character. I will read and test it more carefully to
> find any other problems.
>
> I have to say, if you're under extreme time pressure to get something
> working with minimal debugging effort, consider using nothing but goto.
>
> Whether the resulting code is easy to understand may be another story.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> int ch;
>
> start:
> ch = getchar();
> if (ch == EOF)
> goto end;
> if (ch == '/')
> goto slash;
> outstart:
> putchar(ch);
> goto start;
>
> slash:
> ch = getchar();
> if (ch == EOF)
> goto end;
> if (ch == '*')
> goto slashstar;
> if (ch == '/')
> goto slashslash;
> goto outstart;
>
> slashstar:
> ch = getchar();
> if (ch == EOF)
> goto badend;
> if (ch == '*')
> goto maybeend;
> goto slashstar;
>
> maybeend:
> ch = getchar();
> if (ch == EOF)
> goto badend;
> if (ch == '/') {
> putchar(' ');
> goto start;
> }
> goto slashstar;
>
> slashslash:
> ch = getchar();
> if (ch == EOF)
> goto badend;
> if (ch == '\n')
> goto outstart;
> goto slashslash;
>
> end:
> return EXIT_SUCCESS;
>
> badend:
> return EXIT_FAILURE;
> }
>
Did you test it? (I assume the result needs to compile as the same program.)
This turns a/b into ab.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 17:24 +0000 |
| Message-ID | <20201205092202.175@kylheku.com> |
| In reply to | #156950 |
On 2020-12-05, Bart <bc@freeuk.com> wrote:
> On 05/12/2020 16:58, Kaz Kylheku wrote:
>> On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
>>> On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>> as it's sensible. Use no 'goto' statements. Limit function
>>>> bodies to no more than 25 lines.
>>>
>>> How about versions, A and B, of this exercise:
>>>
>>> A - Use no goto statements.
>>>
>>> B - Use nothing but goto statements (and essential function calls).
>>
>> B attempt. Obviously, this flouts the 25 line rule which makes more
>> sense for A solutions.
>>
>> Notes: I cranked this out almost as fast as I can type.
>>
>> All the time I was thinking, wow this is easy! I'm no wasting any brain
>> cycles on 'how do I shoehorn this obvious flowchart into control
>> structures?'"
>>
>> Furthermore, my code compiled the first time with no diagnostics under
>> gcc -W -Wall -ansi -pedantic and had only one obvious flaw at that time:
>> it completely deleted /*..*/ comments. I fixed that by adding the code
>> to output a space character. I will read and test it more carefully to
>> find any other problems.
>>
>> I have to say, if you're under extreme time pressure to get something
>> working with minimal debugging effort, consider using nothing but goto.
>>
>> Whether the resulting code is easy to understand may be another story.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>> int ch;
>>
>> start:
>> ch = getchar();
>> if (ch == EOF)
>> goto end;
>> if (ch == '/')
>> goto slash;
>> outstart:
>> putchar(ch);
>> goto start;
>>
>> slash:
>> ch = getchar();
>> if (ch == EOF)
>> goto end;
>> if (ch == '*')
>> goto slashstar;
>> if (ch == '/')
>> goto slashslash;
>> goto outstart;
>>
>> slashstar:
>> ch = getchar();
>> if (ch == EOF)
>> goto badend;
>> if (ch == '*')
>> goto maybeend;
>> goto slashstar;
>>
>> maybeend:
>> ch = getchar();
>> if (ch == EOF)
>> goto badend;
>> if (ch == '/') {
>> putchar(' ');
>> goto start;
>> }
>> goto slashstar;
>>
>> slashslash:
>> ch = getchar();
>> if (ch == EOF)
>> goto badend;
>> if (ch == '\n')
>> goto outstart;
>> goto slashslash;
>>
>> end:
>> return EXIT_SUCCESS;
>>
>> badend:
>> return EXIT_FAILURE;
>> }
>>
>
> Did you test it? (I assume the result needs to compile as the same program.)
I caught that one; see my other post.
I have a question: do we need to recognize backslash line continuations
inside // comments, so that such a comment line can be continued past
a newline?
I didn't do it; I will check the standard either. No time now.
I will check the standard later.
> This turns a/b into ab.
Now did you know that from reading the code, or empirically from running it?
Because if you know that from the code, that's a point in favor of the
readability of goto. :)
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-05 17:52 +0000 |
| Message-ID | <7OPyH.39686$JT57.37071@fx31.ams4> |
| In reply to | #156951 |
On 05/12/2020 17:24, Kaz Kylheku wrote: >> Did you test it? (I assume the result needs to compile as the same program.) > > I caught that one; see my other post. > > I have a question: do we need to recognize backslash line continuations > inside // comments, so that such a comment line can be continued past > a newline? Presumably the answer is yes, otherwise the new program will compile/behave differently. > I didn't do it; I will check the standard either. No time now. > > I will check the standard later. > >> This turns a/b into ab. > > Now did you know that from reading the code, or empirically from running it? > > Because if you know that from the code, that's a point in favor of the > readability of goto. :) > I just ran the code. That's how I usually debug. After all, the program might work first time, so that saves some trouble! As to readability, your goto version I actually found somewhat more readability than my clunky attempt that used state variables. That was written in a script language, and worked string to string (and was about 48 non-blank lines; I ignored the 25-line limit). Then when I was going to port it to C using stdin/stdout, I found my code had to overwrite the first "/" of "//" or "/*" that has already been output, which I decided was to fiddly to bother with in C [my C spec would not have stipulated stdin/stdout]. Anyway my attempts in either language would not have used goto; wasn't that the point of the challenge? Not sure why that was proposed, but I suspect Tim will post a compact solution that relies on gotos.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 18:30 +0000 |
| Message-ID | <20201205102920.798@kylheku.com> |
| In reply to | #156954 |
On 2020-12-05, Bart <bc@freeuk.com> wrote: > On 05/12/2020 17:24, Kaz Kylheku wrote: > >>> Did you test it? (I assume the result needs to compile as the same program.) >> >> I caught that one; see my other post. >> >> I have a question: do we need to recognize backslash line continuations >> inside // comments, so that such a comment line can be continued past >> a newline? > > Presumably the answer is yes, otherwise the new program will > compile/behave differently. The answer is yes, because backslash continuations (folding logical lines into physical lines) is done in an earlier translation phase relative to processing comments. That's how I thought I remembered it; I just checked.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-05 19:56 +0000 |
| Message-ID | <HBRyH.108884$9J69.31805@fx21.ams4> |
| In reply to | #156954 |
On 05/12/2020 17:52, Bart wrote:
> On 05/12/2020 17:24, Kaz Kylheku wrote:
>
>>> Did you test it? (I assume the result needs to compile as the same
>>> program.)
>>
>> I caught that one; see my other post.
>>
>> I have a question: do we need to recognize backslash line continuations
>> inside // comments, so that such a comment line can be continued past
>> a newline?
>
> Presumably the answer is yes, otherwise the new program will
> compile/behave differently.
>
>> I didn't do it; I will check the standard either. No time now.
>>
>> I will check the standard later.
>>
>>> This turns a/b into ab.
>>
>> Now did you know that from reading the code, or empirically from
>> running it?
>>
>> Because if you know that from the code, that's a point in favor of the
>> readability of goto. :)
>>
>
> I just ran the code. That's how I usually debug. After all, the program
> might work first time, so that saves some trouble!
>
> As to readability, your goto version I actually found somewhat more
> readability than my clunky attempt that used state variables.
>
> That was written in a script language, and worked string to string (and
> was about 48 non-blank lines; I ignored the 25-line limit).
>
> Then when I was going to port it to C using stdin/stdout, I found my
> code had to overwrite the first "/" of "//" or "/*" that has already
> been output, which I decided was to fiddly to bother with in C [my C
> spec would not have stipulated stdin/stdout].
FWIW I completed it and the whole program is given below.
It doesn't bother with possible comment delimiters inside '...'
literals; those are only possible with multi-character constants and
those I understand are implementation-defined. In any case it would just
be one more state on top of the 4 already handled.
Comments are entirely converted to whitespace where necessary, but
preserving newlines.
(Tested on the 219Kloc sqlite3.c plus, since the latter mostly uses
/*...*/ comments, a couple of smaller programs that use //. The new .c
files compile to the same .exe or near-identical .obj, since .obj files
include the file name which is different.)
-------------------------------------------------
#include <stdio.h>
int lastoutc=0;
void outchar(char c) {
if (lastoutc) putchar(lastoutc);
lastoutc=c;
}
int main(void) {
int inlinecomment=0;
int inblockcomment=0;
int instring=0;
int c,lastc=0;
while ((c=getchar())!=EOF) {
if (inlinecomment) {
if (c==13 || c==10) {
if (lastc!='\\') {
inlinecomment=0;
}
outchar(c);
} else {
outchar(' ');
}
} else if (inblockcomment) {
if (lastc=='*' && c=='/') {
inblockcomment=0;
}
outchar((c==13 || c==10?c:' '));
} else if (instring) {
if (c=='"') instring=0;
outchar(c);
} else {
if (lastc=='/' && c=='*') {
inblockcomment=1;
lastoutc=' ';
outchar(' ');
} else if (lastc=='/' && c=='/') {
inlinecomment=1;
lastoutc=' ';
outchar(' ');
} else if (c=='"') {
instring=1;
outchar(c);
} else {
outchar(c);
}
}
lastc=c;
}
outchar(0);
}
-------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-06 14:51 +0000 |
| Message-ID | <Zd6zH.246117$ijZ9.26751@fx05.ams4> |
| In reply to | #156962 |
On 05/12/2020 19:56, Bart wrote:
> It doesn't bother with possible comment delimiters inside '...'
> literals; those are only possible with multi-character constants and
> those I understand are implementation-defined. In any case it would just
> be one more state on top of the 4 already handled.
> } else if (instring) {
> if (c=='"') instring=0;
> outchar(c);
I didn't allow for embedded " characters inside strings, as I'd
forgotten they were allowed.
That needs to be fixed, I believe by changing that middle line to:
if (c=='"' && lastc!='\\') instring=0;
As it is, it will go wrong with strings such as:
"abc\"/*comment*/\"def"
and probably worse with only one embedded ".
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-05 17:49 +0000 |
| Message-ID | <87zh2sqh2l.fsf@bsb.me.uk> |
| In reply to | #156948 |
Kaz Kylheku <563-365-8930@kylheku.com> writes: > On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote: >> On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> as it's sensible. Use no 'goto' statements. Limit function >>> bodies to no more than 25 lines. >> >> How about versions, A and B, of this exercise: >> >> A - Use no goto statements. >> >> B - Use nothing but goto statements (and essential function calls). > > B attempt. Obviously, this flouts the 25 line rule which makes more > sense for A solutions. > > Notes: I cranked this out almost as fast as I can type. Quite a lot of bugs, though! <cut code> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 18:34 +0000 |
| Message-ID | <20201205103251.785@kylheku.com> |
| In reply to | #156953 |
On 2020-12-05, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Kaz Kylheku <563-365-8930@kylheku.com> writes: > >> On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote: >>> On 2020-12-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> as it's sensible. Use no 'goto' statements. Limit function >>>> bodies to no more than 25 lines. >>> >>> How about versions, A and B, of this exercise: >>> >>> A - Use no goto statements. >>> >>> B - Use nothing but goto statements (and essential function calls). >> >> B attempt. Obviously, this flouts the 25 line rule which makes more >> sense for A solutions. >> >> Notes: I cranked this out almost as fast as I can type. > > Quite a lot of bugs, though! Ah yes, slapforehead. It's completely broken. We have to properly tokenize C code when parsing for comments, of course, doh. Or at least semi-properly. Otherwise we will do stupid things, like recognize /* in the middle of string and character constants. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-05 19:40 +0100 |
| Message-ID | <rqgk7n$56m$1@dont-email.me> |
| In reply to | #156948 |
/*, */ and // might be part of a string, and string-delimiters might be part of escape-sequences, so this isn't as easy as you think.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 18:47 +0000 |
| Message-ID | <20201205104248.307@kylheku.com> |
| In reply to | #156959 |
On 2020-12-05, Bonita Montero <Bonita.Montero@gmail.com> wrote: > /*, */ and // might be part of a string, and string-delimiters might > be part of escape-sequences, so this isn't as easy as you think. Fortunately, I beat you to acknowledging this essential requirement in my reply to Ben. :) Yes, it is completely broken. Comments are recognized in the context of tokenization. They are a kind of token pattern, effectively, whose semantic action is to be deleted. We have to at least recognize string and character constants (which could be multi-byte: 'ab\xff'. For the purpose of the task, we might be able to get away without classifying valid versus invalid escape sequences. So that is to say, for instance, it could be an acceptable requirement if the program passes through a broken literal like "abc\zdef", rather than misbehaving or bailing. Sometimes implementations have extensions in this area, so it's not even such a good idea to be too rigid in a comment-removing program. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-05 23:19 +0000 |
| Message-ID | <20201205151302.394@kylheku.com> |
| In reply to | #156960 |
On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> On 2020-12-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> /*, */ and // might be part of a string, and string-delimiters might
>> be part of escape-sequences, so this isn't as easy as you think.
>
> Fortunately, I beat you to acknowledging this essential requirement
> in my reply to Ben. :)
>
> Yes, it is completely broken.
>
> Comments are recognized in the context of tokenization. They are a kind
> of token pattern, effectively, whose semantic action is to be deleted.
Improved version which has hacky quote recognition and also recognition
of backslash-newline continuations.
It handles cases like:
int x = /\
/ this is a comment
42;
where a continuation occurs in the middle of he // sequence.
Because the continuation could occur anywhere, it would complicate the
transition graph to try to handle it in a single stage. So I broke away
from the pure goto model.
Instead of getchar being called directly, a function called s2getc
is called "stage 2 getchar". This routine eats the continuations and
returns a logical character. A call to ungetc is required when it
gets a backslash not followed by a newline, in order to push back that
second character and return the backslash.
#include <stdio.h>
#include <stdlib.h>
/* "get char from translation stage 2",
* which recognizes physical lines and folds them into
* logical lines
*/
int s2getc(void)
{
int ch;
entry:
ch = getchar();
if (ch != '\\')
goto end;
ch = getchar();
if (ch == '\n')
goto entry;
if (ch == EOF) {
ch = '\\';
goto end;
}
ungetc(ch, stdin);
ch = '\\';
end:
return ch;
}
int main(void)
{
int ch;
int qc;
start:
ch = getchar();
if (ch == EOF)
goto end;
if (ch == '/')
goto slash;
if (ch == '"' || ch == '\'') {
qc = ch;
goto quote;
}
outstart:
putchar(ch);
goto start;
slash:
ch = s2getc();
if (ch == EOF)
goto end;
if (ch == '*')
goto slashstar;
if (ch == '/')
goto slashslash;
putchar('/');
goto outstart;
slashstar:
ch = s2getc();
if (ch == EOF)
goto badend;
if (ch == '*')
goto maybeend;
goto slashstar;
maybeend:
ch = s2getc();
if (ch == EOF)
goto badend;
if (ch == '/') {
putchar(' ');
goto start;
}
goto slashstar;
slashslash:
ch = s2getc();
if (ch == EOF)
goto badend;
if (ch == '\n')
goto outstart;
goto slashslash;
quote:
putchar(ch);
ch = s2getc();
if (ch == EOF)
goto badend;
if (ch == qc)
goto outstart;
if (ch == '\\')
goto bsinquote;
goto quote;
bsinquote:
putchar(ch);
ch = s2getc();
if (ch == EOF)
goto badend;
goto quote;
end:
return EXIT_SUCCESS;
badend:
return EXIT_FAILURE;
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-05 23:56 +0000 |
| Message-ID | <W6VyH.146513$bZF7.108238@fx30.ams4> |
| In reply to | #156967 |
On 05/12/2020 23:19, Kaz Kylheku wrote:
> On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
>> On 2020-12-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> /*, */ and // might be part of a string, and string-delimiters might
>>> be part of escape-sequences, so this isn't as easy as you think.
>>
>> Fortunately, I beat you to acknowledging this essential requirement
>> in my reply to Ben. :)
>>
>> Yes, it is completely broken.
>>
>> Comments are recognized in the context of tokenization. They are a kind
>> of token pattern, effectively, whose semantic action is to be deleted.
>
> Improved version which has hacky quote recognition and also recognition
> of backslash-newline continuations.
>
> It handles cases like:
>
> int x = /\
> / this is a comment
> 42;
When you talked about backslash in the middle of a // comment, I thought
you meant at the end of the comment, not literally in the middle of //!
Such a break /is/ allowed in C, and can actually be in the middle of
anything:
i\
n\
t m\
a\
i\
n void() {}
It's something I only recently learnt about but decided not to implement
[in my compiler].
A \ at the end of a // comment like this:
puts("A"); // one two\
puts("B");
puts("C");
continues the comment onto the next line, but not if it is in the middle
of the comment:
puts("A"); // one two\three
>
> /* "get char from translation stage 2",
> * which recognizes physical lines and folds them into
> * logical lines
> */
> int s2getc(void)
> {
> int ch;
<snip>
This has a problem with this input (line breaks may be inserted by
newsreader, but each /*..*/ comment was on one line):
-------------------------------------------
#define TKFLG_DONTFOLD 0x100 /* Omit constant folding
optimizations */
/************** End of parse.h
***********************************************/
/************** Continuing where we left off in sqliteInt.h
******************/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <stddef.h>
-------------------------------------------
The output is:
-------------------------------------------
#define TKFLG_DONTFOLD 0x100
-------------------------------------------
The #includes are elided.
(The original code is in the 219000-line version of the amalgamated
sqlite3.c, lines 13472 to 13481. In the full version, translation
continues after this comment:
/*
** Use a macro to replace memcpy() if compiled with SQLITE_INLINE_MEMCPY.
** This allows better measurements of where memcpy() is used when running
** cachegrind. But this macro version of memcpy() is very slow so it
** should not be used in production. This is a performance measurement
** hack only.
*/
#ifdef SQLITE_INLINE_MEMCPY
)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-08 02:26 +0000 |
| Message-ID | <20201207182512.515@kylheku.com> |
| In reply to | #156967 |
On 2020-12-05, Kaz Kylheku <563-365-8930@kylheku.com> wrote:
> int main(void)
> {
> int ch;
> int qc;
>
> start:
> ch = getchar();
This is a bug; this getchar should have been replaced by s2getc, like
the others.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-08 16:04 +0300 |
| Message-ID | <20201208160437.44860a2351f9f468bd03f65f@gmail.com> |
| In reply to | #157074 |
Kaz Kylheku: > This is a bug; For the benefit of whoever may be collecting the entries, I ask you to post full updated versions of your solutions, in addition to, indicating bugs. It is much easier to copy- paste a program form the newsreader than manually to apply the indicated changes the previous copy, which is also error-prone. -- Anton Shepelev
[toc] | [prev] | [next] | [standalone]
Page 2 of 20 — ← Prev page 1 [2] 3 4 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web