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 | 19 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 20 of 20 — ← Prev page 1 … 18 19 [20]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-01-26 11:37 +0000 |
| Message-ID | <87ft2ovshr.fsf@bsb.me.uk> |
| In reply to | #158612 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
> --- I tried this program ---
> #include <stdio.h>
>
> #define _DeFiNe_ #define
> _DeFiNe_ short
> #undef _DeFiNe_
>
> unsigned short A;
> main()
> {
> unsigned short B;
> B = A;
> printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
> #ifndef short
> printf("!defined!\n");
> #endif
> }
I think a simpler, more modern, program would make it easier to comment.
People might be distracted from the question you are asking by the
various UB constructs in this version.
Also, I think you should say, right up front, that you are not treating
this as a C program. As a C program it has syntax errors, but as source
to a C macro processor it's fine.
> --- My MCP produced this ---
> // 11 lines from the include file snipped
> #define short
>
> unsigned short A;
> main()
> {
> unsigned short B;
> B = A;
> printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
> printf("!defined!\n");
> }
>
> --- GPP (LCC -EP) produced this ---
> // 247 lines from the include snipped
>
> #define short
>
>
> unsigned short A;
> main()
> {
> unsigned short B;
> B = A;
> printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
>
> printf("!defined!\n");
>
> }
OK, so far. The only difference is that GPP (LCC -EP) (which I don't
know) has put in a few more spacing characters here and there.
> --- Both programs compiled and produced exactly the same output --
> 2 2 2
> !defined!
>
> This surprised me.
Just to be sure I've got this clear: you ran the original through the
pre-processor of two different C compilers and then compiled the
resulting program with that C compiler, thereby passing the source
through the pre-processor twice? Using gcc's command-line syntax, you
are doing
gcc -E source.c | gcc -xc -
Have I got that right? If so, I am not surprised that both programs
produce the same result since they are essentially identical, but I am
surprised that the sizes are 2, so I suspect I don't know what you are
doing.
If you have access to gcc, what do you get for this command?
> This surprised me. I understand why it does this on my compiler (it's
> what I was trying for), because the #define short
> is being handled by the limited built in internal pre-processor, and the
> #ifdef is handled by MCP which didn't see the definition for "short".
>
> But I don't understand LCC/GCC - clearly it didn't see the
> definition of "short" (which I didn't expect), and the #define short
> DID make it past GPP - so why didn't it get a compile error?
>
> As it turns out anything in the passed "#" command gets
> ignored (ie: #farkle) - shouldn't this cause an error if it
> occurs in the source AFTER GPP. Are lines beginning with '#'
> handled/removed by a later "translation phase"?
I found this description and question very hard to follow. It doesn't
help that I don't know what MCP, LCC/GCC and GPP are (though I guess LCC
might be Fraser and Hanson's portable C compiler).
> And Borland Turbo-C DOES generate errors:
> ---
> Error a.c 3: # operator not followed by macro argument name
> Error a.c 4: Declaration syntax error
> Error a.c 11: Undefined symbol 'A' in function main
> *** 3 errors in Compile ***
> ---
Now this makes me think you are treating the original code as C code
when it isn't. No standard C compiler should accept it without
complaint (sadly, that is pretty much the most the standard requires --
a diagnostic). Pre-ANSI compilers are not so constrained. Are you
talking about a old K&R C compilers here?
> What's GCC doing with a '#'line getting past GPP. Does the standard cover
> this or is it just something "special" with GCC.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-27 08:04 -0800 |
| Message-ID | <8635yml61n.fsf@linuxsc.com> |
| In reply to | #158605 |
Dave Dunfield <dave.dunfield@gmail.com> writes: [..on how to produce attribution lines..] > This isn't as easy as you might think in gg/CHROME. [...] I strongly recommend finding both a better newsreader and a better source for access to news groups. Google groups is just a big bucket of shit now, which is sad because it used to be actually pretty useful.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2021-01-27 19:16 +0300 |
| Message-ID | <20210127191623.7d050250a4226a8f85573258@g{oogle}mail.com> |
| In reply to | #158655 |
Tim Rentsch:
> I strongly recommend finding both a better newsreader and
> a better source for access to news groups. Google groups
> is just a big bucket of shit now, which is sad because it
> used to be actually pretty useful.
Yet sensitive people abhorred GoogleGropus in its infancy:
http://twovoyagers.com/improve-usenet.org
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-27 23:38 -0800 |
| Message-ID | <86pn1pjyth.fsf@linuxsc.com> |
| In reply to | #158657 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Tim Rentsch:
>
>> I strongly recommend finding both a better newsreader and
>> a better source for access to news groups. Google groups
>> is just a big bucket of shit now, which is sad because it
>> used to be actually pretty useful.
>
> Yet sensitive people abhorred GoogleGropus in its infancy:
>
> http://twovoyagers.com/improve-usenet.org
I'm not sure we are talking about the same thing. In any
case I didn't say that the early Google groups was great,
only that it was pretty useful. And I'm not including
anything to do with posting rather but just searching and
reading.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-27 13:43 -0800 |
| Message-ID | <86tur2jbtf.fsf@linuxsc.com> |
| In reply to | #158594 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
[..quoted text rearranged for convenience of responding..]
> Please do let me know of any other/continued problems you find.
> I'm kindof interested in making this work in the best possible
> way.
I have some comments below. Probably some of them will be about
layout or other style issues, but most should be about program
structure. As a warning, my comments might be rather harshly
worded in some cases, but please don't take that personally.
The comments are meant to be about the code, not about you.
> If you want, I can probably easily modify it to output spaces
> instead of characters in comment (and preserve all [\<newline>]
> thereby making the output exactly the same size/shape as the
> original. I know this was mentioned in recent messages, please let
> me know if you would like me to look into this.
For now I think just stick to simply removing // comments (but not
removing the ending newlines for those), and replacing /*...*/
comments by a single space.
> /*
> * whole line comments could easily be absent and should not
> * count against to 25 lime function body limit.
> *
I suggest putting any whole line comments either just before or
just after the function they relate to. A line of code can be
marked with a //[n] indicator if needed to identify where in
the function body a particular whole line comments is meant to
apply.
> unsigned short // at least 16 bits to insure '& 0xFF00' works
> Cp, // Pending input character
> C0, // Last character read
> Enl; // EscapeNewLine seen
> unsigned char
> C1, // Previous character read
> Imode; // Input mode
You have the germ of a good idea here (and carried forward in
rdchar1(), discussed below), but the names chosen and the types
used get in the way. There is no reason to use either unsigned
short or unsigned char: characters should be of type 'int', the
counter should be just 'unsigned', and Imode shouldn't be a
character at all, but some enum type. The names (ignoring the
style of initial capital letter) used for the characters go
pretty strongly against the mental grain. I suggest this (I am
using all lower case but please don't focus on that):
int c0, c1, c2; // { last, current, next } character
int s_type; // to remember '\'' or '"' for strings
unsigned n_lcs; // number of line continuations
// state variable to be declared later
> // Line continuation sequences occurring within comments are
> // removed. But what about comments starting with [/\<newline>*]
> // [/<newline>/] ?
Presumably you meant [/\<newline>/] at the end there.
> // I decided to remove them,
That is the right thing to do
> // but if you prefer those [\<newline>]s to
> // remain, change all [/*1] in this file to [//1], [...]
It would be nicer if this sort of conditional behavior were done
using regular code and not using either comments or the C
pre-processor.
> // Read a single character, ignoring C sequence: \<nl>
> // Added to simulates line splicing performed by "official" CPP.
> unsigned rdchar1(void)
> {
> C1 = C0;
> for(;;) {
> if(C0 = Cp)
> Cp = 0;
> else
> C0 = getc(stdin);
> if(C0 != '\\') // Not an escape
> return C0;
> if((C0 = getc(stdin)) != '\n') { // Not Escaped Newline
> Cp = C0;
> return C0 = '\\'; }
> /*1*/ ++Enl; // So we can re-insert it in output
> //2*/ if(!Imode)
> //2*/ fputs("\\\n", stdout);
> }
> }
First the code has a hidden brace (just before the /*1*/ line).
Please don't do that.
Looking at the semantics, I can't help the feeling that the code
is both working too hard and is too hard to understand. Using
the declarations I wrote above, it can be written more concisely
thus (also I changed the name - 'rdchar1' is horrible):
int
read_next(){
c0 = c1, n_lcs = 0, c1 = c2, c2 = getchar();
while( c1 == '\\' && c2 == '\n' ){
n_lcs++, c1 = getchar(), c2 = getchar();
}
return c1;
}
Notice the code is simpler because the invariant is easier to
write. The values in c0, c1, and c2 are consistent at all times:
last, current, and next. The number of LCs (in n_lcs) goes with
the character in c1 so it is initialized to zero at the start of
the routine. Do you see how this writing corresponds (even if
not exactly) to your rdchar1() function?
> // Read one character, excluding content of comments
> unsigned char rdchar2(void)
> {
> for(;;) {
> // Assumes 8-bit char set, not including 0 and EOF is >255
> if(rdchar1() & 0xFF00)
> return 0;
> // changing this to multiple 'if's could eliminate the 'switch' line
> switch(Imode) {
> case '*' : // Inside '/*' comment
> if((C1 == '*') && (C0 == '/')) { // Ending '/*'
> Imode = Enl = 0;
> C0=' '; } // Replace /*...*/ with single space
> continue;
> case '/' : // Inside '//' comment
> if(C1 == '\n') {
> Imode = Enl = 0;
> break; }
> continue;
> case 0 : // No special mode
> // could be considered as two lines in one, although it's a construct I
> // sometimes use if a single 'switch' is the only thing within an 'if'
> if(C1 == '/') switch(C0) {
> case '*': // Starting '/*' comment
> case '/': // Starting '//' comment
> Imode = C0;
> continue; } }
> return C1; }
> }
>
Style comments: the layout is horrible. The name rdchr2() doesn't
tell me anything. More hidden braces. Combinations of break's and
continue's (break's go with the switch(), continue's go with the for()
and are there to pass over the return statement at the end), along
with the if()/switch() -- all of these make the code very hard to
decipher.
Re-writing to clean up the layout and better show the control flow:
// Read one character, excluding content of comments
unsigned char
read_skipping_comment_characters( void )
{
for(;;) {
if(rdchar1() & 0xFF00)
return 0;
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C0 == '/')) { // Ending '/*'
Imode = Enl = 0;
C0=' '; // Replace /*...*/ with single space
}
break;
case '/' : // Inside '//' comment
if(C1 == '\n') {
Imode = Enl = 0;
}
break;
case 0 : // No special mode
if(C1 == '/' && (C0 == '*' || C0 == '/') ){
Imode = C0;
break;
}
/* fallthrough */
default:
return C1;
}
}
}
Now at least we can see what's going on. The code is kind of
strange though. Broadly speaking there are two ways to approach
this problem. One, with a state machine. Two, using a lexing or
token scanning type algorithm. The function here shows that both
are going on - the function as a whole is kind of lexing, but
internally it uses a state machine. That's more complicated than it
needs to be.
> // Read characters, and hande '\\' escape sequences
> // Also enter quote input mode if quote character is seen
> void handle_esc(void)
> {
> switch(rdchar2()) {
> case '\\': // Escape
> putc(C1, stdout);
> rdchar2();
> case 0 : // EOF
> return;
> case '"':
> case'\'':
> if(Imode == C1)
> Imode = 0;
> else if(!Imode) {
> Imode = C1; } }
> }
>
> int main(void)
> {
> rdchar2(); // First call to rdchar2 will return 0;
> do {
> handle_esc();
> [... output <bs><nl> per Enl ...]
> putc(C1, stdout);
> } while(!(C0 & 0xFF00)); // Till EOF has been read
> }
At this point I am lost. The code seems very confused. Normally I
would go through and try to fix things up to the point where it will
work, but I kind of gave up here; I thought would be easier to
write a whole new program from scratch than try to fix this one.
Note by the way that the LCs are output only here, but there is
more than one place that rdchar2() is called, which means some
LCs are potentially lost (ie, not transmitted to the output, or
not transmitted in the right places).
Having shown stuff done for the bottom of the newly written
program (with the character reading routine read_next()), let's
look at the top of the program, that is, mainly, main():
#include <stdio.h>
typedef enum {
W_zero, // ground state
W_slant, // a '/' was seen
W_c90, // in a C90-style comment
W_c99, // in a C99-style comment
W_string, // in a string or character constant
W_done, // premature ending - error detected
} What;
static What (*go[ W_done ])( int );
static int read_next( void );
static void out_c1( void );
static void out_lcs( unsigned );
static int c0, c1, c2, s_type;
static unsigned n_lcs;
int
main(){
What w = W_zero;
c2 = getchar();
while( w != W_done && read_next() != EOF ){
w = go[w]( c1 );
}
return 0;
}
The variable 'w' has the state of the FSM. The loop calls one of
the "go" routines, depending on what state the top-level loop is
in. Note that 'w' is local and set only here, and read_next() is
called in only one place, in the test of the while() loop. The
state of the program is thus quite simple. Because there is only
one state for both string literals and character constants, there
needs to be some global state for that, and that is the variable
's_type' (and some of the "go" routines needs to set or test
that).
Here are skeletons for the "go" routines:
What
go_zero( int c ){
return W_done; // dummy to be replaced
}
What
go_slant( int c ){
return W_done; // dummy to be replaced
}
What
go_c90( int c ){
return W_done; // dummy to be replaced
}
What
go_c99( int c ){
return W_done; // dummy to be replaced
}
What
go_string( int c ){
return W_done; // dummy to be replaced
}
static What (*go[ W_done ])( int ) = {
go_zero,
go_slant,
go_c90,
go_c99,
go_string
};
The "go" routines can be written in a small number of lines each
(no more than 40 or 50 lines altogether).
It's convenient for there to be two output routines, one for the
character in c1 together with any preceeding line continuation
sequence, and for for just an LC sequence without any character
attached.
void
out_c1(){
out_lcs( n_lcs ), putchar( c1 );
}
void
out_lcs( unsigned n ){
while( n-- > 0 ) fputs( "\\\n", stdout );
}
I don't know how much sense all this makes to you. I'm trying to
provide what constructive comments I can, but unfortunately am
hampered by finding the submitted program code confusing. Maybe
this will give you a new idea for how to approach the problem, or
an idea for how to simplify your existing code. If you're
feeling adventurous you could try filling in the "go" routines
and see how that goes (no pun intended).
Do you have questions, or any other reactions?
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-28 03:16 -0800 |
| Message-ID | <3904b733-3255-4c7a-a95f-8d65d6950dfcn@googlegroups.com> |
| In reply to | #158668 |
On Wednesday, January 27, 2021 at 4:43:25 PM UTC-5, Tim Rentsch wrote:
> I have some comments below... As a warning, my comments might be rather
> harshly worded in some cases, but please don't take that personally.
> The comments are meant to be about the code, not about you.
At first I had decided not to respond, but then I thought you at least
deserve to know where I have been coming from (If you want to).
-- Moved up from the end --
> Do you have questions, or any other reactions?
No, I understand what you are saying. I will give you my responses to your
concerns, I don't expect you to "like" them.
I get that you hate my personal style and there are (personal) reasons I
tend to code that way (so It really is in a way "about me" :). It was not
clear to me in the original posting that style was a big factor. I know my
style is not what some like, but for "Quick and Dirty" programming I do
what works best for me. If I were publishing code in/for a book or otherwise
expecting it to go beyond a Usenet discussion I would have taken the effort
to make it look much more like many other people expect.
And FYI - a fair number of people I have worked with/for didn't like my style
at first, but later told me thay liked and appreciated it - to each his own.
> > /*
> > * whole line comments could easily be absent and should not
> > * count against to 25 lime function body limit.
> > *
> I suggest putting any whole line comments either just before or
> just after the function they relate to....
I like comments on functions, but for giving information on what I'm doing
in a certain part of the code (which I often to for myself in tricky parts
- you never know how long it will be before you might have to visit it again),
I like to put those comments in that part. I didn't realize that whole line
comments near where they apply would be against the "spirit" of the
exercise, and I thought my idea "whole line comments shouldn't apply against
the 25 line limit" was pretty clear and reasonable - again, not thinking it
was about "style" I was thinking it would be ok without any comments, and
added the ones I did for reader benefit.
> > unsigned short // at least 16 bits to insure '& 0xFF00' works
> > Cp, // Pending input character
> > C0, // Last character read
> > Enl; // EscapeNewLine seen
> > unsigned char
> > C1, // Previous character read
> > Imode; // Input mode
>
> You have the germ of a good idea here (and carried forward in
> rdchar1(), discussed below), but the names chosen and the types
Again, didn't realize names used would count for the "exercise". I tend to
use small easily typed names for Q&D program (which this started as), and
to me "rdchr" is nearly as descriptive as "read_a_character_from_the_input"
but a LOT faster to type and less prone to typos. When I added another layer
to reading character to account for the [\\<newline>] issue, I didn't pick
new name because ...1 and ...2 were just (to me) two levels of how a character
got read.
> used get in the way. There is no reason to use either unsigned
> short or unsigned char: characters should be of type 'int'.
Personal style. People who "grew up" on big systems tend to not think about
size and go with default type attributes. When you have worked as much as I
have on systems where "int" and/or signed operations can be noticeably more
"expensive" in resources that other types, you tend to do things in ways which
could generate simpler code. And I've always thought that (except with some
specific tools) smaller/simpler types on most systems don't cost you even if
they don't save you much either.
> counter should be just 'unsigned', and Imode shouldn't be a
> character at all, but some enum type. The names (ignoring the
> style of initial capital letter) used for the characters go
> pretty strongly against the mental grain. I suggest this (I am
> using all lower case but please don't focus on that):
More "personal style" I did things simple because of the limitations of the
exercise. Also, I tend to use all lower-case for locals, Beginning with Upper
for globals and all Upper for #defines etc. not 100% consistent in this but I
do it a lot.
> > // Line continuation sequences occurring within comments are
> > // removed. But what about comments starting with [/\<newline>*]
> > // [/<newline>/] ?
> Presumably you meant [/\<newline>/] at the end there.
I did.
> > // I decided to remove them,
> That is the right thing to do
Except that [.../\<newline>* */... /\<newline>* */...]
could result in the [...]s collecting into very long lines when the
<newlines> are not retained. It should be "obvious" that replacing
coments with single spaces would remove any <newline> embedded in those
comments, but it might not be as obvious to someone that these newlines
were "inside" the comment - it takes effect at the '/', but doesn't
actually get recognized till the '*'...
> > // but if you prefer those [\<newline>]s to
> > // remain, change all [/*1] in this file to [//1], [...]
> It would be nicer if this sort of conditional behavior were done
> using regular code and not using either comments or the C
> pre-processor.
Remember the 25 line limit? I was presenting how the program could be
changed if it was desired to do something a little different. And yes the
[//] lines were assumed not to count against the limit. I only did all
this because I pretty much knew that "someone" would argue it if I had
just chosen one or the other.
> First the code has a hidden brace (just before the /*1*/ line).
> Please don't do that.
>.. Lots more comments on how bad my style is throughout trimmed ...
This doesn't apply to your "challenge" and I don't really think it's
something you should need to know, but I'm not young (pretty sure you
know this due to my mentioning having programmed in the 70's), but what
you might not know is that I have some pretty significant vision issues.
Because of this, I tend to work using my own editor which uses a 25x80 text
screen, usually enlarged to fill a 27 (or in some cases 24) inch monitor.
It helps me see what I'm doing a lot better.
Because of the 25 lines, I *abhor* working on code where block braces
have been spread out over lots of nicely indented and otherwise blank
lines. So I do something unpopular with some and stack my braces at the
ends of the lines where the block level changes.
This might not have shown in my code due to the newsgroup, but what *I* do
is to be adamant about horizontal spacing. For C I use tabs at 4-space
intervals - my editor defaults to this for .C .H etc, and you can clearly
follow my codes block just by seeing how the lines are indented. And except
for places I "wanted" a blank line, no screen lines are wasted.
So (just a "fun" statement): You appear to assume that anyone who codes has
good enough vision to comfortably do so in a manner that will please the
majority of people. (Please don't do that. :)
FWIW, if you use the RFCGG program I posted a few messages back, it will
"mostly" restore my original formatting. There will be a few single non-
block contained lines you have to fix manually to get the tabs right, but
it will be restores to mostly way it should have looked (and don't worry
I will try to refrain from posting more of my "horrible" code! :)
> Looking at the semantics, I can't help the feeling that the code
> is both working too hard and is too hard to understand. Using
> the declarations I wrote above, it can be written more concisely
> thus (also I changed the name - 'rdchar1' is horrible):
> int read_next(){
> c0 = c1, n_lcs = 0, c1 = c2, c2 = getchar();
I avoided stacking assignments in one statement because I felt that
this was using a capability of C to sidestep the 25 line restriction.
I was mentally translating "25 lines" to "25 C operations".
You'll note that I commented when I put a single if/switch block on one
line.
> while( c1 == '\\' && c2 == '\n' ){
> n_lcs++, c1 = getchar(), c2 = getchar();
> }
> Notice the code is simpler because the invariant is easier to
> write. The values in c0, c1, and c2 are consistent at all times:
> last, current, and next. The number of LCs (in n_lcs) goes with
> the character in c1 so it is initialized to zero at the start of
> the routine. Do you see how this writing corresponds (even if
> not exactly) to your rdchar1() function?
Sorry but No - it misses the operations with [Cp] which is a Pending character
needed to detect '\<newline>' in accordance with the standard. As I mentioned
in a comment I probably would have done it differently had I know about this
"feature" at the start. I haven't taken the time to look at the rest of your
program to see if you handled it somewhere else.
> Combinations of break's and
> continue's (break's go with the switch(), continue's go with the for()
> and are there to pass over the return statement at the end), along
> with the if()/switch() -- all of these make the code very hard to
> decipher.
But legal C ... which is what I understood the challenge to be about
(avoid [goto] and keep functions below 25 lines)
> Re-writing to clean up the layout and better show the control flow:
I haven't bothered to check your code, but quite possible as this was code
I hacked at to account for the "feature" I hadn't know about at the start.
As far as I could tell I still met the requirements of the "challenge" so
I didn't further optimize it for clarity.
> At this point I am lost. The code seems very confused. Normally I
> would go through and try to fix things up to the point where it will
> work, but I kind of gave up here; I thought would be easier to
> write a whole new program from scratch than try to fix this one.
Sorry for the confusion. I didn't think it was actually that bad, only
four functions which at 17, 25, 16 and 25 non-comment line each (of which
a few are just function definitions and block delimiter lines, making the
number of code generating C lines even less.. I believe it is all legal C,
and the "challenge" was about limits on how big things could be and specified
C features that could not be used, so my code wasn't designed to be overly
readable. If it were a "challenge" about style my entry would have been a
LOT different!
Btw, if the variable names were causing you real problems, it is a small
program and most editors support global substitution. For the block
delimiters, I'm pretty sure there are some "pretty printers" which would
take care of that two.
> Note by the way that the LCs are output only here, but there is
> more than one place that rdchar2() is called, which means some
> LCs are potentially lost (ie, not transmitted to the output, or
> not transmitted in the right places).
I had reasons for ordering things the way I did, so I (personally)
don't think so, but feel free to advise me of any actual issues like
that you might find (that's what I was looking for).
When I asked you for further feedback I was assuming that since you had
posted only a couple and easily fixed problem, I was asking for you to
be sure to let me know of any other functionality problems you observed.
Your post to another guy suggested that you were trying quite a bit of
code through them.
> Here are skeletons for the "go" routines:
> .. quite a few function definitions trimmed ..
Again I clearly didn't understand the "challenge". I thought the 25 line
function limit implied "less code desirable" and that "many small functions"
would be "frowned upon".
> I don't know how much sense all this makes to you. I'm trying to
> provide what constructive comments I can, but unfortunately am
> hampered by finding the submitted program code confusing.
Makes good sense, and had I expected the code to be reviewed for more
than "what it does", I probably would have made some style changes
before sending it.
> If you're feeling adventurous you could try filling in the "go" routines
> and see how that goes (no pun intended).
I don't think so. I've already wasted far too much time on this, and having
other responsibilities to attend to, I likely will be away from this group
for a while. If/when I check back and see something worth addressing I will
handle it then. It was "fun" while it lasted!
Dave
Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-28 06:42 -0500 |
| Message-ID | <ruu7ua$cro$1@dont-email.me> |
| In reply to | #158679 |
On 1/28/21 6:16 AM, Dave Dunfield wrote: > On Wednesday, January 27, 2021 at 4:43:25 PM UTC-5, Tim Rentsch wrote: ... >> used get in the way. There is no reason to use either unsigned >> short or unsigned char: characters should be of type 'int'. > > Personal style. People who "grew up" on big systems tend to not think about > size and go with default type attributes. When you have worked as much as I > have on systems where "int" and/or signed operations can be noticeably more > "expensive" in resources that other types, you tend to do things in ways which > could generate simpler code. And I've always thought that (except with some > specific tools) smaller/simpler types on most systems don't cost you even if > they don't save you much either. Keep in mind the integer promotions: "The following may be used in an expression wherever an int or unsigned int may be used: — An object or expression with an integer type (other than int or unsigned int) whose integer conversion rank is less than or equal to the rank of int and unsigned int. — A bit-field of type _Bool, int, signed int, or unsigned int. If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int." (6.3.1.1p2). In any context where the integer promotions apply (and there's a lot of such contexts, including any context where the "usual arithmetic conversions" apply), use of any of the other types described above doesn't actually save you anything unless the implementation can prove that the end result would be unchanged by using a faster type than 'int' or 'unsigned int' - and even then, only if it actually uses that fact to generate such code.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-28 13:01 -0800 |
| Message-ID | <86czxokc73.fsf@linuxsc.com> |
| In reply to | #158679 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
> On Wednesday, January 27, 2021 at 4:43:25 PM UTC-5, Tim Rentsch wrote:
>
>> I have some comments below... As a warning, my comments might be rather
>> harshly worded in some cases, but please don't take that personally.
>> The comments are meant to be about the code, not about you.
>
> At first I had decided not to respond, but then I thought you at least
> deserve to know where I have been coming from (If you want to).
>
> -- Moved up from the end --
>
>> Do you have questions, or any other reactions?
>
> No, I understand what you are saying. I will give you my responses to
> your concerns, I don't expect you to "like" them.
My primary goal is communication. As long as I understand what
you're saying, and vice versa, personal reactions are not very
important.
> I get that you hate my personal style and there are (personal) reasons
> I tend to code that way (so It really is in a way "about me" :). It
> was not clear to me in the original posting that style was a big
> factor. I know my style is not what some like, but for "Quick and
> Dirty" programming I do what works best for me. If I were publishing
> code in/for a book or otherwise expecting it to go beyond a Usenet
> discussion I would have taken the effort to make it look much more
> like many other people expect.
>
> And FYI - a fair number of people I have worked with/for didn't like
> my style at first, but later told me thay liked and appreciated it -
> to each his own.
My comments about style were not meant as criticism, but only to
say that some of the style choices interfered with understanding
(that is, my understanding of) the deeper structure of the
program, which is where I feel the more significant issues are.
I'm sorry if what I said came across as something else.
>>> /*
>>> * whole line comments could easily be absent and should not
>>> * count against to 25 lime function body limit.
>>> *
>>
>> I suggest putting any whole line comments either just before or
>> just after the function they relate to....
>
> I like comments on functions, but for giving information on what I'm
> doing in a certain part of the code (which I often to for myself in
> tricky parts - you never know how long it will be before you might
> have to visit it again), I like to put those comments in that part. I
> didn't realize that whole line comments near where they apply would be
> against the "spirit" of the exercise, and I thought my idea "whole
> line comments shouldn't apply against the 25 line limit" was pretty
> clear and reasonable - again, not thinking it was about "style" I was
> thinking it would be ok without any comments, and added the ones I did
> for reader benefit.
My comment was only a suggestion, and wasn't about the 25-line
rule or the spirit of the exercise.
>>> unsigned short // at least 16 bits to insure '& 0xFF00' works
>>> Cp, // Pending input character
>>> C0, // Last character read
>>> Enl; // EscapeNewLine seen
>>> unsigned char
>>> C1, // Previous character read
>>> Imode; // Input mode
>>
>> You have the germ of a good idea here (and carried forward in
>> rdchar1(), discussed below), but the names chosen and the types
>
> Again, didn't realize names used would count for the "exercise".
> [...]
Again my comment is only about trying to understand the code, and
was made only because of your stated request to let you know
about "any other/continued problems" in the program. I'm not
saying that the names or types would necessarily be problems for
other people, or anything else about the exercise, but only that
they were problems for me.
>> used get in the way. There is no reason to use either unsigned
>> short or unsigned char: characters should be of type 'int'.
>
> Personal style. People who "grew up" on big systems tend to not think
> about size and go with default type attributes. When you have worked
> as much as I have on systems where "int" and/or signed operations can
> be noticeably more "expensive" in resources that other types, you tend
> to do things in ways which could generate simpler code. And I've
> always thought that (except with some specific tools) smaller/simpler
> types on most systems don't cost you even if they don't save you much
> either.
The problem is one of ease of comprehension. It is possible the
smaller types will work fine, but it costs mental effort to
verify that. The advantage of using 'int' (and after all it's
only four variables) is that if 'int' is used then it's obvious
that the code will work.
>> counter should be just 'unsigned', and Imode shouldn't be a
>> character at all, but some enum type. The names (ignoring the
>> style of initial capital letter) used for the characters go
>> pretty strongly against the mental grain. I suggest this (I am
>> using all lower case but please don't focus on that):
>
> More "personal style" I did things simple because of the limitations
> of the exercise. Also, I tend to use all lower-case for locals,
> Beginning with Upper for globals and all Upper for #defines etc. not
> 100% consistent in this but I do it a lot.
I wasn't complaining about you using initial capitals, just
saying my own usual practice is otherwise. And I did say
explicitly not to focus on the case differences.
>>> // Line continuation sequences occurring within comments are
>>> // removed. But what about comments starting with [/\<newline>*]
>>> // [/<newline>/] ?
>>
>> Presumably you meant [/\<newline>/] at the end there.
>
> I did.
>
>>> // I decided to remove them,
>>
>> That is the right thing to do
>
> Except that [.../\<newline>* */... /\<newline>* */...] could result
> in the [...]s collecting into very long lines when the <newlines> are
> not retained. It should be "obvious" that replacing coments with
> single spaces would remove any <newline> embedded in those comments,
> but it might not be as obvious to someone that these newlines were
> "inside" the comment - it takes effect at the '/', but doesn't
> actually get recognized till the '*'...
I wasn't faulting your (implied) question, just answering it.
>>> // but if you prefer those [\<newline>]s to
>>> // remain, change all [/*1] in this file to [//1], [...]
>>
>> It would be nicer if this sort of conditional behavior were done
>> using regular code and not using either comments or the C
>> pre-processor.
>
> Remember the 25 line limit? I was presenting how the program could be
> changed if it was desired to do something a little different. And yes
> the [//] lines were assumed not to count against the limit. I only
> did all this because I pretty much knew that "someone" would argue it
> if I had just chosen one or the other.
My suggestion was made in the interest of ease of understanding.
It shouldn't be too hard to use if() rather than commenting or
pre-processor conditionals and still observe a limit on function
length.
>> First the code has a hidden brace (just before the /*1*/ line).
>> Please don't do that.
>> .. Lots more comments on how bad my style is throughout trimmed ...
>
> This doesn't apply to your "challenge" and I don't really think it's
> something you should need to know, but I'm not young (pretty sure you
> know this due to my mentioning having programmed in the 70's), but
> what you might not know is that I have some pretty significant vision
> issues.
>
> Because of this, I tend to work using my own editor which uses a 25x80
> text screen, usually enlarged to fill a 27 (or in some cases 24) inch
> monitor. It helps me see what I'm doing a lot better.
Interesting. This effect is not one I have encountered before,
at least not this severely.
> Because of the 25 lines, I *abhor* working on code where block braces
> have been spread out over lots of nicely indented and otherwise blank
> lines. So I do something unpopular with some and stack my braces at
> the ends of the lines where the block level changes.
Another thing you could do is strive for shorter functions. I
wrote several different programs as solutions for this exercise,
and across all of those programs none of the functions was
anywhere close to 25 lines.
> This might not have shown in my code due to the newsgroup, but what
> *I* do is to be adamant about horizontal spacing. For C I use tabs at
> 4-space intervals - my editor defaults to this for .C .H etc, and you
> can clearly follow my codes block just by seeing how the lines are
> indented. And except for places I "wanted" a blank line, no screen
> lines are wasted.
>
> So (just a "fun" statement): You appear to assume that anyone who
> codes has good enough vision to comfortably do so in a manner that
> will please the majority of people. (Please don't do that. :)
My comment about placement of closing braces runs deeper than
matters of personal preference. However that's a larger topic so
I will just say thank you for explaining your situation.
> FWIW, if you use the RFCGG program I posted a few messages back, it
> will "mostly" restore my original formatting. There will be a few
> single non- block contained lines you have to fix manually to get the
> tabs right, but it will be restores to mostly way it should have
> looked (and don't worry I will try to refrain from posting more of my
> "horrible" code! :)
I haven't looked at that yet but will try to soon.
>> Looking at the semantics, I can't help the feeling that the code
>> is both working too hard and is too hard to understand. Using
>> the declarations I wrote above, it can be written more concisely
>> thus (also I changed the name - 'rdchar1' is horrible):
>>
>> int read_next(){
>> c0 = c1, n_lcs = 0, c1 = c2, c2 = getchar();
>
> I avoided stacking assignments in one statement because I felt that
> this was using a capability of C to sidestep the 25 line restriction.
> I was mentally translating "25 lines" to "25 C operations".
I wrote it this way because it more directly expresses how I
think of what is being done. To me, conceptually this is one
operation. In any case "25 lines" means 25 lines, not something
else. I wrote code the I usually do, not trying to reduce the
number of lines artifically, and that is what I was expecting
other people would do.
> You'll note that I commented when I put a single if/switch block on one
> line.
Yes, and there are cases where I imagine I would do something
similar (I think I have done while()switch() on the same line in
some programs in the past). For me the deciding factor, at least
in almost all cases, is Does the code best express my conception
of what is being done? It wasn't that the if()switch() by itself
is bad, only that in combination with all the other control flow
going on it added another unit of difficulty.
>> while( c1 == '\\' && c2 == '\n' ){
>> n_lcs++, c1 = getchar(), c2 = getchar();
>> }
>> Notice the code is simpler because the invariant is easier to
>> write. The values in c0, c1, and c2 are consistent at all times:
>> last, current, and next. The number of LCs (in n_lcs) goes with
>> the character in c1 so it is initialized to zero at the start of
>> the routine. Do you see how this writing corresponds (even if
>> not exactly) to your rdchar1() function?
>
> Sorry but No - it misses the operations with [Cp] which is a Pending
> character needed to detect '\<newline>' in accordance with the
> standard. As I mentioned in a comment I probably would have done it
> differently had I know about this "feature" at the start. I haven't
> taken the time to look at the rest of your program to see if you
> handled it somewhere else.
The variable c2 corresponds to your Cp variable. The while()
loop shown dutifully counts the <backslant><newline> pairs just
before each (regular) character. I'm pretty sure these two
functions exhibit the same externally visible behavior (taking
into account the change of variable names). Do you see some
way that they are different in that respect?
>> Combinations of break's and
>> continue's (break's go with the switch(), continue's go with the for()
>> and are there to pass over the return statement at the end), along
>> with the if()/switch() -- all of these make the code very hard to
>> decipher.
>
> But legal C ... which is what I understood the challenge to be about
> (avoid [goto] and keep functions below 25 lines)
My comments were not about observing the restrictions of the
exercise but about trying to give feedback on the program's
behavior, which for me was hindered by the elaborate control flow
used.
>> Re-writing to clean up the layout and better show the control flow:
>
> I haven't bothered to check your code, but quite possible as this was
> code I hacked at to account for the "feature" I hadn't know about at
> the start. As far as I could tell I still met the requirements of the
> "challenge" so I didn't further optimize it for clarity.
At the risk of repeating myself, my comments were not meant as
criticism or whether the program meets the constraints of the
exercise, only about giving feedback on how to make it give
correct results.
>> At this point I am lost. The code seems very confused. Normally I
>> would go through and try to fix things up to the point where it will
>> work, but I kind of gave up here; I thought would be easier to
>> write a whole new program from scratch than try to fix this one.
>
> Sorry for the confusion. I didn't think it was actually that bad,
> only four functions which at 17, 25, 16 and 25 non-comment line each
> (of which a few are just function definitions and block delimiter
> lines, making the number of code generating C lines even less.. I
> believe it is all legal C, and the "challenge" was about limits on how
> big things could be and specified C features that could not be used,
> so my code wasn't designed to be overly readable. If it were a
> "challenge" about style my entry would have been a LOT different!
My comments were primarily about program behavior and how to make
it give correct results. Any comments about style were (and are)
subsidiary to that.
> Btw, if the variable names were causing you real problems, it is a
> small program and most editors support global substitution. For the
> block delimiters, I'm pretty sure there are some "pretty printers"
> which would take care of that two.
I did both of those things.
>> Note by the way that the LCs are output only here, but there is
>> more than one place that rdchar2() is called, which means some
>> LCs are potentially lost (ie, not transmitted to the output, or
>> not transmitted in the right places).
>
> I had reasons for ordering things the way I did, so I (personally)
> don't think so, but feel free to advise me of any actual issues like
> that you might find (that's what I was looking for).
>
> When I asked you for further feedback I was assuming that since you
> had posted only a couple and easily fixed problem, I was asking for
> you to be sure to let me know of any other functionality problems you
> observed.
My post upthread (before your latest program) included this
example (indented, so remove leading white space)
================
/\
\
\
1
================
The program you last posted gives this output for that
================
\
\
\
/1
================
Obviously that's wrong. Since the program is having problems
with examples I already gave, it seemed appropriate to look
at how the code works and comment on that. And that is what
I did.
> Your post to another guy suggested that you were trying
> quite a bit of code through them.
I do have a lot of test cases, but your code isn't yet passing
all the ones I've already given you. Do you not test the
specific cases I mention?
>> Here are skeletons for the "go" routines:
>> .. quite a few function definitions trimmed ..
>
> Again I clearly didn't understand the "challenge". I thought the 25
> line function limit implied "less code desirable" and that "many small
> functions" would be "frowned upon".
I don't know how you got that idea. The point of limiting
function length is to avoid overly long functions. It seems kind
of obvious that as functions are made shorter the number of
functions used will tend to go up. The exercise wasn't meant to
be a code golf kind of exercise.
>> I don't know how much sense all this makes to you. I'm trying to
>> provide what constructive comments I can, but unfortunately am
>> hampered by finding the submitted program code confusing.
>
> Makes good sense, and had I expected the code to be reviewed for more
> than "what it does", I probably would have made some style changes
> before sending it.
I was reviewing the code because you had asked for feedback about
other problems, and all of my comments were meant to be directed
toward that goal. It wasn't meant as a code review for its own
sake, only to provide information that might help you correct the
program's behavior.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-06 13:35 -0500 |
| Message-ID | <rt4vte$8ba$1@dont-email.me> |
| In reply to | #158220 |
On 1/6/21 11:55 AM, Dave Dunfield wrote: ... > If it weren't for this side affect, lines ending with: \\<N> > would become '\\','\n' without regard to whatever is on the next That would make lines ending in \\<N> a special case, different from all other escaped newlines. That would require extra wording in the standard. ... > which leads to the question... Did people actually significantly use this > behavior where the first \ in \\<N> applies to the first character of > the next line -- enough to standardize it? You've got it slightly backwards. It currently works because nothing special is said about that case. Wording would have to be added to the standard to make it not work.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-06 19:27 +0000 |
| Message-ID | <20210106104902.882@kylheku.com> |
| In reply to | #158220 |
On 2021-01-06, Dave Dunfield <dave.dunfield@gmail.com> wrote:
> My thought is this this is undesirable because it voids the otherwise
> valid notion that a \ escape applies to what immediately follows it
> (in this case another '\').
\ is only an "escape" in character and string literals.
Elsewhere, it has no special meaning, except that if it is followed
by a newline, absolutely anywhere in the syntax, it is a line splice.
The situation is orthogonal: the line splice is handled in one
translation phase, such that it is not even seen by the next phase in
which string literals and character constants are recognized.
It is absolutely undesirable to complicate this situation further by
introducing interactions between character escape sequences in
string literals and line continuation.
> But .. to coin your phrase this made
> "writing of an implementation as easy as possible".
> And apparently this became part of the standard.
1. It isn't as easy as possible. At any point in any token of the
language, a backslash-newline can occur. This makes it impractical
to use a conventional lexical scanner directly; an input routine
has to be used that "eats" the continuations.
2. The line continuation treatment is a feature of the original
C implementation on Unix, which used a separate program called cpp
for doing all preprocessing.
That program allowed for situations like:
#define macro foo
foo("macro"); /* macro is expanded in string literal */
It was more of a raw text processor than the current specification
of the corresponding C translation phases, which have to obey
token integrity to a greater extent.
Still, the way it is defined now shows vestiges of the pipelined
approach.
The 1979 sources of cpp (Version 7 Unix) are here:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/cpp
3. The whole original purpose of line continuations is that
preprocessor directives are line oriented. A #define must be written
all on one line. The continuation mechanism allows for multi-line
defines. This is why the mechanism "belongs to" the preprocessing
stage. The compiler proper without the preprocessor had no backslash
continuation mechanism. It didn't require one because the one thing
you might need to break up, namely long string literals, support
juxtaposition: "foo" "bar" is the same object as "foobar", spelled
using a different token sequence.
A line continuation mechanism designed as part of one integrated
language without a separate preprocessor might be designed
differently. Line continuation could just be a special feature
supported in string literals.
> (Q: when is \\ not '\' - A: when it occurs immediately before a newline).
\\ is also not \ outside of any string literal or character constant!
There is no such escape, except in string and character literals.
Someone writing a line of code like
"Hello ... \\
who is expecting that \\ is just an encoding of a single \
must also be expecting an error: unterminated string literal.
There is no closing quote in the same line.
Or else, that programmer would also not have to know that
C string literals must start and end in the same line.
Or else, that programmer knows about backslash continuations,
and is either not fooled, or at least pauses to think.
Nobody who knows that C literals are all in one line would write the
above, compile it, and not expect an error. It could happen by
accident, and there would have to be another accident (a stray " in the
following line) for that not to result in an error.
>>I remember one of the mantras of the Standards Committee was that
>>"Existing Programs were important, Existing Implementations were not",
>>which meant that a language change that broke existing programs was to be
>>avoided when possible, including those using implementation defined
>>behavior or extensions. But they didn't really care if a change required
>>totally rewriting the compiler.
>
> which leads to the question... Did people actually significantly use this
> behavior where the first \ in \\<N> applies to the first character of
> the next line -- enough to standardize it?
But that case *specifically* isn't standardized; what is standardized is that
a backslash continuation can occur anywhere in the input stream, before
tokens are recognized, and thus it can split any token, invisibly to
that token.
Yes, unknown numbers of programs out in the wild contain a token
interrupted by a line continuation, so that it can't be broken.
Changing it for a special case in string literals (which is ultimately
not even valid syntax!) makes little sense.
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-06 21:25 +0000 |
| Message-ID | <20210106114549.541@kylheku.com> |
| In reply to | #158220 |
On 2021-01-06, Dave Dunfield <dave.dunfield@gmail.com> wrote: > Exactly, except that somewhere along the way, somebody realized that to > properly handle many of the escape actions they had to be done after the > line was tokenized, eg: \" wouldn't let you insert a '"' in a string if > all the compiler saw in either case was a source input of '"'. This hypothesis is not confirmed by the actual historic sources. Here is that part of the compiler from V1 Unix, 1971: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/c/nc0/c00.c The functions for handling string literals and character constants, getstr, getcc are clearly tokenizing and handling the escapes. These escapes were never implemented in the preprocessor, invisibly to the compiler: only the line continuations were. The predecessor language, B, also had escapes, denoted by an asterisk. I'm not about to hunt this done in PDP-7 assembly language sources, but the reference manual describes this in an Appendix. Appendix A.1 specifies character escapes that are available in literals. Those use a * character. A.2 specifies "source code escapes" which are introduced by a $. These are a subset of the A.1 ones, providing printable characers not available on some keyboards. Again this shows that escapes are not oblivious to token structure.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-06 00:37 -0500 |
| Message-ID | <rt3ias$in9$1@dont-email.me> |
| In reply to | #158204 |
On 1/5/21 10:33 PM, Dave Dunfield wrote:
> I don't see much point continuing... but in "short" response:
>
>>> #define foo "A\\
>>> tB"
>>> ... discussion about this code ...
>>> which correctly prints as "A<tab>B"
>> That, on the other hand, is correct.
>
>> No, that's not the correct idea. The general idea is that "\\\n" will be
>> treated as "".
>
> Since we had no discussion of three '\' characters, I'm guessing that the above
> is the same as my: \\nl
I'm not sure what your notation means. My notation is equivalent to
{'\\', '\n'}, in other words, it's a single backslash, followed by a
newline character. Inside a character constant or a string literal, a
single backslash character must be represented by two backslash
characters, otherwise it would be interpreted as the first character of
an escape sequence. The sequence '\n' is an escape sequence that
represents a newline character.
That's an example of why this is a confusing topic to discuss.
> where 'nl' is an actual newline character (end of line)
>
> So applying that rule, the #define becomes: #define foo "AB"
No, it becomes
#define foo "A\tB"
...
>>> IMHO this behavior should be implementation dependent and a really
>>> good compiler might allow it and issue a warning that you are relying on
>>> non-standard behavior.
>> I'm fairly certain that any such change would break multi-line macros,
>> which are fairly commonly used.
>
> "allowing it" and Issuing a warning would break existing code?
No. Making it implementation-dependent would mean that this behavior is
no longer mandatory, which would break existing code, on every
implementation that took advantage of that fact. Realistically, no one
would take advantage of that fact, which is closely related to the fact
that this suggestion has no chance of being approved by the committee.
But you won't appreciate why that's true until you get a better
understanding of how it works.
> And why is this a significant issue? Which brings me back to a question I previously
> asked that nobody has bothered to actual answer:
>
> Is there a compelling reason to code : ...otherstuff...\\nl
Yes. Preprocessing directives always end with a newline. If you want to
write a preprocessing directive that is too long to put on a single
line, you have to use escaped newline characters, which get removed
during translation phase 2, and therefore are not visible when
preprocessing directives get parsed during translation phase 4.
> if as you say a trailing: \\nl
> becomes "" then why not use: ...otherstuff...\nl
> which does the same thing, is there ever an actual reason to use: ...\\nl
I wrote a long explanation before I realized that I'm not sure what
you're suggesting. You're saying that ...otherstuff...\nl would be a
better alternative to something involving \\nl, but it's not clear to me
what that something is. Presumably it involves otherstuff, but I'm not
sure where otherstuff is supposed to be relative to the \\nl.
> If as I had guessed, the preceding '\' applies to the first character on the next line
> (after the last-on-line '\nl' becomes "") - which it seems to, they why not use:
The primary use of escaped newlines is to allow multi-line preprocessing
directives. That fact that it allows you to split escape sequences in
character constants and string literals is just a side-effect, it's not
the purpose of that feature. I would say in general that it's better
style to put an escape sequence entirely on one side or the other of an
escaped newline.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-06 04:34 -0800 |
| Message-ID | <8f41525c-c8f2-4c17-bfd9-520f8f5027b0n@googlegroups.com> |
| In reply to | #158208 |
> I'm not sure what your notation means. My notation is equivalent to
> {'\\', '\n'}, in other words, it's a single backslash, followed by a
> newline character.
I think I see the crux of our misunderstanding.
Since we are talking about what a compiler does, I've been posting much of my
text in natural form (as it would appear while editing source code), not what it would
be in C notation (yeah... maybe not the best way in a C group :-)
I did this because It can get confusing to post simple characters using C notation
in example source text - which may also containing C notation.
So \ is a single backslash, C equiv: '\\'
Since none of the text I've posted uses "nl", as I have tried to explain,
nl is a newline character, C equivalent '\n'
The original code which was posted (not by me):
included:
------ Start ------
#define foo "\\
"*/"
------- End -------
If this is what the source text would look like, I took this to mean
(in 'C' notation):
'#','d','e','f','i','n','e',' ','f','o','o',' ','"','\\','\\','\n',
'"','*','/','"','\n'
So when I discussed: \\nl
appearing in source text, it would be: '\\', '\\','\n'
Does this clear it up? Perhaps my comments/questions will make more sense
now.
Dave
Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-06 11:54 -0500 |
| Message-ID | <rt4q0u$ouk$1@dont-email.me> |
| In reply to | #158214 |
On 1/6/21 7:34 AM, Dave Dunfield wrote:
>> I'm not sure what your notation means. My notation is equivalent to
>> {'\\', '\n'}, in other words, it's a single backslash, followed by a
>> newline character.
>
> I think I see the crux of our misunderstanding.
> Since we are talking about what a compiler does, I've been posting much of my
> text in natural form (as it would appear while editing source code), not what it would
> be in C notation (yeah... maybe not the best way in a C group :-)
> I did this because It can get confusing to post simple characters using C notation
> in example source text - which may also containing C notation.
As I said, it's confusing. I used my notation because the new-line
character is invisible in natural form, and your replacement "nl" looks
exactly the same as 'n' followed by 'l', which would perfectly valid
source file text. Also,when preceded by '\\', it looks exactly like '\n'
followed by 'l', which would also be legal if it occurs in a string
literal. Those three different possibilities for \nl are clearly
distinguished in my notation: they are "\\\n", "\\nl", and "\nl".
> So \ is a single backslash, C equiv: '\\'
> Since none of the text I've posted uses "nl", as I have tried to explain,
> nl is a newline character, C equivalent '\n'
>
> The original code which was posted (not by me):
> included:
>
> ------ Start ------
> #define foo "\\
> "*/"
> ------- End -------
> If this is what the source text would look like, I took this to mean
> (in 'C' notation):
>
> '#','d','e','f','i','n','e',' ','f','o','o',' ','"','\\','\\','\n',
> '"','*','/','"','\n'
>
> So when I discussed: \\nl
> appearing in source text, it would be: '\\', '\\','\n'
>
> Does this clear it up? Perhaps my comments/questions will make more sense
> now.
In my notation, the rule is that "\\\n" or {'\\', '\n'} gets removed.
In your notation, the rule is that \nl gets removed.
Either way, that removal converts two physical source code lines into
one logical source code line. This only applies for the very last '\' on
a physical source code line.
The result after application of that rule is
'#','d','e','f','i','n','e',' ','f','o','o',' ','"','\\',
'"','*','/','"','\n'
or
#define foo "\"*/"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-05 15:28 -0800 |
| Message-ID | <86mtxnq7yo.fsf@linuxsc.com> |
| In reply to | #158189 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
> Just a closing thought on this discussion:
>
>>> I've always thought of escapes (and hence my compiler does too) as
>>> in the order the characters occur, and that the escape applies to the
>>> NEXT character in sequence:
>>
>> It does; it applies to the next character in the logical line that
>> exists in ISO C translation phase 3.
>
> I understand why this might occur in some implementations, and I
> agree that the standard should account for it, but I disagree that
> it should be mandated by the standard. Like some other things in
> the standard, I feel that this should be a "may" item - ie: This may
> occur in some implementations and is not guaranteed by the standard.
>
> I can't see a reason to code like this and there are other more
> straightforward ways to code this without relying on this
> characteristic.
>
> In addition to being caused by a particular implementation decision,
> it is also not fully predicable unless you know inner technical
> details of the compiler. [..elaboration..]
>
> Knowing why it happens you could know that it likely won't work
> across multiple newlines - but does the standard actually mandate
> that it can't. A vendor could knowing that it is mandated to work
> the first time, detect it and make it work over multiple newlines.
>
> IMHO this behavior should be implementation dependent and a really
> good compiler might allow it and issue a warning that you are
> relying on non-standard behavior.
>
> Please enlighten me if there is a compelling reason to rely on this
> behavior.
Your comments actually raise several different questions. Let me
see if I can separate them out and address each one individually.
Q: Is it important for the C standard to address this aspect of C
programs? If so then why? A: It's important because lots of
previously existing code made use of line continuation escapes,
and it's important (that is, stated as a given by the C standard
committee) that such code continue to work reliably under the C
standard, similarly to how other previously existing cases were
considered.
Q: Is it important for the C standard to have a particular rule
for how line continuation works? A: Yes, because an important
job of the standard is to reconcile slightly differing choices
made by earlier implementations. The C standard committee chose
to follow the principle "Existing code is important, existing
implementations are not." There needs to be a specific rule
precisely so that a particular behavior can be used reliably, and
so previously existing code will continue to work under the C
standard the same way it did before the standard was written.
Q: Is there any reason to rely on how line continuations work?
A: In many cases no, but in some cases yes. See below.
Q: It seems like we have to look at compiler internals to know
what's really going on here. How can we know what the rule is
without having to understand the (or several) compilers? A: In
section 5.1.1.2 of the C standard, titled "Translation phases",
there is a high-level description of a sequence of phases used
to translate a C program. The descriptions are specific enough
so that what happens is well defined, but not so detailed that
they are tied to any particular compiler or implementation. This
relationship is perhaps best explained by a footnote in that
section:
Implementations shall behave as if these separate phases
occur, even though many are typically folded together in
practice. Source files, translation units, and translated
translation units need not necessarily be stored as files,
nor need there be any one-to-one correspondence between
these entities and any external representation. The
description is conceptual only, and does not specify any
particular implementation.
Q: What the rule is seems kind of screwy. What led to the
decision to have the rule be what it is? A: This question is
perhaps best answered by the excerpt from the Rationale document
for the ANSI (and later ISO) C standard:
A backslash immediately before a newline has long been used
to continue string literals, as well as preprocessing
command lines. In the interest of easing machine generation
of C, and of transporting code to machines with restrictive
physical line lengths, the C89 Committee generalized this
mechanism to permit any token to be continued by interposing
a backslash/newline sequence.
I hope the preceding points help address your reservations. I
know I am quite happy to have the specifics of line continuation
nailed down by the ISO C standard, so that it can be used with
confidence and without any concern about which C implementation is
being used to compile programs that use it (and most do, if not
directly then indirectly through #include's of system headers).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-05 13:27 -0500 |
| Message-ID | <rt2b33$uap$1@dont-email.me> |
| In reply to | #158178 |
On 1/5/21 11:55 AM, Dave Dunfield wrote: ... >> (the double quote in the middle is escaped by the first \). The >> input (after removing leading indentation) >> >> "\\ >> "/*" >> >> is a valid string literal, the same as "\"/*". > > Just shows how you can always learn something. Still don't quite > understand it though. > > I've always thought of escapes (and hence my compiler does too) as > in the order the characters occur, and that the escape applies to the > NEXT character in sequence: You're right, but you have to pay attention to the translation phases in order to correctly determine which character is the next one. > "\\ > "/*" The sequence of characters at this point is: '"', '\\', '\\', '\n', '"', '/', '*', '"' During translation phase 2, escaped newlines are removed, so at the end of that phase, you have '"', '\\', '"', '/', '*', '"' It is not until translation phase 3 that escaped characters in character constants and string literals are evaluated, and at the start of that phase, the next character after the backslash is the second double quote mark, so what you thought is in fact correct - but for a different "next character" than you thought it was.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-05 15:43 -0800 |
| Message-ID | <86im8bq7am.fsf@linuxsc.com> |
| In reply to | #158178 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
>> I think you have missed the essential element here. The presence
>> of #define is incidental, and there is no unpaired double quote
>> (the double quote in the middle is escaped by the first \). The
>> input (after removing leading indentation)
>>
>> "\\
>> "/*"
>>
>> is a valid string literal, the same as "\"/*".
>
> Just shows how you can always learn something. Still don't quite
> understand it though.
>
> I've always thought of escapes (and hence my compiler does too) as
> in the order the characters occur, and that the escape applies to the
> NEXT character in sequence: [..elaboration..]
>
> I wonder if this is truly portable, or an interesting quirk
> of some toolsets... Clearly I need to investigate some more.
Like what I said in my response downthread, there are several
transformations applied, and there is a specific precedence to
the order in which they are applied. This order is spelled out
in section 5.1.1.2 of the ISO C standard. If you don't have a
copy of that, download this
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
which is not the actual standard document, but a draft that is
for almost all intents and purposes indistinguishable from it.
Get a copy of that, and read section 5.1.1.2 (just a little more
than one page), and see if that doesn't help clarify things.
I might give a warning: text in the C standard can be rather
dense, and so trying to read it can be rather slow and takes some
getting used to. Despite that, I think you will ultimately find
it helpful and worthwhile to read this particular section of the
C standard.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-05 20:10 -0800 |
| Message-ID | <3a28797b-2b2b-4e44-9844-670134c374e9n@googlegroups.com> |
| In reply to | #158177 |
> As long as you understand what's going on, how to fix it
> is up to you. Are you going to submit a revised program?
> Other people have done that.
Since you asked.. note that this fixes the A/**/B and also
adds a warning message if it sees: \\nl
It doesn't actually support \\nl yet which would require a few more
lines/functions - and it's never been an issue for me, but I can look
into adding that ability of people really want it.
/*
* whole line comments could easily be absent and should not
* could against to 25 lime function body limit.
*
* Assumes a valid 'C' program as input, will not detect
* certain errors affecting comments, quotes or escapes.
*/
#include <stdio.h>
unsigned // at least 16 bits to insure '& 0xFF00' works
C2; // Last character read
unsigned char
C1, // Previous character read
Imode; // Input mode
unsigned char rdchar(void)
{
for(;;) {
C1 = C2;
// Assumes 8-bit char set, not including 0 and EOF is >255
if((C2 = getc(stdin)) & 0xFF00)
return 0;
// changing this if multiple 'if's could eliminate the 'switch' line
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C2 == '/')) {
Imode = 0;
C2=' '; }
continue;
case '/' : // Inside '//' comment
if(C2 != '\n')
continue;
Imode = 0;
continue;
case 0 : // No special mode
// could be considered as two lines in one, although it's a construct
// I sometimes use if a 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C2) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C2;
continue; } }
return C1; }
}
int main(void)
{
unsigned char c, d=0;
rdchar(); // First call to rdchar will return 0;
for(;;) {
switch(c = rdchar()) {
case '\\': // Escape
putc(c, stdout);
if(d = rdchar()) {
putc(d, stdout);
continue; }
return 0;
case 0 :
putc(C1, stdout);
return 0;
case'\'':
case '"':
if(Imode == c)
Imode = 0;
else if(!Imode)
Imode = c;
break;
case '\n':
if(d == '\\')
fputs("use of: \\\\newline\n", stderr); }
putc(c, stdout);
d = 0; }
}
Dave
Search "Dave's Old Computers" see "my personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-06 23:07 -0800 |
| Message-ID | <86eeixql7u.fsf@linuxsc.com> |
| In reply to | #158206 |
Dave Dunfield <dave.dunfield@gmail.com> writes: >> As long as you understand what's going on, how to fix it >> is up to you. Are you going to submit a revised program? >> Other people have done that. > > Since you asked.. note that this fixes the A/**/B and also > adds a warning message if it sees: \\nl > It doesn't actually support \\nl yet which would require a few more > lines/functions - and it's never been an issue for me, but I can look > into adding that ability of people really want it. I think most people who posted solutions addressed or at least tried to address this situation. I don't know that anyone really wants of these programs but it was intended as being part of the original problem statement. Also part of what makes the problem interesting.
[toc] | [prev] | [standalone]
Page 20 of 20 — ← Prev page 1 … 18 19 [20]
Back to top | Article view | comp.lang.c
csiph-web