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 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-24 12:24 -0800 |
| Message-ID | <877dp79cl9.fsf@nosuchdomain.example.com> |
| In reply to | #157701 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 12/9/20 1:55 AM, Tim Rentsch wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> The spec did say to make your own decisions on corner cases.
>>>
>>> Corner cases are meant to be only for input that the C
>>> standard specifies as undefined behavior.
>>
>> or implementation defined or unspecified behavior, like the
>> \<space><newline> case.
>
> No, I meant what I said. Furthermore any compiler that
> accepts \<space><newline> as a line continuation is not
> conforming, as I have explained else-thread.
I thought I had seen (and perhaps even made) an argument that phase 1:
Physical source file multibyte characters are mapped, in an
implementation-defined manner, to the source character set
(introducing new-line characters for end-of-line indicators) if
necessary.
could include removing trailing spaces. I admit it's a bit of a
stretch of the meaning of "mapped".
Aside from what the standard actually says, I certainly think it's more
convenient to be able to ignore spaces at the end of a line following a
\ character. Treating backslash+space at the end of a line differently
than backslash at the end of a line is awkward, even if it's conforming.
I'd like to see a modification to phase 1 saying that white space
between \ and the end of a line is discarded.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-24 17:19 -0500 |
| Message-ID | <du8FH.44799$R82.5801@fx46.iad> |
| In reply to | #157705 |
On 12/24/20 3:24 PM, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Richard Damon <Richard@Damon-Family.org> writes: >>> On 12/9/20 1:55 AM, Tim Rentsch wrote: >>>> Bart <bc@freeuk.com> writes: >>>> [...] >>>> >>>>> The spec did say to make your own decisions on corner cases. >>>> >>>> Corner cases are meant to be only for input that the C >>>> standard specifies as undefined behavior. >>> >>> or implementation defined or unspecified behavior, like the >>> \<space><newline> case. >> >> No, I meant what I said. Furthermore any compiler that >> accepts \<space><newline> as a line continuation is not >> conforming, as I have explained else-thread. > > I thought I had seen (and perhaps even made) an argument that phase 1: > > Physical source file multibyte characters are mapped, in an > implementation-defined manner, to the source character set > (introducing new-line characters for end-of-line indicators) if > necessary. > > could include removing trailing spaces. I admit it's a bit of a > stretch of the meaning of "mapped". > > Aside from what the standard actually says, I certainly think it's more > convenient to be able to ignore spaces at the end of a line following a > \ character. Treating backslash+space at the end of a line differently > than backslash at the end of a line is awkward, even if it's conforming. > I'd like to see a modification to phase 1 saying that white space > between \ and the end of a line is discarded. > The big part of the issue is that some system don't use \n or anything like it to terminate lines, but store text files as fixed length records which are space filled. In such an environment, it would be very inconvinent, if not impossible to make the \ the very last character of the line (different parts of the system might use different length possible lines, so file moved to a longer system would no longer be at the end, and the need to have the \ at the end would make it likely cause an error if you tried to move it to a short length system. The C Standard makes several concessions to support such systems, like the possible loss of spaces at end of text lines in files, and I thought it was clarified that this included similar options to phase 1. So yes, if phase 2 sees \<space><newline> it should not interpret that as a line continuation, but phase 1 might convert <space><newline> to just be <newline> under the clause of (introducing new-line characters for end-of-line indicators) by defining the 'end-of-line indicator' to be an arbitrary and optional number of white spaces followed by a newline character.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-27 05:16 -0800 |
| Message-ID | <86pn2vwfr9.fsf@linuxsc.com> |
| In reply to | #157710 |
Richard Damon <Richard@Damon-Family.org> writes: > On 12/24/20 3:24 PM, Keith Thompson wrote: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Richard Damon <Richard@Damon-Family.org> writes: >>> >>>> On 12/9/20 1:55 AM, Tim Rentsch wrote: >>>> >>>>> Bart <bc@freeuk.com> writes: >>>>> [...] >>>>> >>>>>> The spec did say to make your own decisions on corner cases. >>>>> >>>>> Corner cases are meant to be only for input that the C >>>>> standard specifies as undefined behavior. >>>> >>>> or implementation defined or unspecified behavior, like the >>>> \<space><newline> case. >>> >>> No, I meant what I said. Furthermore any compiler that >>> accepts \<space><newline> as a line continuation is not >>> conforming, as I have explained else-thread. >> >> I thought I had seen (and perhaps even made) an argument that phase 1: >> >> Physical source file multibyte characters are mapped, in an >> implementation-defined manner, to the source character set >> (introducing new-line characters for end-of-line indicators) if >> necessary. >> >> could include removing trailing spaces. I admit it's a bit of a >> stretch of the meaning of "mapped". >> >> Aside from what the standard actually says, I certainly think it's more >> convenient to be able to ignore spaces at the end of a line following a >> \ character. Treating backslash+space at the end of a line differently >> than backslash at the end of a line is awkward, even if it's conforming. >> I'd like to see a modification to phase 1 saying that white space >> between \ and the end of a line is discarded. > > The big part of the issue is that some system don't use \n or anything > like it to terminate lines, but store text files as fixed length records > which are space filled. In such an environment, it would be very > inconvinent, if not impossible to make the \ the very last character of > the line (different parts of the system might use different length > possible lines, so file moved to a longer system would no longer be at > the end, and the need to have the \ at the end would make it likely > cause an error if you tried to move it to a short length system. > > The C Standard makes several concessions to support such systems, like > the possible loss of spaces at end of text lines in files, and I thought > it was clarified that this included similar options to phase 1. > > So yes, if phase 2 sees \<space><newline> it should not interpret that > as a line continuation, but phase 1 might convert <space><newline> to > just be <newline> under the clause of > > (introducing new-line characters for end-of-line indicators) > > by defining the 'end-of-line indicator' to be an arbitrary and optional > number of white spaces followed by a newline character. Presumably whatever rule the compiler is using is the same as the rule for text streams in the environment of the decommenting program. It's pointless to compare cases where these two rules are different, like what I said in my earlier response elsethread.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-27 04:17 -0800 |
| Message-ID | <8635zrxx30.fsf@linuxsc.com> |
| In reply to | #157705 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 12/9/20 1:55 AM, Tim Rentsch wrote:
>>>
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>
>>>>> The spec did say to make your own decisions on corner cases.
>>>>
>>>> Corner cases are meant to be only for input that the C
>>>> standard specifies as undefined behavior.
>>>
>>> or implementation defined or unspecified behavior, like the
>>> \<space><newline> case.
>>
>> No, I meant what I said. Furthermore any compiler that
>> accepts \<space><newline> as a line continuation is not
>> conforming, as I have explained else-thread.
>
> I thought I had seen (and perhaps even made) an argument that phase 1:
>
> Physical source file multibyte characters are mapped, in an
> implementation-defined manner, to the source character set
> (introducing new-line characters for end-of-line indicators) if
> necessary.
>
> could include removing trailing spaces. I admit it's a bit of a
> stretch of the meaning of "mapped".
There is no way to make that work. Let me call the two kinds
of spaces <space>[PSF] and <space>[SCS]. If we have a physical
source file with a line
int<space>[PSF]x;<space>[PSF]<space>[PSF]<newline>[PSF]
presumably you would want that to map to
int<space>[SCS]x;<newline>[SCS]
which means <space>[PSF] would be a single-byte character and
also part of a non-single-byte multi-byte character. It can't
be both.
> Aside from what the standard actually says, I certainly think it's
> more convenient to be able to ignore spaces at the end of a line
> following a \ character. Treating backslash+space at the end of a
> line differently than backslash at the end of a line is awkward,
> even if it's conforming. I'd like to see a modification to phase 1
> saying that white space between \ and the end of a line is
> discarded.
I oppose such a change. It's a needless complication and an
unnecessary incompatibility. I have compiled probably tens of
millions of lines, if not hundreds of millions of lines, of C
code, and I don't remember ever seeing this problem except in
cases constructed specifically to test this rule. Moreover if
someone wants to guard against end-of-line spaces it's almost
trivial to do that with a single grep or sed command. Or just
compile with gcc, which will give a diagnostic in the particular
case of spaces/tabs between \ and newline. Any change to the C
standard, and especially any change that causes incompatibility
between different versions, should yield substantial benefits to
justify its introduction. The case we're talking about here
occurs so rarely that it is nowhere close to reaching the bar.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-27 08:27 -0500 |
| Message-ID | <dZ%FH.74176$x92.27175@fx48.iad> |
| In reply to | #157809 |
On 12/27/20 7:17 AM, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Richard Damon <Richard@Damon-Family.org> writes: >>> >>>> On 12/9/20 1:55 AM, Tim Rentsch wrote: >>>> >>>>> Bart <bc@freeuk.com> writes: >>>>> [...] >>>>> >>>>>> The spec did say to make your own decisions on corner cases. >>>>> >>>>> Corner cases are meant to be only for input that the C >>>>> standard specifies as undefined behavior. >>>> >>>> or implementation defined or unspecified behavior, like the >>>> \<space><newline> case. >>> >>> No, I meant what I said. Furthermore any compiler that >>> accepts \<space><newline> as a line continuation is not >>> conforming, as I have explained else-thread. >> >> I thought I had seen (and perhaps even made) an argument that phase 1: >> >> Physical source file multibyte characters are mapped, in an >> implementation-defined manner, to the source character set >> (introducing new-line characters for end-of-line indicators) if >> necessary. >> >> could include removing trailing spaces. I admit it's a bit of a >> stretch of the meaning of "mapped". > > There is no way to make that work. Let me call the two kinds > of spaces <space>[PSF] and <space>[SCS]. If we have a physical > source file with a line > > int<space>[PSF]x;<space>[PSF]<space>[PSF]<newline>[PSF] > > presumably you would want that to map to > > int<space>[SCS]x;<newline>[SCS] > > which means <space>[PSF] would be a single-byte character and > also part of a non-single-byte multi-byte character. It can't > be both. > Who says that is prohibited at a system level? Note that this sort of stuff DOES happen in some character sets, that you need to use a bit of look ahead to decode what a character means. Note also, that the issue does NOT exist at the level of the Source Character Set, as by the point we get to that, the spaces before the newline have been removed, so the source character set does not have that issue. >> Aside from what the standard actually says, I certainly think it's >> more convenient to be able to ignore spaces at the end of a line >> following a \ character. Treating backslash+space at the end of a >> line differently than backslash at the end of a line is awkward, >> even if it's conforming. I'd like to see a modification to phase 1 >> saying that white space between \ and the end of a line is >> discarded. > > I oppose such a change. It's a needless complication and an > unnecessary incompatibility. I have compiled probably tens of > millions of lines, if not hundreds of millions of lines, of C > code, and I don't remember ever seeing this problem except in > cases constructed specifically to test this rule. Moreover if > someone wants to guard against end-of-line spaces it's almost > trivial to do that with a single grep or sed command. Or just > compile with gcc, which will give a diagnostic in the particular > case of spaces/tabs between \ and newline. Any change to the C > standard, and especially any change that causes incompatibility > between different versions, should yield substantial benefits to > justify its introduction. The case we're talking about here > occurs so rarely that it is nowhere close to reaching the bar. > Maybe I am just 'luckier' than you, as I HAVE seen cases in the wild where it made a difference. Code was copy and pasted from an article and cleaned up. Results was much of the code had trailing spaces, and the lines that had multi-line macros just didn't compile right. The person who did this was TOTALLY puzzled by the error messages, because in the editor it was clear that this was a continuation line, but only with careful operation of the editor could the space after the \ be detected. As far as I know, the only way valid code would be broken with this would be a line oriented comment that ends with a \ followed by spaces then the next line is not a comment. (the most likely cause would be a comment ending with a Linux path name to a directory, especially to root I am not sure that such a line would be considered good practice anyway, as if you ever DID one of the cleanups you propose, it would break that line.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-29 19:18 -0800 |
| Message-ID | <86v9ckugkr.fsf@linuxsc.com> |
| In reply to | #157816 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/27/20 7:17 AM, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 12/9/20 1:55 AM, Tim Rentsch wrote:
>>>>>
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>> [...]
>>>>>>
>>>>>>> The spec did say to make your own decisions on corner cases.
>>>>>>
>>>>>> Corner cases are meant to be only for input that the C
>>>>>> standard specifies as undefined behavior.
>>>>>
>>>>> or implementation defined or unspecified behavior, like the
>>>>> \<space><newline> case.
>>>>
>>>> No, I meant what I said. Furthermore any compiler that
>>>> accepts \<space><newline> as a line continuation is not
>>>> conforming, as I have explained else-thread.
>>>
>>> I thought I had seen (and perhaps even made) an argument that phase 1:
>>>
>>> Physical source file multibyte characters are mapped, in an
>>> implementation-defined manner, to the source character set
>>> (introducing new-line characters for end-of-line indicators) if
>>> necessary.
>>>
>>> could include removing trailing spaces. I admit it's a bit of a
>>> stretch of the meaning of "mapped".
>>
>> There is no way to make that work. Let me call the two kinds
>> of spaces <space>[PSF] and <space>[SCS]. If we have a physical
>> source file with a line
>>
>> int<space>[PSF]x;<space>[PSF]<space>[PSF]<newline>[PSF]
>>
>> presumably you would want that to map to
>>
>> int<space>[SCS]x;<newline>[SCS]
>>
>> which means <space>[PSF] would be a single-byte character and
>> also part of a non-single-byte multi-byte character. It can't
>> be both.
>
> Who says that is prohibited at a system level? Note that this sort of
> stuff DOES happen in some character sets, that you need to use a bit of
> look ahead to decode what a character means.
Yes, it wouldn't be surprising to see such a thing in cases where
for example the unadorned character is an 'e' and the adorned
character is an 'e' with an accent.
On the other hand, it's a safe bet that no existing character set
has a multi-byte character that is simply a redundant representation
of a single-byte character, or has unbounded lookahead. The point
of mapping physical source multi-byte characters is to conform to
an externally chosen representation, not to let a C implementation
transmogrify the input according to its whims.
Short summary: probably technically within the letter of the C
standard, but surely not the intended meaning.
> Note also, that the issue does NOT exist at the level of the Source
> Character Set, as by the point we get to that, the spaces before the
> newline have been removed, so the source character set does not have
> that issue.
The source /character set/ certainly does have the problem. A
bizarro mapping can eliminate the possibility of a particular input
during stage 1, but the source character set still has the ability
to represent the undesired inputs.
>>> Aside from what the standard actually says, I certainly think it's
>>> more convenient to be able to ignore spaces at the end of a line
>>> following a \ character. Treating backslash+space at the end of a
>>> line differently than backslash at the end of a line is awkward,
>>> even if it's conforming. I'd like to see a modification to phase 1
>>> saying that white space between \ and the end of a line is
>>> discarded.
>>
>> I oppose such a change. It's a needless complication and an
>> unnecessary incompatibility. I have compiled probably tens of
>> millions of lines, if not hundreds of millions of lines, of C
>> code, and I don't remember ever seeing this problem except in
>> cases constructed specifically to test this rule. Moreover if
>> someone wants to guard against end-of-line spaces it's almost
>> trivial to do that with a single grep or sed command. Or just
>> compile with gcc, which will give a diagnostic in the particular
>> case of spaces/tabs between \ and newline. Any change to the C
>> standard, and especially any change that causes incompatibility
>> between different versions, should yield substantial benefits to
>> justify its introduction. The case we're talking about here
>> occurs so rarely that it is nowhere close to reaching the bar.
>
> Maybe I am just 'luckier' than you, as I HAVE seen cases in the wild
> where it made a difference. Code was copy and pasted from an article and
> cleaned up. Results was much of the code had trailing spaces, and the
> lines that had multi-line macros just didn't compile right.
>
> The person who did this was TOTALLY puzzled by the error messages,
> because in the editor it was clear that this was a continuation line,
> but only with careful operation of the editor could the space after the
> \ be detected.
Even so, the ROI is very close to zero. It isn't like this happens
every day, or even every year; you get puzzled once, and after it
happens the makefiles are fixed so it doesn't happen again. Done.
> As far as I know, the only way valid code would be broken with this
> would be a line oriented comment that ends with a \ followed by spaces
> then the next line is not a comment. (the most likely cause would be a
> comment ending with a Linux path name to a directory, especially to root
#define BACKSLANT \ (with spaces after the \)
#define SOMETHING ...
> I am not sure that such a line would be considered good practice anyway,
> as if you ever DID one of the cleanups you propose, it would break that
> line.
Oh nonsense. Using grep would flag the line but not change
anything. An intentional white-space-after-backslant could
be done using a TAB character rather than a space, assuming
one wanted to do that. Or a sed command could change spaces
after a backslant into '\/*!*/' and then a subsequent grep
could look for that pattern. etc...
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-07 05:15 -0800 |
| Message-ID | <2b402da4-d2fe-46a2-8e5d-ead8d6eda752n@googlegroups.com> |
| In reply to | #157020 |
On Monday, 7 December 2020 at 12:05:36 UTC, Ben Bacarisse wrote: > > Preserving uncommented line continuations makes the problem seem a > little contrived to me. I'm not tempted to have a go. > That's a classic gotcha that occurs all the time in industrial programming. The client asks for something, maybe tries to specify it formally or maybe just asks for it informally, then finds that whilst the result does most of what he wants, there are a few cases which it doesn't handle properly. It might be technically what he asked for, or it might be something that wasn't considered until the first candidate program was delivered. Either way, he's paying the bills. The program structure often deteriorates as you try to accommodate these requests without starting from scratch.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-07 13:42 +0000 |
| Message-ID | <87h7oxohqq.fsf@bsb.me.uk> |
| In reply to | #157026 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Monday, 7 December 2020 at 12:05:36 UTC, Ben Bacarisse wrote: >> >> Preserving uncommented line continuations makes the problem seem a >> little contrived to me. I'm not tempted to have a go. >> > That's a classic gotcha that occurs all the time in industrial programming. > > The client asks for something, maybe tries to specify it formally or maybe > just asks for it informally, then finds that whilst the result does most of > what he wants, there are a few cases which it doesn't handle properly. > It might be technically what he asked for, or it might be something that > wasn't considered until the first candidate program was delivered. Either > way, he's paying the bills. > > The program structure often deteriorates as you try to accommodate > these requests without starting from scratch. Yes. This is a big part of my complaint to Bart that using a goto is often the simplest solution. As accumulated "simple" changes go, adding in a goto is one of the most risky. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-08 22:53 -0800 |
| Message-ID | <86pn3j79nh.fsf@linuxsc.com> |
| In reply to | #157020 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> It's a nice program, but it doesn't quite do what was asked for. >> The problem statement says to remove comments. This program does >> remove comments, but it also takes out line splices to replace >> multiple physical lines with their corresponding logical line. >> Line continuation sequences outside of comments should be >> preserved in the output. > > Ah, I didn't see that in the specification. Given the phases described > in the standard, I implemented what I guessed was the expected > behaviour. Understood. In hindsight I realize the problem statement wasn't clear enough. More on your other comments which I hope to get to soon.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-10 01:49 -0800 |
| Message-ID | <86wnxq2do9.fsf@linuxsc.com> |
| In reply to | #157020 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>>> Haskell has two big advantages for this exercise: pattern matched
>>> cases and lazy evaluation. [..explanation..]
>>
>> Also one not mentioned: 'input <- getContents'. An analogous
>> functionality in C would read the contents of a file into a
>> character array, which would make the C program easier.
>
> I don't think its analogous at all! 'input' <- getContents does
> no IO. Input is fetched only as needed to perform computations on
> 'input' and processed data will be considered garbage.
The point I am trying to make here is not about IO but about data
structuring. I understand that Haskell has lazy eval and agree
that there are advantages that accrue from that. Here though I
think the important property is that getContents returns a "data
structure" that is convenient to process in Haskell, specifically
in the context of what an uncommenting program wants to do. An
analogous data structure in C (not counting the lazy evaluation
part, which I've already acknowledged) is a character array.
Let's look at some C code that takes advantage of its primary
data structure for handling strings.
** SPOILER ALERT **
The program below is a comment remover where backslant-newline
sequences have also been eliminated in the output. Stop reading
now if you don't want to see the code yet.
** SPOILER ALERT **
Granted, the code below isn't a nice as your Haskell version, but
I think it isn't too bad. How does it strike you?
/* remove comments after pre-combining physical lines into logical lines */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef const char *String;
static int decomment_stdin_all_good( void );
static void splice_lines( char * );
static int decomment_okay( String );
static String show_literal( String );
static String show_string( String );
static String handle_slant( String );
static String skip_over_literal( String );
static String skip_over_string( String );
static String skip_comment_tail( String );
static char * contents_of_file( FILE * );
static String skip_to( String, String );
int
main(){
return
! decomment_stdin_all_good()
? fputs( " [not good] ", stderr ), EXIT_FAILURE
: 0;
}
int
decomment_stdin_all_good(){
char *in = contents_of_file( stdin );
return in ? splice_lines( in ), decomment_okay( in ) : 0;
}
void
splice_lines( char *s ){
char c, *p = s;
const char *q = s;
while( c = *p++ = *q++ ){
if( c == '\\' && 0[q] == '\n' ) p--, q++;
}
}
/* process spliced input, removing comments */
int
decomment_okay( String s ){
while( s && *s ){
String p = skip_to( s, "\"'/" );
printf( "%.*s", (int){ p-s }, s );
/**/ if( *p == '\'' ) s = show_literal( p );
else if( *p == '"' ) s = show_string( p );
else if( *p == '/' ) s = handle_slant( p );
else s = p;
}
return s ? 1 : 0;
}
String
show_literal( String s ){
String p = skip_over_literal( s+1 );
return printf( "%.*s", (int){p-s}, s ), p ;
}
String
skip_over_literal( String s ){
String p = skip_to( s, "\n'\\" );
return *p == '\n' || !*p ? p
: *p++ == '\'' ? p
: *p == '\n' || !*p ? p
: skip_over_literal( p+1 );
}
String
show_string( String s ){
String p = skip_over_string( s+1 );
return printf( "%.*s", (int){p-s}, s ), p;
}
String
skip_over_string( String s ){
String p = skip_to( s, "\n\"\\" );
return *p == '\n' || !*p ? p
: *p++ == '"' ? p
: *p == '\n' || !*p ? p
: skip_over_string( p+1 );
}
String
handle_slant( String s ){
return 1[s] == '*' ? putchar( ' ' ), skip_comment_tail( s+2 )
: 1[s] != '/' ? putchar( '/' ), s+1
: skip_to( s+1, "\n" );
}
String
skip_comment_tail( String s ){
String p = strstr( s, "*/" );
return p ? p+2 : strchr( s, 0 );
}
/*** utility functions ***/
char *
contents_of_file( FILE *f ){
typedef unsigned long Index, Extent;
char *r = malloc( 1 );
Index k = 0;
Extent n = 1;
int c;
if( !r ) return r;
r[k] = 0;
while( c = getc( f ), c != EOF ){
if( k+1 >= n ){
Extent n1 = n + n/4 + 1024;
char *r1 = realloc( r, n1 );
if( !r1 ) return free( r ), r = 0;
r = r1, n = n1;
}
r[k++] = c, r[k] = 0;
}
return r;
}
inline String
skip_to( String s, String choices ){
return s + strcspn( s, choices );
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-10 22:35 +0000 |
| Message-ID | <87eejx9tna.fsf@bsb.me.uk> |
| In reply to | #157185 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > > [...] > >>>> Haskell has two big advantages for this exercise: pattern matched >>>> cases and lazy evaluation. [..explanation..] >>> >>> Also one not mentioned: 'input <- getContents'. An analogous >>> functionality in C would read the contents of a file into a >>> character array, which would make the C program easier. >> >> I don't think its analogous at all! 'input' <- getContents does >> no IO. Input is fetched only as needed to perform computations on >> 'input' and processed data will be considered garbage. > > The point I am trying to make here is not about IO but about data > structuring. I understand that Haskell has lazy eval and agree > that there are advantages that accrue from that. Here though I > think the important property is that getContents returns a "data > structure" that is convenient to process in Haskell, specifically > in the context of what an uncommenting program wants to do. An > analogous data structure in C (not counting the lazy evaluation > part, which I've already acknowledged) is a character array. > Let's look at some C code that takes advantage of its primary > data structure for handling strings. As always the problem with "analogous" is what properties are being considered. I see what you mean now. You say it would make the program easier. I wonder if it does. <cut> > Granted, the code below isn't a nice as your Haskell version, but > I think it isn't too bad. How does it strike you? Yes, it seems like a reasonable way to do it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-10 21:17 -0800 |
| Message-ID | <86tuss2a6i.fsf@linuxsc.com> |
| In reply to | #157208 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >> [...] >> >>>>> Haskell has two big advantages for this exercise: pattern matched >>>>> cases and lazy evaluation. [..explanation..] >>>> >>>> Also one not mentioned: 'input <- getContents'. An analogous >>>> functionality in C would read the contents of a file into a >>>> character array, which would make the C program easier. >>> >>> I don't think its analogous at all! 'input' <- getContents does >>> no IO. Input is fetched only as needed to perform computations on >>> 'input' and processed data will be considered garbage. >> >> The point I am trying to make here is not about IO but about data >> structuring. I understand that Haskell has lazy eval and agree >> that there are advantages that accrue from that. Here though I >> think the important property is that getContents returns a "data >> structure" that is convenient to process in Haskell, specifically >> in the context of what an uncommenting program wants to do. An >> analogous data structure in C (not counting the lazy evaluation >> part, which I've already acknowledged) is a character array. >> Let's look at some C code that takes advantage of its primary >> data structure for handling strings. > > As always the problem with "analogous" is what properties are being > considered. I see what you mean now. > > You say it would make the program easier. I wonder if it does. For myself I can say it does. Now that you have looked at what I did, do you still wonder, or has your impression changed?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-12 21:44 +0000 |
| Message-ID | <87wnxm8ztm.fsf@bsb.me.uk> |
| In reply to | #157214 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>> [...] >>> >>>>>> Haskell has two big advantages for this exercise: pattern matched >>>>>> cases and lazy evaluation. [..explanation..] >>>>> >>>>> Also one not mentioned: 'input <- getContents'. An analogous >>>>> functionality in C would read the contents of a file into a >>>>> character array, which would make the C program easier. >>>> >>>> I don't think its analogous at all! 'input' <- getContents does >>>> no IO. Input is fetched only as needed to perform computations on >>>> 'input' and processed data will be considered garbage. >>> >>> The point I am trying to make here is not about IO but about data >>> structuring. I understand that Haskell has lazy eval and agree >>> that there are advantages that accrue from that. Here though I >>> think the important property is that getContents returns a "data >>> structure" that is convenient to process in Haskell, specifically >>> in the context of what an uncommenting program wants to do. An >>> analogous data structure in C (not counting the lazy evaluation >>> part, which I've already acknowledged) is a character array. >>> Let's look at some C code that takes advantage of its primary >>> data structure for handling strings. >> >> As always the problem with "analogous" is what properties are being >> considered. I see what you mean now. >> >> You say it would make the program easier. I wonder if it does. > > For myself I can say it does. Now that you have looked at what I > did, do you still wonder, or has your impression changed? I'm not sure what you mean. I made the remark after studying your program (if that is what you mean). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-12 19:46 -0800 |
| Message-ID | <868sa21i7m.fsf@linuxsc.com> |
| In reply to | #157237 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>> >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> >>>> [...] >>>> >>>>>>> Haskell has two big advantages for this exercise: pattern >>>>>>> matched cases and lazy evaluation. [..explanation..] >>>>>> >>>>>> Also one not mentioned: 'input <- getContents'. An analogous >>>>>> functionality in C would read the contents of a file into a >>>>>> character array, which would make the C program easier. [...] >>> You say it would make the program easier. I wonder if it does. >> >> For myself I can say it does. Now that you have looked at what I >> did, do you still wonder, or has your impression changed? > > I'm not sure what you mean. I made the remark after studying your > program (if that is what you mean). I think a program based on processing a character array is easier than a program that deals with input only one character at a time (as for example using a finite state machine). Here easier means easier to write, easier to understand, and easier to get right. My impression after trying both approaches supports that conclusion. Your comment leads me to think you aren't sure if an approach based on processing the input in a character array is easier than a more conventional one-character-at-a-time approach. Or at least that you weren't sure in the past. My question is meant to ask about what your impression is now.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-13 12:21 +0000 |
| Message-ID | <874kkp99rh.fsf@bsb.me.uk> |
| In reply to | #157247 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> >>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>> >>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>> >>>>> [...] >>>>> >>>>>>>> Haskell has two big advantages for this exercise: pattern >>>>>>>> matched cases and lazy evaluation. [..explanation..] >>>>>>> >>>>>>> Also one not mentioned: 'input <- getContents'. An analogous >>>>>>> functionality in C would read the contents of a file into a >>>>>>> character array, which would make the C program easier. > [...] >>>> You say it would make the program easier. I wonder if it does. >>> >>> For myself I can say it does. Now that you have looked at what I >>> did, do you still wonder, or has your impression changed? >> >> I'm not sure what you mean. I made the remark after studying your >> program (if that is what you mean). > > I think a program based on processing a character array is easier > than a program that deals with input only one character at a time > (as for example using a finite state machine). Here easier means > easier to write, easier to understand, and easier to get right. My > impression after trying both approaches supports that conclusion. > Your comment leads me to think you aren't sure if an approach based > on processing the input in a character array is easier than a more > conventional one-character-at-a-time approach. Or at least that you > weren't sure in the past. My question is meant to ask about what > your impression is now. I have not tried both, which is why I was not sure enough to agree with your assessment. And if I did try both, I don't think my personal assessment would be worth much because (unless I hit some fundamental unforeseen problem), I almost always find the second version of any program easier (in your sense of the word). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-24 11:35 -0800 |
| Message-ID | <861rffyp2t.fsf@linuxsc.com> |
| In reply to | #157252 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: [...] >> I think a program based on processing a character array is easier >> than a program that deals with input only one character at a time >> (as for example using a finite state machine). Here easier means >> easier to write, easier to understand, and easier to get right. My >> impression after trying both approaches supports that conclusion. >> Your comment leads me to think you aren't sure if an approach based >> on processing the input in a character array is easier than a more >> conventional one-character-at-a-time approach. Or at least that you >> weren't sure in the past. My question is meant to ask about what >> your impression is now. > > I have not tried both, which is why I was not sure enough to agree > with your assessment. Okay. > And if I did try both, I don't think my > personal assessment would be worth much because (unless I hit some > fundamental unforeseen problem), I almost always find the second > version of any program easier (in your sense of the word). Sure, the second program will likely be easier than the first. But can you not get a good sense of the two approaches, even if the particular programs are influenced by the history of the order in which they were tried? This question isn't meant as rhetorical. In many (or most?) cases I think I get a pretty good sense of how different approaches compare, even if approach A programs are all done before approach B programs. I'm curious to know more about your comment, since I find it surprising.
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2020-12-31 00:46 +0100 |
| Message-ID | <q94quflgje4u1oun4gf1g2hdv4p3s1h4r4@4ax.com> |
| In reply to | #157703 |
On Thu, 24 Dec 2020 11:35:38 -0800, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote:
>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>[...]
>
>>> I think a program based on processing a character array is easier
>>> than a program that deals with input only one character at a time
>>> (as for example using a finite state machine). Here easier means
>>> easier to write, easier to understand, and easier to get right. My
>>> impression after trying both approaches supports that conclusion.
>>> Your comment leads me to think you aren't sure if an approach based
>>> on processing the input in a character array is easier than a more
>>> conventional one-character-at-a-time approach. Or at least that you
>>> weren't sure in the past. My question is meant to ask about what
>>> your impression is now.
>>
>> I have not tried both, which is why I was not sure enough to agree
>> with your assessment.
>
>Okay.
>
>> And if I did try both, I don't think my
>> personal assessment would be worth much because (unless I hit some
>> fundamental unforeseen problem), I almost always find the second
>> version of any program easier (in your sense of the word).
>
>Sure, the second program will likely be easier than the first.
>But can you not get a good sense of the two approaches, even
>if the particular programs are influenced by the history of
>the order in which they were tried?
>
>This question isn't meant as rhetorical. In many (or most?)
>cases I think I get a pretty good sense of how different
>approaches compare, even if approach A programs are all done
>before approach B programs. I'm curious to know more about
>your comment, since I find it surprising.
this is my try
#include <stdio.h>
main()
{int c, cp;
for(;(c=getchar())!=EOF;)
{if(c=='/')
{cp=c;
if((c=getchar())=='*')
{for(cp='a';(c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
else if(c=='/')
{for(;cp!='\n'&&(cp=getchar())!=EOF;);if(cp!=EOF)putchar(cp);}
else if(c=='\''||c=='\"')
for(putchar('/'),putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
else if(c!=EOF) {putchar(cp); putchar(c);cp=c;}
else break;
}
else if(c=='\''||c=='\"')
for(putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
else {putchar(c);cp=c;}
if(cp==EOF)break;
}
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2020-12-31 00:52 +0100 |
| Message-ID | <uj4quf5csaup4dlhr52tgt413ffpanruc7@4ax.com> |
| In reply to | #157918 |
On Thu, 31 Dec 2020 00:46:49 +0100, Rosario19 <Ros@invalid.invalid>
wrote:
>On Thu, 24 Dec 2020 11:35:38 -0800, Tim Rentsch
><tr.17687@z991.linuxsc.com> wrote:
>
>>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>[...]
>>
>>>> I think a program based on processing a character array is easier
>>>> than a program that deals with input only one character at a time
>>>> (as for example using a finite state machine). Here easier means
>>>> easier to write, easier to understand, and easier to get right. My
>>>> impression after trying both approaches supports that conclusion.
>>>> Your comment leads me to think you aren't sure if an approach based
>>>> on processing the input in a character array is easier than a more
>>>> conventional one-character-at-a-time approach. Or at least that you
>>>> weren't sure in the past. My question is meant to ask about what
>>>> your impression is now.
>>>
>>> I have not tried both, which is why I was not sure enough to agree
>>> with your assessment.
>>
>>Okay.
>>
>>> And if I did try both, I don't think my
>>> personal assessment would be worth much because (unless I hit some
>>> fundamental unforeseen problem), I almost always find the second
>>> version of any program easier (in your sense of the word).
>>
>>Sure, the second program will likely be easier than the first.
>>But can you not get a good sense of the two approaches, even
>>if the particular programs are influenced by the history of
>>the order in which they were tried?
>>
>>This question isn't meant as rhetorical. In many (or most?)
>>cases I think I get a pretty good sense of how different
>>approaches compare, even if approach A programs are all done
>>before approach B programs. I'm curious to know more about
>>your comment, since I find it surprising.
>
>this is my try
>#include <stdio.h>
>main()
>{int c, cp;
> for(;(c=getchar())!=EOF;)
> {if(c=='/')
> {cp=c;
> if((c=getchar())=='*')
>{for(cp='a';(c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
> else if(c=='/')
>{for(;cp!='\n'&&(cp=getchar())!=EOF;);if(cp!=EOF)putchar(cp);}
> else if(c=='\''||c=='\"')
>for(putchar('/'),putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
> else if(c!=EOF) {putchar(cp); putchar(c);cp=c;}
> else break;
> }
> else if(c=='\''||c=='\"')
>for(putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
> else {putchar(c);cp=c;}
> if(cp==EOF)break;
> }
> return 0;
>}
ok
#include <stdio.h>
main()
{int c, cp;
for(;(c=getchar())!=EOF;)
{if(c=='/')
{cp=c;
if((c=getchar())=='*')
{for(cp='a';(c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
else if(c=='/')
{for(;cp!='\n'&&(cp=getchar())!=EOF;);if(cp!=EOF)putchar(cp);}
else if(c=='\''||c=='\"')
for(putchar('/'),putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
else if(c!=EOF) {putchar(cp); putchar(c);cp=c;}
else {putchar(cp); break;}
}
else if(c=='\''||c=='\"')
for(putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
else {putchar(c);cp=c;}
if(cp==EOF)break;
}
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-31 00:34 -0800 |
| Message-ID | <865z4iv0fy.fsf@linuxsc.com> |
| In reply to | #157919 |
Rosario19 <Ros@invalid.invalid> writes:
[...]
> this is my try
>
> #include <stdio.h>
> main()
> {int c, cp;
> for(;(c=getchar())!=EOF;)
> {if(c=='/')
> {cp=c;
> if((c=getchar())=='*')
> {for(cp='a';(c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
> else if(c=='/')
> {for(;cp!='\n'&&(cp=getchar())!=EOF;);if(cp!=EOF)putchar(cp);}
> else if(c=='\''||c=='\"')
> for(putchar('/'),putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
> else if(c!=EOF) {putchar(cp); putchar(c);cp=c;}
> else {putchar(cp); break;}
> }
> else if(c=='\''||c=='\"')
> for(putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
> else {putchar(c);cp=c;}
> if(cp==EOF)break;
> }
> return 0;
> }
Try running your program on this input
enum {
QUOTE = '\'',
};
/* Here is a comment */
which is a valid C translation unit. Does it produce what
you think it should?
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2021-01-01 08:23 +0100 |
| Message-ID | <b9jtufl80vlg5phutaksc29vealiaa93ee@4ax.com> |
| In reply to | #157929 |
On Thu, 31 Dec 2020 00:34:09 -0800, Tim Rentsch wrote:
>Rosario19 <Ros@invalid.invalid> writes:
>
>[...]
>> this is my try
>>
>> #include <stdio.h>
>> main()
>> {int c, cp;
>> for(;(c=getchar())!=EOF;)
>> {if(c=='/')
>> {cp=c;
>> if((c=getchar())=='*')
>> {for(cp='a';(c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
>> else if(c=='/')
>> {for(;cp!='\n'&&(cp=getchar())!=EOF;);if(cp!=EOF)putchar(cp);}
>> else if(c=='\''||c=='\"')
>> for(putchar('/'),putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
>> else if(c!=EOF) {putchar(cp); putchar(c);cp=c;}
>> else {putchar(cp); break;}
>> }
>> else if(c=='\''||c=='\"')
>> for(putchar(c),cp='a';cp!=c&&(cp=getchar())!=EOF;putchar(cp));
>> else {putchar(c);cp=c;}
>> if(cp==EOF)break;
>> }
>> return 0;
>> }
>
>Try running your program on this input
>
> enum {
> QUOTE = '\'',
> };
>
> /* Here is a comment */
>
>which is a valid C translation unit. Does it produce what
>you think it should?
this use ungetc on stdin and would remove all \\n from the input (if
in the code and not in the string) it should be bugged too
#include <stdio.h>
main() // use ungetc on stdin, remove \\n
{int c,cp,cpp;
for(cp='a';cp!=EOF&&(c=getchar())!=EOF;)
{if(c=='*'&&cp=='/') {for(;(
c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
else if(c=='/')
{if(cp=='/') {for(;cp!='\n'&&(cp=getchar())!=EOF; );
if(cp!=EOF)putchar(cp);}
else {cp=c;
if((c=getchar())=='*') {for(; (
c=getchar())!=EOF;cp=c)if(cp=='*'&&c=='/')break;}
else if(c=='/')
{for(;cp!='\n'&&(cp=getchar())!=EOF; ); if(cp!=EOF)putchar(cp);}
else if(c==EOF) {putchar(cp);
break;}
else if(c=='\\'||c=='\''||c=='\"') ungetc(c,stdin);
else {putchar(cp);
putchar(c);}
}
}
else if(c=='\\'){cpp=cp;cp=c;
if((c=getchar())==EOF){putchar(cp);break;}
else if (c=='\n') cp=cpp;
else
{putchar(cp);putchar(c);}
} // there would be some bug cp=cpp is ok
else
if(c=='\''||c=='\"'){for(putchar(c),cpp=cp,cp='a';(cpp!='\\'&&cp!=c)&&(cp=getchar())!=EOF;putchar(cp))cpp=cp;if(cp!=EOF)cp=cpp;
}
else {putchar(c);cp=c;}
}
return 0;
}
[toc] | [prev] | [next] | [standalone]
Page 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web