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 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-09 01:46 -0800 |
| Message-ID | <a2722ebf-5142-4556-a9c9-c20dafc3a06fn@googlegroups.com> |
| In reply to | #157132 |
On Wednesday, 9 December 2020 at 09:33:34 UTC, Anton Shepelev wrote: > I wrote: > > > Malcolm, > > > > you[r] program is not even trying :-) > > Test it with: > > > > a/*b*/c > > I still do not understand. When I save the text quoted above > into a file named 1.c and invoke your program with it: > > mclean.exe 1.c > > The result is: > > c > > -- that is a space followed by ` '. Is it correct behavior? > I expected: > > a c > > -- that is three characters: `a', space, and `c'. > Yes, there's a serious but simple bug. I clear the buffer instead of removing the forwards slash then flushing it on detecting a comment. But the program only handles single line continuation markers. In fact you can have a comment token split by arbitrarily many.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-08 23:29 -0800 |
| Message-ID | <86r1nz5te4.fsf@linuxsc.com> |
| In reply to | #157105 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > Here's my offering. [...] Just wanted to let you know I did get this and add it to the collection. Thank you for joining in.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-08 10:45 -0500 |
| Message-ID | <tcNzH.11096$co4.9494@fx43.iad> |
| In reply to | #157086 |
On 12/8/20 9:40 AM, Bart wrote: > On 08/12/2020 12:32, Richard Damon wrote: >> On 12/8/20 6:44 AM, Bart wrote: > >>> I've said before, this is a crazy thing to allow in a language (how do >>> you even specify it in a grammar?). >> >> C does it by specifying a sequence of stages that ar done. In C comments >> aren't part of the main language 'grammer', but get processed out before >> we get to the normal grammer phase. >> >> Note, that C also really has two fairly distince grammers, one for the >> preprocessor and seperate one for the main language constructs. >>> >>> All you need are // and /**/ comments and be done with it, without >>> allowing that whole extra dimension. >> >> It actually comes out very simply by the way the langague is defined, >> and it provides a very usefull capability for machine generated code >> with line length constraints. > > Yet, I've only heard of it in connection with C. No other language that > I know of does this. How did /they/ (and do they) manage without such a > feature?! > The key is that C is one of the few languages that was used as an output target in environments with strict line lengths. (I forget if the card format based FORTRAN allowed the continuation card (with the character in column 6) would allow breaking tokens that went to column 72 and continued in column 7) Several parts of C are to support this sort of usage.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-08 17:16 +0000 |
| Message-ID | <878sa8gqv3.fsf@bsb.me.uk> |
| In reply to | #157086 |
Bart <bc@freeuk.com> writes: > On 08/12/2020 12:32, Richard Damon wrote: >> On 12/8/20 6:44 AM, Bart wrote: > >>> I've said before, this is a crazy thing to allow in a language (how do >>> you even specify it in a grammar?). >> >> C does it by specifying a sequence of stages that ar done. In C comments >> aren't part of the main language 'grammer', but get processed out before >> we get to the normal grammer phase. >> >> Note, that C also really has two fairly distince grammers, one for the >> preprocessor and seperate one for the main language constructs. >>> >>> All you need are // and /**/ comments and be done with it, without >>> allowing that whole extra dimension. >> >> It actually comes out very simply by the way the langague is defined, >> and it provides a very usefull capability for machine generated code >> with line length constraints. In the old days, it was also useful for sending C in emails. Some systems had line length restrictions, so a simple method for breaking lines was a handy feature. > Yet, I've only heard of it in connection with C. No other language > that I know of does this. How did /they/ (and do they) manage without > such a feature?! Fortran has it's own somewhat fussier version. But no one is saying it's essential. Strange file formats and line length limitations are rare these days so newer languages are not likely to even consider such a feature. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-08 06:39 -0800 |
| Message-ID | <3d09a2ce-a2f8-420c-b533-fc1596478b0bn@googlegroups.com> |
| In reply to | #157080 |
On Tuesday, December 8, 2020 at 6:44:35 AM UTC-5, Bart wrote: > On 08/12/2020 00:02, Richard Damon wrote: > > On 12/5/20 11:25 AM, Tim Rentsch wrote: > >> Prompted by some recent discussion regarding 'goto' statements and > >> state machines, I would like to propose a programming exercise. > >> (It is perhaps a bit too large to be called an exercise, but not so > >> difficult that it deserves the label of challenge. On the other > >> hand there are some constraints so maybe challenge is apropos. In > >> any case somewhere in between those two bounds.) > >> > >> Short problem statement: a C program to remove comments from C > >> source input. > >> > >> Specifics: Remove both /*...*/ and //... style comments. Don't > >> worry about trigraphs. Read from stdin, write to stdout, and > >> diagnostics (if any) go to stderr. If EOF is seen inside a > >> comment, do something sensible but it doesn't matter what as long > >> as it's sensible. Use no 'goto' statements. Limit function > >> bodies to no more than 25 lines. > >> > >> Other: feel free to handle corner cases as you see fit, as long > >> as there is some description of what choice was made. > >> > >> Hopefully it will be a fun exercise. It isn't trivial but it > >> shouldn't take too long either. > >> > > > > A few thoughts on some things that I see that many entries aren't handling: > > > > Strings (and character constants): > > > > The following are some valid strings: > > "" > > > > "\"" > > > > "\\" > > > > "\\\"" > > > > "foo\ > > bar" > > > > > > An arbitrary number of \<nl> combinations can occur between the two > > characters that define the start/end of the comment so the following is > > a valid block comment > > > > > > /\ > > \ > > \ > > * comment *\ > > \ > > \ > > / > I've said before, this is a crazy thing to allow in a language (how do > you even specify it in a grammar?). You don't. It is specified it in the translation phases. The purpose of the translation phases is to establish "The precedence among the syntax rules of translation ..." The relevant rules are: Translation phase 2: "Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character before any such splicing takes place." Translation phase 3: "... A source file shall not end in a partial preprocessing token or in a partial comment. Each comment is replaced by one space character. ..." The C standard actually contains two different grammars, the lexical grammar, which is summarized in A.1, which applies at the start translation phase 4, and the phrase structure grammar which is summarized in A.2, which applies at the end of translation phase 7. > All you need are // and /**/ comments and be done with it, without > allowing that whole extra dimension. > > But today I thought I'd allow it in my C compiler anyway, as a special > option. Except that I found I'd already done it! > > It was available as a long-forgotten built-in flag. So I just made it a > regular compiler option (-splicing). It involves copying and translating > one string to another, which 99.9999% of the time will be a complete > waste of time. > > The 0.0001% is for threads like these. Special cases like the ones shown above are not of any importance to anyone. They are just a natural side-effect of correctly implementing translation phase 2. The main use of line splicing is to cope with the fact that pre-processing directives all are terminated by a new-line characters. Since pre-processing occurs during translation phase 4, the escaped new-lines don't count. That allows you to create multi-line pre-preprocessing directives, which is often necessary. If you implement translation phase 2 correctly, in order to enable multi-line preprocessing directives, it's interaction with comments will be handled correctly, without having to do anything special about that interaction.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-07 17:48 -0800 |
| Message-ID | <86r1o1hxtn.fsf@linuxsc.com> |
| In reply to | #156943 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Prompted by some recent discussion regarding 'goto' statements and > state machines, I would like to propose a programming exercise. > (It is perhaps a bit too large to be called an exercise, but not so > difficult that it deserves the label of challenge. On the other > hand there are some constraints so maybe challenge is apropos. In > any case somewhere in between those two bounds.) > > Short problem statement: a C program to remove comments from C > source input. > > Specifics: Remove both /*...*/ and //... style comments. Don't > worry about trigraphs. Read from stdin, write to stdout, and > diagnostics (if any) go to stderr. If EOF is seen inside a > comment, do something sensible but it doesn't matter what as long > as it's sensible. Use no 'goto' statements. Limit function > bodies to no more than 25 lines. > > Other: feel free to handle corner cases as you see fit, as long > as there is some description of what choice was made. > > Hopefully it will be a fun exercise. It isn't trivial but it > shouldn't take too long either. I see there has been a fair amount of activity. Also some questions and some confusions, so I am prompted to give some clarifications. The program is to remove (see below) C comments from a C source file input, and nothing else. An input with no C comments in it should be transmitted unchanged (provided its compile-time behavior is defined, see below). To give an obvious example, a multi-line macro definition that uses \ at the end of lines to continue the definition (but has no comments) should appear in the output exactly as in the input. The remark about "something sensible" for EOF might be phrased as anything that doesn't violate The Law of Least Astonishment. Simply stopping output is okay, either with or without an error return or diagnostic. The statement about corner cases is meant to apply to compile-time undefined behavior (meaning, in the input), and nothing else. Any input whose compile-time specification has defined behavior, including implementation-defined behavior, should be processed correctly. If an input has compile-time undefined behavior, do something reasonable (like in the previous paragraph), but it doesn't matter so much what exactly as long as the user is given some idea of what that will be. An important property is that the program should transform working programs into the same working programs. In other word compiling an input before it is transformed should give the same semantics as compiling it after it is transformed. There is an exception to this rule in cases where the C pre-processor stringize operator is used. In some cases removing a comment and doing nothing else cannot be done because doing so will change the meaning of the program. To deal with that problem, it is allowed to put in a space for a removed comment. Note, putting in a space is allowed but not required, as long as the input program semantics (not counting stringize) is unchanged. Hence it is permissible for programs that use the stringize operator to exhibit different behavior before and after being transformed. Except for that though the output semantics should match the input semantics. Re: removing comments. This might be done by removing comments entirely (and putting in a single space in some cases), or it might be done by replacing comments with some "filler" white space to, for example, preserve line numbers. Undoubtedly it is easier to simply take the comments out and put in a single space in their place; more elaborate replacements are allowed as long as the output has no comments and preserves the program semantics of the original input. Part of my motivation in offering the exercise is to see how people handle a non-trivial "state machiney" kind of program without using goto statements and without using "big" functions. The choice of 25 lines is meant to codify that, but it isn't meant as an exact hard limit - maybe five lines over (to accommodate style differences) is okay, ten lines over is pushing it. Incidentally, the problem statement isn't something I just made up for the newsgroup, but is a simplified version of a utility program that is used as part of a larger toolkit. Of course I knew this when I first posted the problem, so I had a more fixed idea than the original problem statement presented clearly, giving rise to the resulting confusions etc. I'm sorry the original problem wasn't stated more clearly, and I hope the statements here clear up any remaining uncertainties. Please, please, ask about something if there is any doubt about what is meant.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-07 21:03 -0500 |
| Message-ID | <3aBzH.1938$8f2.1340@fx16.iad> |
| In reply to | #157070 |
On 12/7/20 8:48 PM, Tim Rentsch wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Prompted by some recent discussion regarding 'goto' statements and >> state machines, I would like to propose a programming exercise. >> (It is perhaps a bit too large to be called an exercise, but not so >> difficult that it deserves the label of challenge. On the other >> hand there are some constraints so maybe challenge is apropos. In >> any case somewhere in between those two bounds.) >> >> Short problem statement: a C program to remove comments from C >> source input. >> >> Specifics: Remove both /*...*/ and //... style comments. Don't >> worry about trigraphs. Read from stdin, write to stdout, and >> diagnostics (if any) go to stderr. If EOF is seen inside a >> comment, do something sensible but it doesn't matter what as long >> as it's sensible. Use no 'goto' statements. Limit function >> bodies to no more than 25 lines. >> >> Other: feel free to handle corner cases as you see fit, as long >> as there is some description of what choice was made. >> >> Hopefully it will be a fun exercise. It isn't trivial but it >> shouldn't take too long either. > > I see there has been a fair amount of activity. Also some > questions and some confusions, so I am prompted to give some > clarifications. > > The program is to remove (see below) C comments from a C source > file input, and nothing else. An input with no C comments in it > should be transmitted unchanged (provided its compile-time > behavior is defined, see below). To give an obvious example, > a multi-line macro definition that uses \ at the end of lines > to continue the definition (but has no comments) should appear > in the output exactly as in the input. > > The remark about "something sensible" for EOF might be phrased as > anything that doesn't violate The Law of Least Astonishment. > Simply stopping output is okay, either with or without an error > return or diagnostic. > > The statement about corner cases is meant to apply to compile-time > undefined behavior (meaning, in the input), and nothing else. Any > input whose compile-time specification has defined behavior, > including implementation-defined behavior, should be processed > correctly. If an input has compile-time undefined behavior, do > something reasonable (like in the previous paragraph), but it > doesn't matter so much what exactly as long as the user is given > some idea of what that will be. > > An important property is that the program should transform working > programs into the same working programs. In other word compiling > an input before it is transformed should give the same semantics > as compiling it after it is transformed. There is an exception to > this rule in cases where the C pre-processor stringize operator is > used. In some cases removing a comment and doing nothing else > cannot be done because doing so will change the meaning of the > program. To deal with that problem, it is allowed to put in a > space for a removed comment. Note, putting in a space is allowed > but not required, as long as the input program semantics (not > counting stringize) is unchanged. Hence it is permissible for > programs that use the stringize operator to exhibit different > behavior before and after being transformed. Except for that > though the output semantics should match the input semantics. > > Re: removing comments. This might be done by removing comments > entirely (and putting in a single space in some cases), or it > might be done by replacing comments with some "filler" white > space to, for example, preserve line numbers. Undoubtedly it > is easier to simply take the comments out and put in a single > space in their place; more elaborate replacements are allowed > as long as the output has no comments and preserves the program > semantics of the original input. > > Part of my motivation in offering the exercise is to see how > people handle a non-trivial "state machiney" kind of program > without using goto statements and without using "big" functions. > The choice of 25 lines is meant to codify that, but it isn't meant > as an exact hard limit - maybe five lines over (to accommodate > style differences) is okay, ten lines over is pushing it. > > Incidentally, the problem statement isn't something I just made up > for the newsgroup, but is a simplified version of a utility > program that is used as part of a larger toolkit. Of course I > knew this when I first posted the problem, so I had a more fixed > idea than the original problem statement presented clearly, giving > rise to the resulting confusions etc. I'm sorry the original > problem wasn't stated more clearly, and I hope the statements here > clear up any remaining uncertainties. Please, please, ask about > something if there is any doubt about what is meant. > One piece of implemention defined behavior that you need to allow not handling is the case of \<sp><nl> (where <sp> is a space character and <nl> is a new line character) The issue is that whether the following line is a continuation of this line replacing the \) or not is implementaiton defined, but the program is going to need to make a firm decision on this. This case is a special case in the standard because of the flexibilty of handling speces at the end of lines in text files in C. It is allowed for implementations to add or remove trailing spaces at the end of lines, due to how some file systems deal with lines. Basically the Standard allows the character sequence /\<sp><nl>* to either be the beginning of a block comment or not based on the definition of the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-09 03:02 -0800 |
| Message-ID | <865z5b5jk2.fsf@linuxsc.com> |
| In reply to | #157071 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/7/20 8:48 PM, Tim Rentsch wrote: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Prompted by some recent discussion regarding 'goto' statements and >>> state machines, I would like to propose a programming exercise. >>> (It is perhaps a bit too large to be called an exercise, but not so >>> difficult that it deserves the label of challenge. On the other >>> hand there are some constraints so maybe challenge is apropos. In >>> any case somewhere in between those two bounds.) >>> >>> Short problem statement: a C program to remove comments from C >>> source input. >>> >>> Specifics: Remove both /*...*/ and //... style comments. Don't >>> worry about trigraphs. Read from stdin, write to stdout, and >>> diagnostics (if any) go to stderr. If EOF is seen inside a >>> comment, do something sensible but it doesn't matter what as long >>> as it's sensible. Use no 'goto' statements. Limit function >>> bodies to no more than 25 lines. >>> >>> Other: feel free to handle corner cases as you see fit, as long >>> as there is some description of what choice was made. >>> >>> Hopefully it will be a fun exercise. It isn't trivial but it >>> shouldn't take too long either. >> >> I see there has been a fair amount of activity. Also some >> questions and some confusions, so I am prompted to give some >> clarifications. >> >> The program is to remove (see below) C comments from a C source >> file input, and nothing else. An input with no C comments in it >> should be transmitted unchanged (provided its compile-time >> behavior is defined, see below). To give an obvious example, >> a multi-line macro definition that uses \ at the end of lines >> to continue the definition (but has no comments) should appear >> in the output exactly as in the input. >> >> The remark about "something sensible" for EOF might be phrased as >> anything that doesn't violate The Law of Least Astonishment. >> Simply stopping output is okay, either with or without an error >> return or diagnostic. >> >> The statement about corner cases is meant to apply to compile-time >> undefined behavior (meaning, in the input), and nothing else. Any >> input whose compile-time specification has defined behavior, >> including implementation-defined behavior, should be processed >> correctly. If an input has compile-time undefined behavior, do >> something reasonable (like in the previous paragraph), but it >> doesn't matter so much what exactly as long as the user is given >> some idea of what that will be. >> >> An important property is that the program should transform working >> programs into the same working programs. In other word compiling >> an input before it is transformed should give the same semantics >> as compiling it after it is transformed. There is an exception to >> this rule in cases where the C pre-processor stringize operator is >> used. In some cases removing a comment and doing nothing else >> cannot be done because doing so will change the meaning of the >> program. To deal with that problem, it is allowed to put in a >> space for a removed comment. Note, putting in a space is allowed >> but not required, as long as the input program semantics (not >> counting stringize) is unchanged. Hence it is permissible for >> programs that use the stringize operator to exhibit different >> behavior before and after being transformed. Except for that >> though the output semantics should match the input semantics. >> >> Re: removing comments. This might be done by removing comments >> entirely (and putting in a single space in some cases), or it >> might be done by replacing comments with some "filler" white >> space to, for example, preserve line numbers. Undoubtedly it >> is easier to simply take the comments out and put in a single >> space in their place; more elaborate replacements are allowed >> as long as the output has no comments and preserves the program >> semantics of the original input. >> >> Part of my motivation in offering the exercise is to see how >> people handle a non-trivial "state machiney" kind of program >> without using goto statements and without using "big" functions. >> The choice of 25 lines is meant to codify that, but it isn't meant >> as an exact hard limit - maybe five lines over (to accommodate >> style differences) is okay, ten lines over is pushing it. >> >> Incidentally, the problem statement isn't something I just made up >> for the newsgroup, but is a simplified version of a utility >> program that is used as part of a larger toolkit. Of course I >> knew this when I first posted the problem, so I had a more fixed >> idea than the original problem statement presented clearly, giving >> rise to the resulting confusions etc. I'm sorry the original >> problem wasn't stated more clearly, and I hope the statements here >> clear up any remaining uncertainties. Please, please, ask about >> something if there is any doubt about what is meant. > > One piece of implemention defined behavior that you need to allow > not handling is the case of \<sp><nl> (where <sp> is a space > character and <nl> is a new line character) > > The issue is that whether the following line is a continuation of > this line replacing the \) or not is implementaiton defined, but the > program is going to need to make a firm decision on this. > > This case is a special case in the standard because of the > flexibilty of handling speces at the end of lines in text files in > C. It is allowed for implementations to add or remove trailing > spaces at the end of lines, due to how some file systems deal with > lines. > > Basically the Standard allows the character sequence /\<sp><nl>* to > either be the beginning of a block comment or not based on the > definition of the implementation. It's true that an implementation has some freedom with regard to allowing, adding, or removing spaces at the end of a line. However that possibility is irrelevant as far as the comment removing program is concerned. Whatever input it gets is the input it gets, and that input is what determines what output gets produced. The earlier remark about implementation-defined behavior is limited to /what would be/ implementation-defined behavior /if the input read were viewed as a C program/. What happens with the implementation on which the comment removing program is running falls in a different category. To say this another way, as far as the problem statement is concerned, comment removing programs are free to assume that spaces are faithfully preserved even at the ends of lines, both when the source input is read and when any program output might be read later.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-09 08:02 -0500 |
| Message-ID | <zV3AH.35492$7K1.14383@fx46.iad> |
| In reply to | #157140 |
On 12/9/20 6:02 AM, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 12/7/20 8:48 PM, Tim Rentsch wrote: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Prompted by some recent discussion regarding 'goto' statements and >>>> state machines, I would like to propose a programming exercise. >>>> (It is perhaps a bit too large to be called an exercise, but not so >>>> difficult that it deserves the label of challenge. On the other >>>> hand there are some constraints so maybe challenge is apropos. In >>>> any case somewhere in between those two bounds.) >>>> >>>> Short problem statement: a C program to remove comments from C >>>> source input. >>>> >>>> Specifics: Remove both /*...*/ and //... style comments. Don't >>>> worry about trigraphs. Read from stdin, write to stdout, and >>>> diagnostics (if any) go to stderr. If EOF is seen inside a >>>> comment, do something sensible but it doesn't matter what as long >>>> as it's sensible. Use no 'goto' statements. Limit function >>>> bodies to no more than 25 lines. >>>> >>>> Other: feel free to handle corner cases as you see fit, as long >>>> as there is some description of what choice was made. >>>> >>>> Hopefully it will be a fun exercise. It isn't trivial but it >>>> shouldn't take too long either. >>> >>> I see there has been a fair amount of activity. Also some >>> questions and some confusions, so I am prompted to give some >>> clarifications. >>> >>> The program is to remove (see below) C comments from a C source >>> file input, and nothing else. An input with no C comments in it >>> should be transmitted unchanged (provided its compile-time >>> behavior is defined, see below). To give an obvious example, >>> a multi-line macro definition that uses \ at the end of lines >>> to continue the definition (but has no comments) should appear >>> in the output exactly as in the input. >>> >>> The remark about "something sensible" for EOF might be phrased as >>> anything that doesn't violate The Law of Least Astonishment. >>> Simply stopping output is okay, either with or without an error >>> return or diagnostic. >>> >>> The statement about corner cases is meant to apply to compile-time >>> undefined behavior (meaning, in the input), and nothing else. Any >>> input whose compile-time specification has defined behavior, >>> including implementation-defined behavior, should be processed >>> correctly. If an input has compile-time undefined behavior, do >>> something reasonable (like in the previous paragraph), but it >>> doesn't matter so much what exactly as long as the user is given >>> some idea of what that will be. >>> >>> An important property is that the program should transform working >>> programs into the same working programs. In other word compiling >>> an input before it is transformed should give the same semantics >>> as compiling it after it is transformed. There is an exception to >>> this rule in cases where the C pre-processor stringize operator is >>> used. In some cases removing a comment and doing nothing else >>> cannot be done because doing so will change the meaning of the >>> program. To deal with that problem, it is allowed to put in a >>> space for a removed comment. Note, putting in a space is allowed >>> but not required, as long as the input program semantics (not >>> counting stringize) is unchanged. Hence it is permissible for >>> programs that use the stringize operator to exhibit different >>> behavior before and after being transformed. Except for that >>> though the output semantics should match the input semantics. >>> >>> Re: removing comments. This might be done by removing comments >>> entirely (and putting in a single space in some cases), or it >>> might be done by replacing comments with some "filler" white >>> space to, for example, preserve line numbers. Undoubtedly it >>> is easier to simply take the comments out and put in a single >>> space in their place; more elaborate replacements are allowed >>> as long as the output has no comments and preserves the program >>> semantics of the original input. >>> >>> Part of my motivation in offering the exercise is to see how >>> people handle a non-trivial "state machiney" kind of program >>> without using goto statements and without using "big" functions. >>> The choice of 25 lines is meant to codify that, but it isn't meant >>> as an exact hard limit - maybe five lines over (to accommodate >>> style differences) is okay, ten lines over is pushing it. >>> >>> Incidentally, the problem statement isn't something I just made up >>> for the newsgroup, but is a simplified version of a utility >>> program that is used as part of a larger toolkit. Of course I >>> knew this when I first posted the problem, so I had a more fixed >>> idea than the original problem statement presented clearly, giving >>> rise to the resulting confusions etc. I'm sorry the original >>> problem wasn't stated more clearly, and I hope the statements here >>> clear up any remaining uncertainties. Please, please, ask about >>> something if there is any doubt about what is meant. >> >> One piece of implemention defined behavior that you need to allow >> not handling is the case of \<sp><nl> (where <sp> is a space >> character and <nl> is a new line character) >> >> The issue is that whether the following line is a continuation of >> this line replacing the \) or not is implementaiton defined, but the >> program is going to need to make a firm decision on this. >> >> This case is a special case in the standard because of the >> flexibilty of handling speces at the end of lines in text files in >> C. It is allowed for implementations to add or remove trailing >> spaces at the end of lines, due to how some file systems deal with >> lines. >> >> Basically the Standard allows the character sequence /\<sp><nl>* to >> either be the beginning of a block comment or not based on the >> definition of the implementation. > > It's true that an implementation has some freedom with regard to > allowing, adding, or removing spaces at the end of a line. > However that possibility is irrelevant as far as the comment > removing program is concerned. Whatever input it gets is the > input it gets, and that input is what determines what output gets > produced. The earlier remark about implementation-defined > behavior is limited to /what would be/ implementation-defined > behavior /if the input read were viewed as a C program/. What > happens with the implementation on which the comment removing > program is running falls in a different category. > > To say this another way, as far as the problem statement is > concerned, comment removing programs are free to assume that > spaces are faithfully preserved even at the ends of lines, > both when the source input is read and when any program > output might be read later. > But, my understanding of the standard is that the complier is free to interprete the file: (note using @ at the end of lines as a visible space character) a /\@ * foo ; // */ as either a line continuation code or not, and this behavior is NOT tied to how it treats blanks at the end of lines. While it allows the implemetation to ignore the blanks if the definition of text files might add them, it also allows the implementation to ignore them even if it doesn't, or more perversely, it consider them if the defintion might insert them. Leaving the solution of the perverse case just up to 'quality of implementation'. That means that this program needs to choose how it wants to make that decision, and if it disagrees with the rule used by the actual implementation might differ in what it generates. I would have to think hard if their is a way to write a statement where the \ space sequence could be valid code other than in the contet of a string litteral (where we couldn't get the comment). It might need to be inside a comment and affect when the comment ends.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-09 16:49 +0000 |
| Message-ID | <87im9aexfy.fsf@bsb.me.uk> |
| In reply to | #157150 |
Richard Damon <Richard@Damon-Family.org> writes: > But, my understanding of the standard is that the complier is free to > interprete the file: (note using @ at the end of lines as a visible > space character) > > > a /\@ > * foo > ; > // */ > > as either a line continuation code or not, Just to be clear, are you saying that this file might not be equivalent to a /* foo ; // */ which is just "a" and a comment? What is the alternative and how do you arrive at it? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-09 13:33 -0500 |
| Message-ID | <AL8AH.16979$Eo4.8197@fx44.iad> |
| In reply to | #157155 |
On 12/9/20 11:49 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> But, my understanding of the standard is that the complier is free to
>> interprete the file: (note using @ at the end of lines as a visible
>> space character)
>>
>>
>> a /\@
>> * foo
>> ;
>> // */
>>
>> as either a line continuation code or not,
>
> Just to be clear, are you saying that this file might not be equivalent
> to
>
> a /* foo
> ;
> // */
>
> which is just "a" and a comment? What is the alternative and how do you
> arrive at it?
>
It might be
a /* foo
;
// */
or it might be
a /\
* foo
;
// */
((ie the line splicing does not happen but the \ is just there.
The implementation is allowed to define that it accepts spaces before
the new line after the \ so /\<space><newline>* could be the start of a
block comment.
The implementation taking this option is NOT required to be on a system
with fuzzy rules about blanks at the end of lines. In fact, some argue
that it should be required, since many systems make it hard to see that
extra space in the code, and it can be hard sometimes to debug an issue
when the line is obviously spliced by the end of line \ when it turns
out it was defeated by a hidden space.
In the above case we will get an error but
int foo() {
/* *\@
/ return 1; // */
return 0;
}
could be a file to test which way the compiler is working. If the slash
can have spaces after it before the newline, it returns 1, otherwise it
returns 0.
I don't remember them changing this behavior in any of the more 'recent'
updates to the standard.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-09 19:57 +0000 |
| Message-ID | <87pn3ida69.fsf@bsb.me.uk> |
| In reply to | #157156 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/9/20 11:49 AM, Ben Bacarisse wrote: >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> But, my understanding of the standard is that the complier is free to >>> interprete the file: (note using @ at the end of lines as a visible >>> space character) >>> >>> >>> a /\@ >>> * foo >>> ; >>> // */ >>> >>> as either a line continuation code or not, >> >> Just to be clear, are you saying that this file might not be equivalent >> to >> >> a /* foo >> ; >> // */ >> >> which is just "a" and a comment? What is the alternative and how do you >> arrive at it? >> > > It might be > > a /* foo > ; > // */ > > or it might be > > a /\ > * foo > ; > // */ > > ((ie the line splicing does not happen but the \ is just there. Oh, sorry. You are using @ as a visible /space/. I though it was a visible newline character. For some reason I thought this post was separate to the \<sp><nl> issue. Apologies for the noise. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-10 01:45 +0000 |
| Message-ID | <I5fAH.88523$GUR9.69680@fx16.ams4> |
| In reply to | #157156 |
On 09/12/2020 18:33, Richard Damon wrote:
> On 12/9/20 11:49 AM, Ben Bacarisse wrote:
> The implementation is allowed to define that it accepts spaces before
> the new line after the \ so /\<space><newline>* could be the start of a
> block comment.
>
> The implementation taking this option is NOT required to be on a system
> with fuzzy rules about blanks at the end of lines. In fact, some argue
> that it should be required, since many systems make it hard to see that
> extra space in the code, and it can be hard sometimes to debug an issue
> when the line is obviously spliced by the end of line \ when it turns
> out it was defeated by a hidden space.
Two days ago I didn't even know about /\<newline>/ being a valid
comment. But most compilers accept such code, so it seems reasonable to
detect that also in a comment-removing program.
Now it seems an arbitratry number of spaces are allowed between \ and
the newline:
/\ <newline>/
But fewer compilers accept that (only rextester-clang and some versions
of gcc on my tests).
This makes it harder to detect line comment delimiters like /???/, /??*
and *?????/, where ? represents any number of \@<newline>, sequences, in
each of which @ represents any number of spaces, which can vary each
time (don't know about tabs).
And makes it considerably harder to preserve those sequences outside of
comments, without more complicated code and possibly more memory
resources. (Unlike an actual compiler, this needs to be done preferably
in one pass.)
So I would say that preservation is unreasonable in this case,
especially as:
* It makes no differences to the program (other than making it more
portable)
* It is not visible in the output
* What a comment is replaced by has not been specified at all, other
that ensuring tokens which would run together if not separated by a
comment are still distinct, so there can already by a hugely variable
amount of white space in output.
(I'm also not bothered with reporting errors in the source. That is
ultimately the compiler's job, if a /* is unterminated for example.)
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-12-10 02:15 +0000 |
| Message-ID | <rqs0bj$9sk$2@dont-email.me> |
| In reply to | #157175 |
On Thu, 10 Dec 2020 01:45:58 +0000, Bart wrote: > On 09/12/2020 18:33, Richard Damon wrote: >> On 12/9/20 11:49 AM, Ben Bacarisse wrote: > >> The implementation is allowed to define that it accepts spaces before >> the new line after the \ so /\<space><newline>* could be the start of >> a block comment. >> >> The implementation taking this option is NOT required to be on a system >> with fuzzy rules about blanks at the end of lines. In fact, some argue >> that it should be required, since many systems make it hard to see that >> extra space in the code, and it can be hard sometimes to debug an issue >> when the line is obviously spliced by the end of line \ when it turns >> out it was defeated by a hidden space. > > Two days ago I didn't even know about /\<newline>/ being a valid > comment. That seems to be a side-effect of the specifications in the C standard For instance, C11 5.1.1.2 Translation Phases, paragraph 2 implies it by placing the \<newline> line-splicing phase before the preprocessor tokenization phase. This means that line-splicing happens /before/ the tokenizer recognizes comments. > But most compilers accept such code, I would hope so, assuming that they even vaguely attempt to conform to the C standard. > so it seems reasonable to detect that also in a comment-removing > program. I concur. > Now it seems an arbitratry number of spaces are allowed between \ and > the newline: That doesn't seem to be part of the standard. So, that behaviour is something "implementation specific", and cannot be counted on. Certainly, /I/ wouldn't expect this "comment stripping" exercise to handle that condition. [snip] > But fewer compilers accept that (only rextester-clang and some versions > of gcc on my tests). P'haps you can document the behaviour as a defect to those implementations. [snip] -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-24 11:24 -0800 |
| Message-ID | <86a6u3ypm7.fsf@linuxsc.com> |
| In reply to | #157176 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Thu, 10 Dec 2020 01:45:58 +0000, Bart wrote:
[...]
>> Two days ago I didn't even know about /\<newline>/ being a valid
>> comment.
>
> That seems to be a side-effect of the specifications in the C
> standard For instance, C11 5.1.1.2 Translation Phases, paragraph 2
> implies it by placing the \<newline> line-splicing phase before the
> preprocessor tokenization phase. This means that line-splicing
> happens /before/ the tokenizer recognizes comments.
Right.
>> But most compilers accept such code,
>
> I would hope so, assuming that they even vaguely attempt to conform
> to the C standard.
>
>> so it seems reasonable to detect that also in a comment-removing
>> program.
>
> I concur.
>
>> Now it seems an arbitratry number of spaces are allowed between \
>> and the newline:
>
> That doesn't seem to be part of the standard.
Right, it isn't.
> So, that behaviour is
> something "implementation specific", and cannot be counted on.
Some implementations do allow that, but it is not conforming.
> Certainly, /I/ wouldn't expect this "comment stripping" exercise to
> handle that condition.
The exercise is meant to assume input will be processed
as described in the Translation Phases section, and need not
consider implementations that don't follow those rules.
>> But fewer compilers accept that (only rextester-clang and some
>> versions of gcc on my tests).
>
> P'haps you can document the behaviour as a defect to those
> implementations.
I don't know about clang, but gcc accepts both spaces and tabs
between '\\' and '\n' as being "not there" (with a warning
message). However, commentary from the people who chose the
behavior, and documentation on the gcc website, make it clear
that they consider the result non-conforming.
https://gcc.gnu.org/onlinedocs/gcc/Escaped-Newlines.html
https://gcc.gnu.org/legacy-ml/gcc-patches/2000-09/msg00430.html
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-09 21:57 -0500 |
| Message-ID | <u8gAH.6949$EA2.955@fx01.iad> |
| In reply to | #157175 |
On 12/9/20 8:45 PM, Bart wrote: > Now it seems an arbitratry number of spaces are allowed between \ and > the newline: That isn't quite right, the implementation is allowed, but not required to allow an arbitrary number of spaces between the \ and the newline, because in the mapping of the input to lines the implementation is allowed to remove spaces at the end of the line, and this operation occurs before the looking for the \ newline combination.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-10 03:32 +0000 |
| Message-ID | <20201209190039.577@kylheku.com> |
| In reply to | #157177 |
On 2020-12-10, Richard Damon <Richard@Damon-Family.org> wrote:
> On 12/9/20 8:45 PM, Bart wrote:
>> Now it seems an arbitratry number of spaces are allowed between \ and
>> the newline:
>
> That isn't quite right, the implementation is allowed, but not required
> to allow an arbitrary number of spaces between the \ and the newline,
> because in the mapping of the input to lines the implementation is
> allowed to remove spaces at the end of the line, and this operation
> occurs before the looking for the \ newline combination.
You must be referring to something that appears in C99 7.19, and
might have been even C90:
"Whether space characters that are written out immediately before a
new-line character appear when read in is implementation-defined."
If we imagine a source file being read with a C text stream, then what
this means is not that the backslash-newline sequence may have spaces in
it. What it means is that, in some implementations, if someone prepares
a source file containing lines that end in a backslash followed by one
or more spaces, then those lines may look to the C implementation as if
they they specify continuations, because the spaces are not there. The C
implementation, reading by means of a text stream, will never see the
spaces.
This could be simply because the implementation doesn't /store/ trailing
spaces in text file lines. (If trouble is taken to store the spaces,
why would they not be reproduced on input?)
If the spaces are not stored, then they effectively don't exist.
Someone thought he or she was preparing a source file with trailing
spaces, but acually that did not happen.
In any case, whether or not the deleted spaces are stored, someone
preparing a file in that manner on such a system is making a mistake in
the preparation.
This would only be a concern to someone who has to process files which
were transferred out of such a system (such that the spaces are
preserved in the transfer), and then has to process the files in a
manner emulating that system's I/O (pretending the trailing spaces are
not there).
That provokes the question: why would a system's I/O routines locally
delete spaces, yet allow those spaces to survive a transfer to a
different system?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-10 08:19 -0500 |
| Message-ID | <hfpAH.21749$Fr6.683@fx33.iad> |
| In reply to | #157178 |
On 12/9/20 10:32 PM, Kaz Kylheku wrote: > On 2020-12-10, Richard Damon <Richard@Damon-Family.org> wrote: >> On 12/9/20 8:45 PM, Bart wrote: >>> Now it seems an arbitratry number of spaces are allowed between \ and >>> the newline: >> >> That isn't quite right, the implementation is allowed, but not required >> to allow an arbitrary number of spaces between the \ and the newline, >> because in the mapping of the input to lines the implementation is >> allowed to remove spaces at the end of the line, and this operation >> occurs before the looking for the \ newline combination. > > You must be referring to something that appears in C99 7.19, and > might have been even C90: > > "Whether space characters that are written out immediately before a > new-line character appear when read in is implementation-defined." > > If we imagine a source file being read with a C text stream, then what > this means is not that the backslash-newline sequence may have spaces in > it. What it means is that, in some implementations, if someone prepares > a source file containing lines that end in a backslash followed by one > or more spaces, then those lines may look to the C implementation as if > they they specify continuations, because the spaces are not there. The C > implementation, reading by means of a text stream, will never see the > spaces. > Yes, It really isn't that the ultimate issue is that the compiler allows the spaces after the back-slash, but that some implementation might not see them. > This could be simply because the implementation doesn't /store/ trailing > spaces in text file lines. (If trouble is taken to store the spaces, > why would they not be reproduced on input?) > > If the spaces are not stored, then they effectively don't exist. > Someone thought he or she was preparing a source file with trailing > spaces, but acually that did not happen. > > In any case, whether or not the deleted spaces are stored, someone > preparing a file in that manner on such a system is making a mistake in > the preparation. There is probably no reason to actually have a file with the space after the back slash, except perhaps on a system that you know doesn't strip the spaces to allow a single line comment to end is a back slash. I think every other usage would be a syntax error. > > This would only be a concern to someone who has to process files which > were transferred out of such a system (such that the spaces are > preserved in the transfer), and then has to process the files in a > manner emulating that system's I/O (pretending the trailing spaces are > not there). > > That provokes the question: why would a system's I/O routines locally > delete spaces, yet allow those spaces to survive a transfer to a > different system? > The issue, as I remember it, was that some systems store text files as fixed length records, so when they wrote them, they padded out with spaces, and on read, the trailig space were removed. It is also possible that the file itself has been stored in a system that does preserve trailing spaces, but in the software stack getting it to the implementation, it goes through something that removes them, due to fixed length buffers and space padding. This means that it is conceivable for a system to take in a file with spaces at the end, but by the time it is processed, they have been removed. The Standard, being written in a generous style, allows one system that might not have that issue, act the same way as one that does, so the initial phase is intentionally quite broad, so as to allow a system to define its 'line ending' as an arbitrary number of spaces followed by a newline, which then becomes just a newline in the source file for the rest of the process (allowing spaces after the \ and before the newline in the source file).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-24 11:04 -0800 |
| Message-ID | <86eejfyqi4.fsf@linuxsc.com> |
| In reply to | #157150 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/9/20 6:02 AM, Tim Rentsch wrote:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 12/7/20 8:48 PM, Tim Rentsch wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Prompted by some recent discussion regarding 'goto' statements
>>>>> and state machines, I would like to propose a programming
>>>>> exercise. (It is perhaps a bit too large to be called an
>>>>> exercise, but not so difficult that it deserves the label of
>>>>> challenge. On the other hand there are some constraints so
>>>>> maybe challenge is apropos. In any case somewhere in between
>>>>> those two bounds.)
>>>>>
>>>>> Short problem statement: a C program to remove comments from C
>>>>> source input.
>>>>>
>>>>> Specifics: Remove both /*...*/ and //... style comments. Don't
>>>>> worry about trigraphs. Read from stdin, write to stdout, and
>>>>> diagnostics (if any) go to stderr. If EOF is seen inside a
>>>>> comment, do something sensible but it doesn't matter what as
>>>>> long as it's sensible. Use no 'goto' statements. Limit
>>>>> function bodies to no more than 25 lines.
>>>>>
>>>>> Other: feel free to handle corner cases as you see fit, as long
>>>>> as there is some description of what choice was made.
>>>>>
>>>>> Hopefully it will be a fun exercise. It isn't trivial but it
>>>>> shouldn't take too long either.
>>>>
>>>> I see there has been a fair amount of activity. Also some
>>>> questions and some confusions, so I am prompted to give some
>>>> clarifications.
>>>>
>>>> The program is to remove (see below) C comments from a C source
>>>> file input, and nothing else. An input with no C comments in it
>>>> should be transmitted unchanged (provided its compile-time
>>>> behavior is defined, see below). To give an obvious example, a
>>>> multi-line macro definition that uses \ at the end of lines to
>>>> continue the definition (but has no comments) should appear in
>>>> the output exactly as in the input.
>>>>
>>>> The remark about "something sensible" for EOF might be phrased as
>>>> anything that doesn't violate The Law of Least Astonishment.
>>>> Simply stopping output is okay, either with or without an error
>>>> return or diagnostic.
>>>>
>>>> The statement about corner cases is meant to apply to compile
>>>> time undefined behavior (meaning, in the input), and nothing
>>>> else. Any input whose compile-time specification has defined
>>>> behavior, including implementation-defined behavior, should be
>>>> processed correctly. If an input has compile-time undefined
>>>> behavior, do something reasonable (like in the previous
>>>> paragraph), but it doesn't matter so much what exactly as long as
>>>> the user is given some idea of what that will be.
>>>>
>>>> An important property is that the program should transform
>>>> working programs into the same working programs. In other word
>>>> compiling an input before it is transformed should give the same
>>>> semantics as compiling it after it is transformed. There is an
>>>> exception to this rule in cases where the C pre-processor
>>>> stringize operator is used. In some cases removing a comment and
>>>> doing nothing else cannot be done because doing so will change
>>>> the meaning of the program. To deal with that problem, it is
>>>> allowed to put in a space for a removed comment. Note, putting
>>>> in a space is allowed but not required, as long as the input
>>>> program semantics (not counting stringize) is unchanged. Hence
>>>> it is permissible for programs that use the stringize operator to
>>>> exhibit different behavior before and after being transformed.
>>>> Except for that though the output semantics should match the
>>>> input semantics.
>>>>
>>>> Re: removing comments. This might be done by removing comments
>>>> entirely (and putting in a single space in some cases), or it
>>>> might be done by replacing comments with some "filler" white
>>>> space to, for example, preserve line numbers. Undoubtedly it is
>>>> easier to simply take the comments out and put in a single space
>>>> in their place; more elaborate replacements are allowed as long
>>>> as the output has no comments and preserves the program semantics
>>>> of the original input.
>>>>
>>>> Part of my motivation in offering the exercise is to see how
>>>> people handle a non-trivial "state machiney" kind of program
>>>> without using goto statements and without using "big" functions.
>>>> The choice of 25 lines is meant to codify that, but it isn't
>>>> meant as an exact hard limit - maybe five lines over (to
>>>> accommodate style differences) is okay, ten lines over is pushing
>>>> it.
>>>>
>>>> Incidentally, the problem statement isn't something I just made
>>>> up for the newsgroup, but is a simplified version of a utility
>>>> program that is used as part of a larger toolkit. Of course I
>>>> knew this when I first posted the problem, so I had a more fixed
>>>> idea than the original problem statement presented clearly,
>>>> giving rise to the resulting confusions etc. I'm sorry the
>>>> original problem wasn't stated more clearly, and I hope the
>>>> statements here clear up any remaining uncertainties. Please,
>>>> please, ask about something if there is any doubt about what is
>>>> meant.
>>>
>>> One piece of implemention defined behavior that you need to allow
>>> not handling is the case of \<sp><nl> (where <sp> is a space
>>> character and <nl> is a new line character)
>>>
>>> The issue is that whether the following line is a continuation of
>>> this line replacing the \) or not is implementaiton defined, but
>>> the program is going to need to make a firm decision on this.
>>>
>>> This case is a special case in the standard because of the
>>> flexibilty of handling speces at the end of lines in text files in
>>> C. It is allowed for implementations to add or remove trailing
>>> spaces at the end of lines, due to how some file systems deal with
>>> lines.
>>>
>>> Basically the Standard allows the character sequence /\<sp><nl>*
>>> to either be the beginning of a block comment or not based on the
>>> definition of the implementation.
>>
>> It's true that an implementation has some freedom with regard to
>> allowing, adding, or removing spaces at the end of a line.
>> However that possibility is irrelevant as far as the comment
>> removing program is concerned. Whatever input it gets is the
>> input it gets, and that input is what determines what output gets
>> produced. The earlier remark about implementation-defined
>> behavior is limited to /what would be/ implementation-defined
>> behavior /if the input read were viewed as a C program/. What
>> happens with the implementation on which the comment removing
>> program is running falls in a different category.
>>
>> To say this another way, as far as the problem statement is
>> concerned, comment removing programs are free to assume that
>> spaces are faithfully preserved even at the ends of lines,
>> both when the source input is read and when any program
>> output might be read later.
>
> But, my understanding of the standard is that the complier is free
> to interprete the file: (note using @ at the end of lines as a
> visible space character)
>
>
> a /\@
> * foo
> ;
> // */
>
> as either a line continuation code or not, and this behavior is
> NOT tied to how it treats blanks at the end of lines. While it
> allows the implemetation to ignore the blanks if the definition of
> text files might add them, it also allows the implementation to
> ignore them even if it doesn't, or more perversely, it consider
> them if the defintion might insert them. Leaving the solution of
> the perverse case just up to 'quality of implementation'.
Let me see if I can help untangle the verbal spider web here.
The C standard discusses Input/Output in section 7.21, with
section 7.21.2 being about streams, and paragraph 2 of 7.21.2
being specifically about text streams. That paragraph says in
part:
A text stream is an ordered sequence of characters composed
into lines, each line consisting of zero or more characters
plus a terminating new-line character. [...] Whether space
characters that are written out immediately before a new-line
character appear when read in is implementation-defined.
A compiler doesn't have to read its input using a text stream,
although certainly it could. However, to do that, the compiler
must have been built using a previously existing implementation.
It is the previously existing implementation that decides how
text stream I/O will be handled for the compiler, not the
compiler itself. Even if the PEI was built using the very same
source files, it is a distinct implementation, and whatever
decision was made is a done deal. A compiler (and associated
libraries, etc) does get to decide what happens with programs
that it compiles, but /not/ what happens for its own input: that
decision was made already by the implementation used to build the
compiler. Whatever input it gets is what it gets, and that must
be treated as what the file contains.
A de-commenting program is in a sense a compiler-like program, in
that it reads input meant to be C source code. Such programs
should therefore be built using the PEI that was used to build
the compiler that will later compile that C source code. If they
are not, then all bets are off: we might see 16-bit characters
rather than 8-bit characters, or have program source be read as
EBCDIC rather than ASCII. Of course the de-commenting program
and the intended compiler should be made to match, as otherwise
nonsensical results may ensue.
A compiler that gets '\\', ' ', '\n', in its input stream, and
treats that input as a line continuation, is not conforming.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-24 19:34 +0000 |
| Message-ID | <20201224112821.883@kylheku.com> |
| In reply to | #157699 |
On 2020-12-24, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > A compiler that gets '\\', ' ', '\n', in its input stream, and > treats that input as a line continuation, is not conforming. Right; if such a sequence comes out of a stream, it means that the platform's streams are capable of recording trailing spaces in lines, and that's exacly what is happening right there. An ISO C conforming stream can obliterate trailing spaces, so that when a file is prepared containing '\\', ' ', '\n', the implementation may vandalize that into '\\', '\n', which changes the meaning if that file is C source. (Thus, for maximal portability, do not prepare such source.) The situation has no bearing on the de-commenting program (or any other compiler-like program) when it reads a stream containing trailing spaces. When a line *not* containing trailing spaces is read, there is the suspicion that there had originally been trailing spaces which were deleted by the impelementation's text streams. There is no evidence available to the compiler-like program to confirm or refute such a suspicion. If there are grounds for the suspicion, it is a foregone problem that must be dealt with upstream.
[toc] | [prev] | [next] | [standalone]
Page 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web