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 14 of 20 — ← Prev page 1 … 12 13 [14] 15 16 … 20 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-07 02:41 -0800 |
| Message-ID | <865z49qba3.fsf@linuxsc.com> |
| In reply to | #157949 |
Bart <bc@freeuk.com> writes: > On 31/12/2020 15:16, Kent Dickey wrote: [...] >> I think it makes sense to handle malformed input, since "cc -E" >> does. No matter how badly formed the input is, it does not stop >> on error and produces something. I think my rephrased rules >> capture the rough "cc -E" error handling (where unterminated >> strings get terminated at non-escaped newline). > > This is my view. We're not writing a full C compiler or even a C > tokeniser. Only a program to remove comments. > > If the program is malformed, or not C, or is just text from > Shakespeare, should not be the concern of this translator. > > Brief instructions that input should be well-formed C (pass it > through a compiler first if necessary) should suffice, if this is > to be a real tool. Kent is saying the program should handle malformed input. You are saying that the program should say the input should be well-formed C. It can't be both: either the program handles input that is not well formed, or it doesn't. If it does, there is no reason for program documentation to say the input should be well formed. > But the challenge is apparently not about writing a practical tool > anyway, since the 'model' implementation relies on a compiler > eliminating recursion in order to produce a version that will not > crash after 1000 or 2000 lines. Several comments here. One, I said my reference implementation, not model implementation. I meant only that it would be used for comparison of how input was processed by other entries. I'm not suggesting, nor did I previously suggest, that this program be used as a model for how other people should write their programs. (This trick is one Bart often uses - slightly misquote someone to change the meaning of what was said.) Two, the program I posted works fine in the environment in which it is meant to operate (and that environment is quite common btw). Furthermore I think it's reasonable to expect people to avoid using substandard compilers, and not be stupid about choosing optimization settings. Normally even simple programs like this would be distributed with a Makefile or something similar, which would ensure a reasonable behavior. Three, just because your own compiler is too dumb to generate reasonable code doesn't mean everyone should code to that level. Four, none of the programs you posted (including the one where only a change from the previous version was given) produce correct output with _any_ C compiler. So I think are hardly one to be criticizing.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-31 13:01 -0800 |
| Message-ID | <f802c1a6-27da-47aa-a8c8-e14c072e3a3fn@googlegroups.com> |
| In reply to | #157947 |
On Thursday, 31 December 2020 at 15:16:28 UTC, Kent Dickey wrote: > In article <20201231165401.0079...@gmail.com>, > Anton Shepelev <anto...@gmail.com> wrote: > >Tim Rentsch: > > > >> It looks like we are wrapping up. > > > >I am still going to post a version that handles unterminated > >literals and block comments. I don't think I want to check > >the correctness of char literals, i.e. that they contain > >exactly one character, as that does not seem to be > >absolutely required and would mean a mechanical extension of > >my state machine. > > > >-- > >() ascii ribbon campaign -- against html e-mail > >/\ http://preview.tinyurl.com/qcy6mjc [archived] > I think it makes sense to handle malformed input, since "cc -E" does. No > matter how badly formed the input is, it does not stop on error and produces > something. I think my rephrased rules capture the rough "cc -E" error > handling (where unterminated strings get terminated at non-escaped newline). > You don't want to produced syntactically valid C output when passed syntactically invalid C input. Otherwise you can have code which works when passed through the comment stripper, and mysteriously fails when an attempt is made to compile the original source.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-31 14:15 -0800 |
| Message-ID | <87v9ch7hcq.fsf@nosuchdomain.example.com> |
| In reply to | #157947 |
kegs@provalid.com (Kent Dickey) writes:
[...]
> I think it makes sense to handle malformed input, since "cc -E" does. No
> matter how badly formed the input is, it does not stop on error and produces
> something. I think my rephrased rules capture the rough "cc -E" error
> handling (where unterminated strings get terminated at non-escaped newline).
>
> However, "cc -E" does not enforce other C rules. In fact, it's best if it
> doesn't. Mac C-like languages have multi-character constant support, so
> int c = 'abcd'; is defined and supported (they use this as parameters for
> some system library calls, where it's the value 0x61626364).
>
> More languages than just C use the cpp.
Standard C supports multi-character constants like 'abcd'.
They're of type int with an implementation-defined value.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-01 08:03 -0800 |
| Message-ID | <86ft3ktzjt.fsf@linuxsc.com> |
| In reply to | #157947 |
kegs@provalid.com (Kent Dickey) writes: > In article <20201231165401.0079f4d95a8c7c746de42e91@gmail.com>, > Anton Shepelev <anton.txt@gmail.com> wrote: > >> Tim Rentsch: >> >>> It looks like we are wrapping up. >> >> I am still going to post a version that handles unterminated >> literals and block comments. I don't think I want to check >> the correctness of char literals, i.e. that they contain >> exactly one character, as that does not seem to be >> absolutely required and would mean a mechanical extension of >> my state machine. > > I think it makes sense to handle malformed input, since "cc -E" > does. No matter how badly formed the input is, it does not stop > on error and produces something. I think my rephrased rules > capture the rough "cc -E" error handling (where unterminated > strings get terminated at non-escaped newline). My problem statement deliberately allowed the possibility of simply stopping on inputs that are not lexically well-formed. In most cases it's a good policy to continue processing even in the face of input that is not well formed, and that is a reasonable choice here (assuming of course the downstream processing does something sensible and not cause more damage than help). Just for this exercise however that was not meant to be required. > However, "cc -E" does not enforce other C rules. In fact, it's > best if it doesn't. Mac C-like languages have multi-character > constant support, so int c = 'abcd'; is defined and supported > (they use this as parameters for some system library calls, where > it's the value 0x61626364). Note that arbitrarily long character constants are well formed as far as C's lexical grammar is concerned, so for purposes of the exercise they must be admitted and handled correctly.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-01 07:42 -0800 |
| Message-ID | <86k0swu0ix.fsf@linuxsc.com> |
| In reply to | #157940 |
Anton Shepelev <anton.txt@gmail.com> writes: > Tim Rentsch: > >> It looks like we are wrapping up. > > I am still going to post a version that handles unterminated > literals and block comments. I expect to continue collecting posted versions for the foreseeable future (with the disclaimer that I am not able to see very far into the future). > I don't think I want to check > the correctness of char literals, i.e. that they contain > exactly one character, as that does not seem to be > absolutely required and would mean a mechanical extension of > my state machine. In section 6.4.4.4, the C standard gives that part of C's lexical grammar that pertains to character constants. The grammar rules given allow an arbitrary number of "c-char" in between the enclosing single quotes, and that definition is what these decommenting programs should accept. More generally, they should accept any lexically well-formed input, and that includes arbitrarily long character constants.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2021-01-02 21:59 +0300 |
| Message-ID | <20210102215921.70d75313b9e3a327ca824630@gmail.com> |
| In reply to | #158076 |
Tim Rentsch: > In section 6.4.4.4, the C standard gives that part of C's > lexical grammar that pertains to character constants. The > grammar rules given allow an arbitrary number of "c-char" > in between the enclosing single quotes, and that > definition is what these decommenting programs should > accept. More generally, they should accept any lexically > well-formed input, and that includes arbitrarily long > character constants. Thanks for the clarification, Tim. The only incorrect character constant seems to be an empty one -- '' ? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-02 14:52 -0500 |
| Message-ID | <E94IH.69702$kZ1.14581@fx37.iad> |
| In reply to | #158102 |
On 1/2/21 1:59 PM, Anton Shepelev wrote: > Tim Rentsch: > >> In section 6.4.4.4, the C standard gives that part of C's >> lexical grammar that pertains to character constants. The >> grammar rules given allow an arbitrary number of "c-char" >> in between the enclosing single quotes, and that >> definition is what these decommenting programs should >> accept. More generally, they should accept any lexically >> well-formed input, and that includes arbitrarily long >> character constants. > > Thanks for the clarification, Tim. The only incorrect > character constant seems to be an empty one -- '' ? > I believe the empty character constant is defined as a constraint violation. I also believe that multiple character constants are only optionally acceptable, A compiler would still be conforming to reject all multiple character character constants (but also still be conforming to accept all multiple character character constants).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-01-02 12:30 -0800 |
| Message-ID | <1ee8eda4-75a0-4075-8747-db5e2f07515dn@googlegroups.com> |
| In reply to | #158108 |
On Saturday, 2 January 2021 at 19:52:16 UTC, Richard Damon wrote: > On 1/2/21 1:59 PM, Anton Shepelev wrote: > > Tim Rentsch: > > > >> In section 6.4.4.4, the C standard gives that part of C's > >> lexical grammar that pertains to character constants. The > >> grammar rules given allow an arbitrary number of "c-char" > >> in between the enclosing single quotes, and that > >> definition is what these decommenting programs should > >> accept. More generally, they should accept any lexically > >> well-formed input, and that includes arbitrarily long > >> character constants. > > > > Thanks for the clarification, Tim. The only incorrect > > character constant seems to be an empty one -- '' ? > > > I believe the empty character constant is defined as a constraint violation. > From appendix A. (6.4.4.4)character-constant: 'c-char-sequence'L'c-char-sequence'u'c-char-sequence'U'c-char-sequence' (6.4.4.4)c-char-sequence: c-charc-char-sequence c-char (6.4.4.4)c-char: any member of the source character set except the single-quote', backslash\, or new-line characterescape-sequence So it's just a normal grammar rule. c-char-sequence can't be empty.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-02 18:17 -0500 |
| Message-ID | <rsquur$r9a$1@dont-email.me> |
| In reply to | #158108 |
On 1/2/21 2:52 PM, Richard Damon wrote: > On 1/2/21 1:59 PM, Anton Shepelev wrote: >> Tim Rentsch: >> >>> In section 6.4.4.4, the C standard gives that part of C's >>> lexical grammar that pertains to character constants. The >>> grammar rules given allow an arbitrary number of "c-char" >>> in between the enclosing single quotes, and that >>> definition is what these decommenting programs should >>> accept. More generally, they should accept any lexically >>> well-formed input, and that includes arbitrarily long >>> character constants. >> >> Thanks for the clarification, Tim. The only incorrect >> character constant seems to be an empty one -- '' ? >> > > I believe the empty character constant is defined as a constraint violation. No, it's a syntax error. > I also believe that multiple character constants are only optionally > acceptable, A compiler would still be conforming to reject all multiple > character character constants (but also still be conforming to accept > all multiple character character constants). "The value of an integer character constant containing more than one character (e.g., 'ab'), or containing a character or escape sequence that does not map to a single-byte execution character, is implementation-defined." (6.4.4.4p10). An implementation-defined value is an "unspecified value where each implementation documents how the choice is made" (3.19.1). An unspecified value is a "valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance" (3.19.3). An implementation is therefore required to map any multi-character character constant, regardless of length, to a valid value of type int. It is not free to reject such constructs. It's been argued that an implementation is free to assign a value to such a constant that is outside of the valid range for an int, which would make use of such a constant a constraint violation (6.4.4p3). As far as I can see, that claim directly violates 3.19.3 - but pointing that out failed to convince the person who made that claim.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-02 19:22 -0500 |
| Message-ID | <t78IH.52352$SY1.46320@fx38.iad> |
| In reply to | #158110 |
On 1/2/21 6:17 PM, James Kuyper wrote: > On 1/2/21 2:52 PM, Richard Damon wrote: >> On 1/2/21 1:59 PM, Anton Shepelev wrote: >>> Tim Rentsch: >>> >>>> In section 6.4.4.4, the C standard gives that part of C's >>>> lexical grammar that pertains to character constants. The >>>> grammar rules given allow an arbitrary number of "c-char" >>>> in between the enclosing single quotes, and that >>>> definition is what these decommenting programs should >>>> accept. More generally, they should accept any lexically >>>> well-formed input, and that includes arbitrarily long >>>> character constants. >>> >>> Thanks for the clarification, Tim. The only incorrect >>> character constant seems to be an empty one -- '' ? >>> >> >> I believe the empty character constant is defined as a constraint violation. > > No, it's a syntax error. > >> I also believe that multiple character constants are only optionally >> acceptable, A compiler would still be conforming to reject all multiple >> character character constants (but also still be conforming to accept >> all multiple character character constants). > > > "The value of an integer character constant containing more than one > character (e.g., 'ab'), or containing a character or escape sequence > that does not map to a single-byte execution character, is > implementation-defined." (6.4.4.4p10). > > An implementation-defined value is an "unspecified value where each > implementation documents how the choice is made" (3.19.1). > > An unspecified value is a "valid value of the relevant type where this > International Standard imposes no requirements on which value is chosen > in any instance" (3.19.3). > > An implementation is therefore required to map any multi-character > character constant, regardless of length, to a valid value of type int. > It is not free to reject such constructs. > > It's been argued that an implementation is free to assign a value to > such a constant that is outside of the valid range for an int, which > would make use of such a constant a constraint violation (6.4.4p3). As > far as I can see, that claim directly violates 3.19.3 - but pointing > that out failed to convince the person who made that claim. > I will admit I could have been wrong, and from the references it sounds like it isn't a constraint violation to provide an 'overly long' character constant. I do remember getting diagnostics for do this, but they could have been just warnings, and an implementation is allowed to issue a 'warning' for just about anything, it just can't reject the program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-01-02 17:48 -0800 |
| Message-ID | <87mtxq7pu7.fsf@nosuchdomain.example.com> |
| In reply to | #158110 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/2/21 2:52 PM, Richard Damon wrote:
>> On 1/2/21 1:59 PM, Anton Shepelev wrote:
>>> Tim Rentsch:
>>>
>>>> In section 6.4.4.4, the C standard gives that part of C's
>>>> lexical grammar that pertains to character constants. The
>>>> grammar rules given allow an arbitrary number of "c-char"
>>>> in between the enclosing single quotes, and that
>>>> definition is what these decommenting programs should
>>>> accept. More generally, they should accept any lexically
>>>> well-formed input, and that includes arbitrarily long
>>>> character constants.
>>>
>>> Thanks for the clarification, Tim. The only incorrect
>>> character constant seems to be an empty one -- '' ?
>>>
>>
>> I believe the empty character constant is defined as a constraint violation.
>
> No, it's a syntax error.
>
>> I also believe that multiple character constants are only optionally
>> acceptable, A compiler would still be conforming to reject all multiple
>> character character constants (but also still be conforming to accept
>> all multiple character character constants).
>
>
> "The value of an integer character constant containing more than one
> character (e.g., 'ab'), or containing a character or escape sequence
> that does not map to a single-byte execution character, is
> implementation-defined." (6.4.4.4p10).
>
> An implementation-defined value is an "unspecified value where each
> implementation documents how the choice is made" (3.19.1).
>
> An unspecified value is a "valid value of the relevant type where this
> International Standard imposes no requirements on which value is chosen
> in any instance" (3.19.3).
>
> An implementation is therefore required to map any multi-character
> character constant, regardless of length, to a valid value of type int.
> It is not free to reject such constructs.
>
> It's been argued that an implementation is free to assign a value to
> such a constant that is outside of the valid range for an int, which
> would make use of such a constant a constraint violation (6.4.4p3). As
> far as I can see, that claim directly violates 3.19.3 - but pointing
> that out failed to convince the person who made that claim.
I don't recall 3.19.3 being invoked last time this was brought up (which
of course doesn't mean that it wasn't.) I agree that a conforming
implementation must accept even very long character constants, as long
as they don't exceed the implementation's maximum line length. It
wouldn't bother me if the standard were changed to allow implementations
to reject such constants, but currently it doesn't.
N1570 6.4.4.4p10:
An integer character constant has type int. [...] The value of an
integer character constant containing more than one character (e.g.,
'ab'), or containing a character or escape sequence that does not
map to a single-byte execution character, is implementation-defined.
3.19.1 defines "implementation-defined value":
unspecified value where each implementation documents how the choice is
made
3.19.3 defines "unspecified value":
valid value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance
NOTE An unspecified value cannot be a trap representation.
It seems sufficiently obvious that the wording "The value ... is
implementation-defined" means that the definition of
"implementation-defined value" applies, and therefore that the value of,
for example, 'abcdefghijklmnopqrstuvwxyz' must be of type int, and must
be in the range INT_MIN to INT_MAX. A value outside that range, which
could trigger a constraint violation, would not be a "valid value".
(I note that gcc gets this right, issing a non-fatal warning with
"-std=c11 -pedantic-errors", and clang rejects even 'ab' the same
options.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-02 22:35 -0500 |
| Message-ID | <rsre24$a5t$1@dont-email.me> |
| In reply to | #158115 |
On 1/2/21 8:48 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >> "The value of an integer character constant containing more than one >> character (e.g., 'ab'), or containing a character or escape sequence >> that does not map to a single-byte execution character, is >> implementation-defined." (6.4.4.4p10). >> >> An implementation-defined value is an "unspecified value where each >> implementation documents how the choice is made" (3.19.1). >> >> An unspecified value is a "valid value of the relevant type where this >> International Standard imposes no requirements on which value is chosen >> in any instance" (3.19.3). >> >> An implementation is therefore required to map any multi-character >> character constant, regardless of length, to a valid value of type int. >> It is not free to reject such constructs. >> >> It's been argued that an implementation is free to assign a value to >> such a constant that is outside of the valid range for an int, which >> would make use of such a constant a constraint violation (6.4.4p3). As >> far as I can see, that claim directly violates 3.19.3 - but pointing >> that out failed to convince the person who made that claim. > > I don't recall 3.19.3 being invoked last time this was brought up (which > of course doesn't mean that it wasn't.) I cited it in my message on the thread "longer 'char literals' meaning in c" that had the header Date: Thu, 30 Apr 2020 18:36:09 -0400 I only provided the text, however - I didn't cite the section number, which is a break from my usual practice. On 2020-05-04 Tim Rentsch's posted a message objecting to that argument based upon a claim that there's a difference between "an implementation-defined value" and "a value that is implementation-defined". If such a distinction can be made, I admit that it would break that argument. However, I couldn't make heads or tails of his argument; It's not even clear to me what he claimed that distinction to be. He also, as is typical of him, dismissed those arguments by referring to the "laugh test" and labeling them "absurd" rather than actually addressing whatever fault it was that he found with them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-02 18:02 -0800 |
| Message-ID | <86y2hasrpt.fsf@linuxsc.com> |
| In reply to | #158102 |
Anton Shepelev <anton.txt@gmail.com> writes: > Tim Rentsch: > >> In section 6.4.4.4, the C standard gives that part of C's >> lexical grammar that pertains to character constants. The >> grammar rules given allow an arbitrary number of "c-char" >> in between the enclosing single quotes, and that >> definition is what these decommenting programs should >> accept. More generally, they should accept any lexically >> well-formed input, and that includes arbitrarily long >> character constants. > > Thanks for the clarification, Tim. The only incorrect > character constant seems to be an empty one -- '' ? In terms of lexical well-formedness, yes, I believe that's right. Let me say also that even though an empty character constant is not well formed as far as the C standard is concerned, I expect that any self-respecting de-commenting program would process it without complaint.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-01-03 00:42 -0800 |
| Message-ID | <87im8e76oo.fsf@nosuchdomain.example.com> |
| In reply to | #158117 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Anton Shepelev <anton.txt@gmail.com> writes:
>> Tim Rentsch:
>>> In section 6.4.4.4, the C standard gives that part of C's
>>> lexical grammar that pertains to character constants. The
>>> grammar rules given allow an arbitrary number of "c-char"
>>> in between the enclosing single quotes, and that
>>> definition is what these decommenting programs should
>>> accept. More generally, they should accept any lexically
>>> well-formed input, and that includes arbitrarily long
>>> character constants.
>>
>> Thanks for the clarification, Tim. The only incorrect
>> character constant seems to be an empty one -- '' ?
>
> In terms of lexical well-formedness, yes, I believe that's
> right. Let me say also that even though an empty character
> constant is not well formed as far as the C standard is
> concerned, I expect that any self-respecting de-commenting
> program would process it without complaint.
I wouldn't necessarily expect that. Preprocessor tokens, including
character constants, have to be recognized before comments can be
removed (both in phase 3, but pp-token recognition still has to
precede comment recognition). It doesn't seem reasonable to require
'/*' or "//" to be recognized as the beginning of a comment without
also requiring '' to be recognized as an invalid preprocessor token.
Of course a program (a C preprocessor or a comment recognizer)
*could* treat '' as a pseudo-valid token be diagnosed in a later
phase, and several compilers I've tried do so.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-04 20:12 -0800 |
| Message-ID | <868s98rpi3.fsf@linuxsc.com> |
| In reply to | #158121 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Anton Shepelev <anton.txt@gmail.com> writes: >> >>> Tim Rentsch: >>> >>>> In section 6.4.4.4, the C standard gives that part of C's >>>> lexical grammar that pertains to character constants. The >>>> grammar rules given allow an arbitrary number of "c-char" >>>> in between the enclosing single quotes, and that >>>> definition is what these decommenting programs should >>>> accept. More generally, they should accept any lexically >>>> well-formed input, and that includes arbitrarily long >>>> character constants. >>> >>> Thanks for the clarification, Tim. The only incorrect >>> character constant seems to be an empty one -- '' ? >> >> In terms of lexical well-formedness, yes, I believe that's >> right. Let me say also that even though an empty character >> constant is not well formed as far as the C standard is >> concerned, I expect that any self-respecting de-commenting >> program would process it without complaint. > > I wouldn't necessarily expect that. Preprocessor tokens, including > character constants, have to be recognized before comments can be > removed (both in phase 3, but pp-token recognition still has to > precede comment recognition). It doesn't seem reasonable to require > '/*' or "//" to be recognized as the beginning of a comment without > also requiring '' to be recognized as an invalid preprocessor token. The formatting program indent treats '' as a valid token.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-04 07:04 -0800 |
| Message-ID | <ae7d06e6-3c03-4f6d-9cb5-5995ca1060a6n@googlegroups.com> |
| In reply to | #156943 |
On Saturday, December 5, 2020 at 11:25:36 AM UTC-5, Tim Rentsch wrote:
> Short problem statement: a C program to remove comments from C
> source input.
Just discovered this, here is a very preliminary shot.
/*
* 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 short // 16 bits to insure '& 0xFF00' works
C2; // Last character read
unsigned char
C1, // Previous character read
Imode; // Input mode
unsigned char rdchar(void)
{
for(;;) {
C1 = C2;
// Assumes 8-bit char set, not including 0 and EOF is >255
if((C2 = getc(stdin)) & 0xFF00)
return 0;
// changing this to multiple 'if's could eliminate the 'switch' line
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C2 == '/'))
Imode = C2 = 0;
continue;
case '/' : // Inside '//' comment
if(C2 != '\n')
continue;
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 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C2) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C2;
continue; } }
if(C1)
return C1; }
}
int main(void)
{
unsigned char c;
rdchar(); // First call to rdchar will return 0;
for(;;) {
switch(c = rdchar()) {
case '\\': // Escape
putc(c, stdout);
if(c = rdchar())
break;
return 0;
case 0 :
putc(C1, stdout);
return 0;
case'\'':
case '"':
if(Imode == c)
Imode = 0;
else if(!Imode)
Imode = c;
break; }
putc(c, stdout); }
}
// Dave
// Search 'Dave's Old Computers' see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-04 20:22 -0800 |
| Message-ID | <864kjwrp0i.fsf@linuxsc.com> |
| In reply to | #158154 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
> On Saturday, December 5, 2020 at 11:25:36 AM UTC-5, Tim Rentsch wrote:
>
>> Short problem statement: a C program to remove comments from C
>> source input.
>
> Just discovered this, here is a very preliminary shot.
>
> [..code..]
For a shot that is very preliminary, I would have to say
it's not bad.
Several points of feedback:
One: output a space character in place of a /*...*/ comment.
This can be done with
putchar( ' ' ), Imode = C2 = 0;
in place of where 'Imode = C2 = 0;' is done now.
Two: there is some kind of glitch in processing the first
character. I didn't try to track this down but I think it
should be easy to see the effect.
Three: a sample input for you to test with (file starts
with 'xyz'):
xyz/* hello */
#define END_END_END_END_END
#define START_START_START
int x = 0 /\
*blah*/ + 1;
#define END_END_END_END_END
#define START_START_START
// blah \
\
blah
#define END_END_END_END_END
#define START_START_START
#define foo "\\
"/*"
#define END_END_END_END_END
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 04:24 -0800 |
| Message-ID | <bc72a3ec-4a68-4604-8e75-ee586a857dcan@googlegroups.com> |
| In reply to | #158170 |
> > Just discovered this, here is a very preliminary shot.
> > [..code..]
>
> For a shot that is very preliminary, I would have to say
> it's not bad.
Thanks.
> Several points of feedback:
>
> One: output a space character in place of a /*...*/ comment.
> This can be done with
>
> putchar( ' ' ), Imode = C2 = 0;
>
> in place of where 'Imode = C2 = 0;' is done now.
Agreed, without doing this, 'A/**/B' turns into 'AB'
which is definitely not the same.
> Two: there is some kind of glitch in processing the first
> character. I didn't try to track this down but I think it
> should be easy to see the effect.
Near the beginning of main:
rdchar(); // First call to rdchar will return 0;
I initially added this because rdchar() DID return C1
always and it is initially zero.
At the end of rcchar()
if(C1)
return C1; }
I added the 'if' to avoid returning 0
because '/**/' comments initially passed back '/'
which I discovered at first test. I added C2 to the '=0'
line you noted, and the 'if' but failed to realize this
would also eliminated the first 0 return.
Two easy ways to fix:
eliminate the initial call to 'rdchar() in main()
Even better:
Change 'Imode = C2 = 0;' in rdchar() to:
{ Imode=0; C2=' '; }
and eliminate the if(C1) as it will not be needed.
This will insert a space for '/**/' comments, but
note that the initial rdchar() still returns 0.
> Three: a sample input for you to test with (file starts
> with 'xyz'):
Interesting trick, trying to hide a single " within
a define:
#define foo "\\
"/*"
But this wouldn't compile under LCC (GCC), Borland Turbo-C
or my own Micro-C. Assuming you intended to put a newline
at the end of the #define, I changed it to:
#define foo "\
/*"
Which makes it compile on all of the above, and shows
correctly with my little "one shot".
I think that even if you could figure a way to put a single quote
within a #define, it would be outside the spirit of the "challenge"
as it would require you to implement #define which would be well
over the 25 line function limit. I might be able to do a somewhat
reasonable preprocessor with a lot of 25 line functions
- but it wouldn't be pretty.
--Dave
Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-05 06:22 -0800 |
| Message-ID | <86zh1nqx8r.fsf@linuxsc.com> |
| In reply to | #158175 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
>>> Just discovered this, here is a very preliminary shot.
>>> [..code..]
>>
>> For a shot that is very preliminary, I would have to say
>> it's not bad.
>
>
>> Several points of feedback: [...]
>>
>> Two: there is some kind of glitch in processing the first
>> character. [...]
>
> [..explanation..] Two easy ways to fix: [...]
As long as you understand what's going on, how to fix it
is up to you. Are you going to submit a revised program?
Other people have done that.
>> Three: a sample input for you to test with (file starts
>> with 'xyz'):
>
> Interesting trick, trying to hide a single " within
> a define:
>
> #define foo "\\
> "/*"
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 "\"/*". The \<newline> in
the middle is a line continuation, and gets removed prior to
tokenizing, leaving an escaped double quote in the middle of
the string.
> But this wouldn't compile under LCC (GCC), Borland Turbo-C
> or my own Micro-C.
Then they are broken. That is standard C (and just to be sure I
re-verified it using both gcc and clang).
> Assuming you intended to put a newline
> at the end of the #define, I changed it to:
>
> #define foo "\
> /*"
This input is completely different. The point of the example
is to show an escaped double quote with a line continuation
in the middle. Try this example:
char foo[] = "\\
\
\
\
" and now this part is still in the string...";
Again that is standard and valid C, verified with both gcc and
clang.
> I think that even if you could figure a way to put a single quote
> within a #define, it would be outside the spirit of the "challenge"
Definitely, but that is not what's going on here.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 08:55 -0800 |
| Message-ID | <4ed1bfed-173f-4aef-ad7b-0e0970860c80n@googlegroups.com> |
| In reply to | #158177 |
> 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 "\"/*".
Just shows how you can always learn something. Still don't quite
understand it though.
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:
"\\
"/*"
is: '"', '\\', nl, '"', '/', '*', '"'
which I would translate to:
STR, '\', nl, STR, '/', '*', STR
note the unmatched STR.
because \\ is a single '\' character, note I'm using STR
to denote the '"' interpreted as a string delimiter.
-------- Borland obviously looked at it the same way ---
#include <stdio.h>
#define foo "\\
"/*"
main()
{
fputs(foo, stdout);
}
--- TCC T.C gives ---
Turbo C Version 2.0 Copyright (c) 1987, 1988 Borland International
t.c:
Error t.c 4: Declaration syntax error
Error t.c 8: Unterminated string or character constant
*** 2 errors in Compile ***
Available memory 444682
---------------------------------------------------------
"\"/*" I would think of
as: '"', '\"', '/', '*', '"'
which would translate to:
STR, '"', '/', '*', STR
which is a valid string.
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
cpp: t.c:3 No newline at end of file
Entry point ("main" function) is not defined
-----------------------------
as expected. So it would appear that in the first case,
'\\' is acting as a line continuation character and NOT
as '\' but the second '\' of it applies to the '"' on the
following line.
-- it's not clear to me why in this case '\\' does not mean
'\'. If I code it the way I would have, which is:
#define foo "\
\"/*"
It also works exactly the same. It seems a bit inconsistent
to me as '\', '\', nl, '"' appears to be treated exactly the
same as '\', nl, '\', '"' - but you learn something new every
day!
I wonder if this is truly portable, or an interesting quirk
of some toolsets... Clearly I need to investigate some more.
Dave
Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
Page 14 of 20 — ← Prev page 1 … 12 13 [14] 15 16 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web