Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #156943 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2020-12-05 08:25 -0800 |
| Last post | 2021-01-06 23:07 -0800 |
| Articles | 20 on this page of 399 — 24 participants |
Back to article view | Back to comp.lang.c
Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-05 08:25 -0800
Re: Programming exercise/challenge Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-12-05 17:33 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 11:58 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-30 09:40 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-30 18:20 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 01:04 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-02 22:05 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 14:48 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 19:17 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 19:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-30 21:44 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-31 02:54 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-03 09:49 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-04 00:15 +0300
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-03 21:57 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-03 23:00 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 00:00 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 07:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 22:30 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 18:42 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 21:23 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-04 23:41 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 16:39 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 16:58 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 17:08 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 17:11 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 17:24 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 17:52 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:30 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 19:56 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 14:51 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-05 17:49 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:34 +0000
Re: Programming exercise/challenge Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-05 19:40 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 18:47 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-05 23:19 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-05 23:56 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 02:26 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 16:04 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:39 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:34 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:28 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:34 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 20:05 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:03 -0800
Re: Programming exercise/challenge dfs <nospam@dfs.com> - 2020-12-05 13:58 -0500
Re: Programming exercise/challenge Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-12-05 21:37 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:13 -0800
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 18:00 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 12:31 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 06:26 -0800
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-05 23:32 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 17:18 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-06 17:51 +0100
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 22:27 +0000
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-07 09:37 +0100
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 07:36 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:49 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 17:51 +0000
Re: Programming exercise/challenge dfs <nospam@dfs.com> - 2020-12-06 13:03 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 23:53 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-06 19:53 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-06 23:38 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 00:17 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 02:09 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-07 01:03 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 12:05 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 12:25 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 13:33 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 14:18 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-07 14:31 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 12:58 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:03 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 07:12 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 21:55 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:59 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:55 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 07:45 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:26 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-24 12:24 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-24 17:19 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:16 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:17 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:27 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:18 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-07 05:15 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 13:42 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 22:53 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 01:49 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:35 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 21:17 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:44 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:46 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-13 12:21 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:35 -0800
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2020-12-31 00:46 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2020-12-31 00:52 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 00:34 -0800
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 08:23 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 10:09 +0100
Re: Programming exercise/challenge Rosario19 <Ros@invalid.invalid> - 2021-01-01 11:38 +0100
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 08:24 -0800
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-07 07:03 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 02:16 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 02:39 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:18 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:17 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 00:27 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:20 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 13:44 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 14:01 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-07 22:16 +0000
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-07 15:10 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 01:07 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 00:34 +0000
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-08 18:17 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 00:56 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 02:30 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 15:14 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-09 15:44 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:56 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-12 13:29 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:46 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-12 13:59 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 14:17 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-13 12:58 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-13 20:57 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-14 20:44 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-23 11:15 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-23 23:45 +0300
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-23 21:36 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 09:11 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 15:30 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 23:18 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-24 23:56 -0800
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2020-12-28 12:01 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:31 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 14:47 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-08 01:59 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:26 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 19:02 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 01:15 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 20:38 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 02:19 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 11:44 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 07:32 -0500
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 14:40 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-08 06:52 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 17:31 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 20:16 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-08 20:48 +0000
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-08 15:34 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 02:54 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:33 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:43 +0300
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-09 01:52 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:28 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 21:40 +0000
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-12 13:48 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-09 01:46 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:29 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 10:45 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 17:16 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-08 06:39 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-07 17:48 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-07 21:03 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:02 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:02 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 16:49 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 13:33 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 19:57 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-10 01:45 +0000
Re: Programming exercise/challenge Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-12-10 02:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:24 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 21:57 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-10 03:32 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-10 08:19 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:04 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 19:34 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-08 02:22 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:04 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 11:59 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:11 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 00:02 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 15:12 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 10:36 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-10 22:11 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-10 23:34 +0000
Re: Programming exercise/challenge "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-12-10 20:11 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 21:06 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 03:03 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-08 21:21 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 12:50 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2020-12-09 08:16 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-08 23:32 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-09 12:21 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-02 19:15 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 01:54 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 22:36 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 23:07 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-22 20:27 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 13:05 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 07:45 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 16:49 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 11:22 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-23 16:53 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 09:55 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 21:35 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-24 18:17 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:57 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 11:28 -0800
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-08 11:30 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-08 20:31 +0000
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-08 22:17 +0100
Re: Programming exercise/challenge jacobnavia <jacob@jacob.remcomp.fr> - 2020-12-08 22:15 +0100
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-08 13:28 -0800
Re: Programming exercise/challenge "jfbod...@gmail.com" <jfbode1029@gmail.com> - 2020-12-09 12:05 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:04 +0300
Re: Programming exercise/challenge Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-12-08 21:38 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:25 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 01:00 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-09 03:09 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:35 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 22:57 +0000
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-12 23:43 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:47 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 23:27 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-13 14:44 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 11:47 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 03:36 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-09 14:51 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 11:35 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-10 02:33 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 00:05 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-10 14:59 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-10 20:32 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-12 23:45 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:24 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-13 00:17 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-12 19:23 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-09 19:31 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 12:01 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-09 12:25 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-23 01:00 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 14:34 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-26 23:03 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 06:29 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-28 11:52 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 00:38 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-28 15:29 +0300
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-28 17:12 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 23:54 -0800
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:26 -0600
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-29 10:37 -0600
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-29 19:59 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-30 09:17 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2020-12-31 16:54 +0300
Re: Programming exercise/challenge kegs@provalid.com (Kent Dickey) - 2020-12-31 09:16 -0600
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2020-12-31 15:56 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-07 02:41 -0800
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-31 13:01 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-31 14:15 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 08:03 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-01 07:42 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-02 21:59 +0300
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 14:52 -0500
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-02 12:30 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-02 18:17 -0500
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-02 19:22 -0500
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-02 17:48 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-02 22:35 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-02 18:02 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-03 00:42 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:12 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-04 07:04 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-04 20:22 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 04:24 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 06:22 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 08:55 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-05 20:22 +0300
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-05 20:27 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 14:20 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 17:23 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 10:18 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-05 18:57 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 12:58 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-05 17:31 -0500
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-05 17:50 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 19:33 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-05 23:02 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 21:00 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-06 07:42 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 08:55 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-06 13:29 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 14:09 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 22:11 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-07 03:10 -0800
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-07 06:40 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-09 06:27 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-10 04:32 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-11 06:58 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-11 14:40 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-15 09:46 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-17 04:13 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-17 14:18 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-17 18:02 +0000
Re: Programming exercise/challenge Richard Damon <Richard@Damon-Family.org> - 2021-01-17 15:12 -0500
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-17 21:39 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-20 10:57 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-21 11:37 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 00:30 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-22 09:09 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 13:47 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-22 19:00 +0000
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-22 19:42 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-22 21:16 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-22 16:41 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 17:46 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 09:51 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 18:38 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 04:52 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-23 15:45 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 09:04 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-23 23:10 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 15:39 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 15:59 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 11:40 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 09:47 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-23 18:32 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-23 17:26 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-24 01:55 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 08:40 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-23 20:51 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-24 02:28 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-24 03:49 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-24 15:38 +0300
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-24 14:04 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 07:26 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-25 16:58 +0100
Re: Programming exercise/challenge luser droog <luser.droog@gmail.com> - 2021-01-25 09:14 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 07:32 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-27 16:24 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-28 00:11 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 12:25 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 06:18 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 16:54 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 09:15 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-28 20:07 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 15:58 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-29 00:07 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 16:17 -0500
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-29 00:03 +0300
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-28 03:37 -0800
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-28 22:50 +0000
Re: Programming exercise/challenge Anton Shepelev <anton.txt@gmail.com> - 2021-01-30 23:14 +0300
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-30 20:49 +0000
Re: Programming exercise/challenge M Joshua Ryan <luser.droog@gmail.com> - 2021-01-28 00:05 -0600
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-27 11:51 -0800
Re: Programming exercise/challenge Bart <bc@freeuk.com> - 2021-01-25 17:22 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 12:21 -0800
Re: Programming exercise/challenge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-01-25 14:27 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-25 19:41 -0800
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-26 04:46 +0000
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-26 06:30 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-26 15:46 +0100
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-27 03:43 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 13:43 +0100
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 17:51 +0300
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-27 11:02 -0500
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 17:03 +0100
Re: Programming exercise/challenge Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-01-27 07:21 -0800
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-27 17:09 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-27 17:04 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-28 10:41 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-28 18:25 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-28 10:44 +0100
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-28 21:33 +0000
Re: Programming exercise/challenge David Brown <david.brown@hesbynett.no> - 2021-01-29 10:39 +0100
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-25 23:52 -0500
Re: Programming exercise/challenge Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-01-26 11:37 +0000
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 08:04 -0800
Re: Programming exercise/challenge Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-01-27 19:16 +0300
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 23:38 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-27 13:43 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-28 03:16 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-28 06:42 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-28 13:01 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 13:35 -0500
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-06 19:27 +0000
Re: Programming exercise/challenge Kaz Kylheku <563-365-8930@kylheku.com> - 2021-01-06 21:25 +0000
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 00:37 -0500
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-06 04:34 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-06 11:54 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 15:28 -0800
Re: Programming exercise/challenge James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-01-05 13:27 -0500
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-05 15:43 -0800
Re: Programming exercise/challenge Dave Dunfield <dave.dunfield@gmail.com> - 2021-01-05 20:10 -0800
Re: Programming exercise/challenge Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-01-06 23:07 -0800
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-10 04:32 -0800 |
| Message-ID | <b71fe02c-3211-433a-a9f7-c6a67686ff1dn@googlegroups.com> |
| In reply to | #158266 |
Another "good nights sleep" and I woke realizing that there would
still be problem with: (Tested and GCC accepts it)
---------------
#define foo "\\
\
"/*"
---------------
Since '\<nl>'s would have priority, this should still reduce to:
#define foo "\"/*"
The fix is not only simple, but reduces the number of lines in my
"solution". sigh... seems this might never end! :)
---------------
/*
* whole line comments could easily be absent and should not
* could against to 25 lime function body limit.
*
* Assumes a valid 'C' program as input, will not detect
* certain errors affecting comments, quotes or escapes.
*/
#include <stdio.h>
unsigned short // at least 16 bits to insure '& 0xFF00' works
C0; // Last character read
unsigned char
C1, // Previous character read
Bbn, // BackslashBackslashNewline tracker
Imode; // Input mode
// Read one character, excluding content of comments
unsigned char rdchar(void)
{
for(;;) {
C1 = C0;
// Assumes 8-bit char set, not including 0 and EOF is >255
if((C0 = getc(stdin)) & 0xFF00)
return 0;
// changing this to multiple 'if's could eliminate the 'switch' line
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C0 == '/')) { // Ending '/*'
Imode = 0;
C0=' '; } // Replace /*...*/ with single space
continue;
case '/' : // Inside '//' comment
if(C0 == '\n') // Ending: '//'
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 single 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C0) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C0;
continue; } }
return C1; }
}
// Read characters, and hande '\\' escape sequences
void handle_esc(void)
{
switch(rdchar()) {
case '\n': // possibly after: //
if(Bbn != '\\')
break;
// Following line issues warning, not needed for challenge.
fputs("'\\','\\n' following (effective) '\\'\n", stderr);
case '\\': // Escape
putc(C1, stdout);
Bbn = rdchar();
case 0 : // EOF
return;
case '"':
case'\'':
if(Imode == C1)
Imode = 0;
else if(!Imode)
Imode = C1; }
Bbn = 0;
}
int main(void)
{
rdchar(); // First call to rdchar will return 0;
do {
handle_esc();
putc(C1, stdout);
} while(!(C0 & 0xFF00)); // Till EOF has ben read
}
---------------
Btw (for the sake of discussion completeness)
someone along the way mentioned:
> --- TCC T.C gives ---
> Turbo C Version 2.0 Copyright (c) 1987, 1988 Borland International
> t.c:
1988 was before the first C standard was ratified by ANSI.
Well aware, wanted to test with a commercial K&R compiler and TC is
probably the only one here which I can easily still run (DOSBOX).
> Available memory 444682
That figure is not literally correct, either (I presume).
It would be whatever it saw under the virtual system...
Dave
Search "Dave's Old Computers" see my "personal" near bottom!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-11 06:58 -0800 |
| Message-ID | <86czybpljj.fsf@linuxsc.com> |
| In reply to | #158276 |
Dave Dunfield <dave.dunfield@gmail.com> writes: > Another "good nights sleep" and I woke realizing that there would > still be problem with: (Tested and GCC accepts it) > --------------- > #define foo "\\ > \ > "/*" > --------------- I observe that the new program handles this case correctly (with some diagnostics issued). > The fix is not only simple, but reduces the number of lines in my > "solution". sigh... seems this might never end! :) If changes always reduce the number of lines, then surely it has to end sometime. :) > [..program source..] It appears the program does not consider the possibility of line escape sequences as part of comments. Some examples: ================ /\ * This is a comment */ ================ /* This is a comment *\ /But this is not a comment /**/ ================ /\ / This is a comment This line is not a comment ================ // blah blah blah \ This is part of the same comment \ This too is part of the same comment This line is not a comment ================ Try using gcc -E as a basis for comparison.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-11 14:40 -0800 |
| Message-ID | <1ebc19c3-093d-4bc0-b680-aedbb9576eb5n@googlegroups.com> |
| In reply to | #158287 |
>I observe that the new program handles this case correctly (with
>some diagnostics issued).
Diagnostics are intentional, as I've made known: I don't particularly like
the "feature" it's detecting, It would most likely be a type on my part,
and I'm allowed to issue a warning :)
>If changes always reduce the number of lines, then surely it has
>to end sometime. :)
Very true, I might say however that my "this is never going to end" comment
was more about humor than fact :))
>It appears the program does not consider the possibility of line
>escape sequences as part of comments. Some examples:
Good point, and again I'll state that this would be unlikely in any of
my code, because If I wanted a mutli-line comment I'd either use a /* */
style, or another '//' at the beginning of the next line(S).
But the fix is easy and doesn't add any lines:
----------------------------------------------
/*
* 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.
*
* Dave Dunfield - Jan 2021
*/
#include <stdio.h>
unsigned short // at least 16 bits to insure '& 0xFF00' works
C0; // Last character read
unsigned char
C1, // Previous character read
Bbn, // BackslashBackslashNewline tracker
Imode; // Input mode
// Read one character, excluding content of comments
unsigned char rdchar(void)
{
for(;;) {
C1 = C0;
// Assumes 8-bit char set, not including 0 and EOF is >255
if((C0 = getc(stdin)) & 0xFF00)
return 0;
// changing this to multiple 'if's could eliminate the 'switch' line
switch(Imode) {
case '*' : // Inside '/*' comment
if((C1 == '*') && (C0 == '/')) { // Ending '/*'
Imode = 0;
C0=' '; } // Replace /*...*/ with single space
continue;
case '/' : // Inside '//' comment
if((C0 == '\n') && (C1 != '\\')) // Ending: '//'
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 single 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C0) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C0;
continue; } }
return C1; }
}
// Read characters, and hande '\\' escape sequences
void handle_esc(void)
{
switch(rdchar()) {
case '\n': // possibly after: \\
if(Bbn != '\\')
break;
// Following line issues warning, not needed for challenge.
fputs("'\\','\\n' following (effective) '\\'\n", stderr);
case '\\': // Escape
putc(C1, stdout);
Bbn = rdchar();
case 0 : // EOF
return;
case '"':
case'\'':
if(Imode == C1)
Imode = 0;
else if(!Imode)
Imode = C1; }
Bbn = 0;
}
int main(void)
{
rdchar(); // First call to rdchar will return 0;
do {
handle_esc();
putc(C1, stdout);
} while(!(C0 & 0xFF00)); // Till EOF has been read
}
----------------------------------------------
And one more thought.. (notice I've dropped describing them as "final":)
Somewhere in the arguments against my opinions, statements were made something
to the effect of:
"This sequence \\<nl> would not be manually entered, but having '\\','\n'
take precedence would make it much easier for a program that limited lines
to a printable length".
The thing is, if you want to limit a program to a certain "printable"
length and keep it readable and still be valid source code, there's nothing
"simple" about it and you would have to scan through the lines anyway.
Reason: '\t' - the TAB character
sure, sources may contain tabs, but there's no guarantee the printer has
the same tab stops as you used in the source (I use stops at 4 spaces
in C source as I find it much more continent *for me*). And you can easily
convert tabs to spaces (again using set tab stops) but C allows strings to
contain actual tab (0x09) characters (tested with GCC). You could convert
them to spaces but then the sources would not produce the same program.
You would have to convert tab characters within "" (or '') to \t - and you
would still have to convert all other tabs to spaces - not easily done
without scanning the line, and to my mine makes the job of detecting that
'\\'<char> would cause the line to exceed it's desired length and the whole
sequence should be moved to the next line seem quite a small part of the
whole "make it printable in lines of <=# characters) problem.
So I'm not sure I buy the reasoning. Which makes me still think this "feature"
came from a previous implementation and actually makes the language
slightly worst, not better (see my previous posts for my reasoning).
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-15 09:46 -0800 |
| Message-ID | <868s8uozxo.fsf@linuxsc.com> |
| In reply to | #158293 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
>> I observe that the new program handles this case correctly (with
>> some diagnostics issued).
>
> Diagnostics are intentional, [...]
Understood. I was just reporting the observation, not making
a judgment.
>> If changes always reduce the number of lines, then surely it has
>> to end sometime. :)
>
> Very true, I might say however that my "this is never going to end"
> comment was more about humor than fact :))
My statement likewise.
>> It appears the program does not consider the possibility of line
>> escape sequences as part of comments. Some examples:
>
> Good point, and again I'll state that this would be unlikely in any
> of my code, because If I wanted a mutli-line comment I'd either use
> a /* */ style, or another '//' at the beginning of the next line(S).
It would be surprising to find it in any code written by a
person. But not really surprising to find it in code that is
programmatically produced or processed.
> But the fix is easy and doesn't add any lines:
> [...]
Still has some problems. Try this test input ('gcc -E' may
provide a good basis for comparison):
================
/\
* This is a comment */
================
/* This is a comment *\
/But this is not a comment /**/
================
/\
/ This is a comment
This line is not a comment
================
#define foo "\\
\
"/*"
foo
================
> And one more thought.. (notice I've dropped describing them as
> "final":) Somewhere in the arguments against my opinions,
I don't know about other people, but my comments were not meant
as arguments. I meant only to report the motivations of the
people on the standardization committee who made the decision
for the orginal C standard.
> statements were made something to the effect of:
>
> "This sequence \\<nl> would not be manually entered, but having
> '\\','\n' take precedence would make it much easier for a program
> that limited lines to a printable length".
>
> The thing is, if you want to limit a program to a certain
> "printable" length and keep it readable and still be valid source
> code, there's nothing "simple" about it and you would have to scan
> through the lines anyway.
If program source is being mechanically generated, there may be
no expection that it will be, and no special effort made to make
it be, readable especially. The use of (arbitrary) line breaking
may be simply a protection against lines that are accidentally
longer than some externally imposed limit.
> Reason: '\t' - the TAB character [...]
If program source is being mechanically generated, presumably it
would choose to use spaces rather than tabs. For character
constants and string literals, a \t escape could be used (and
this is probably good practice anyway).
> So I'm not sure I buy the reasoning. Which makes me still think
> this "feature" came from a previous implementation and actually
> makes the language slightly worst, not better (see my previous
> posts for my reasoning).
I think there are two things missing here. The first is what
alternatives are being considered for comparison? No doubt the
standardiation committee did consider possible alternatives, but
they may not have considered - or may have ruled out - one or
more alternatives that you think would be better. The second is
what factors are important to take into consideration when
comparing alternatives? It seems likely that the factors you
would take into account are not the same as those considered by
the people who wrote the C standard. Also the weights may be
different: something you consider important may have been judged
to be much less so by the standardization committee, and vice
versa. That is not to say that your ideas are wrong, but if you
want your comments to be more than just empty voicing of opinion,
I think you should say explicitly what alternatives you mean to
compare against, and what considerations and weighting factors
apply in judging different alternatives.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-17 04:13 -0800 |
| Message-ID | <6a2e3784-1cb3-4d6a-99c2-6ac650dd6fben@googlegroups.com> |
| In reply to | #158374 |
>It would be surprising to find it in any code written by a
>person. But not really surprising to find it in code that is
>programmatically produced or processed.
>> But the fix is easy and doesn't add any lines:
>Still has some problems.
The "fix" did address the problem/code you originally suggested where the
"\<nl>" was at the end of the comment, however you are correct that It did
not address '\<nl>' sequences occurring within the "/*" or "//" which begins
a comment (my bad).
To fully implement this "feature" you pretty much have to do it like CPP does
and ignore "\<nl>" sequences at the end of lines and carry any preceding \ to
the start of the following line. See (YACPE) below:
>If program source is being mechanically generated, there may be
>no expection that it will be, and no special effort made to make
>it be, readable especially. The use of (arbitrary) line breaking
>may be simply a protection against lines that are accidentally
>longer than some externally imposed limit.
I've written a fair bit of code over the years which generated C code. I do
in general try to generate at least somewhat readable code, because you never
know if/when you might need to look at that code.
I've also written programs which convoluted previously readable source with
the intention of making it as unreadable as possible while still compiling to
the same executable. This is a different matter altogether (and now that I am
aware of this "feature" I may make use if it if doing such things in the
future :)
>> Reason: '\t' - the TAB character [...]
>If program source is being mechanically generated, presumably it
>would choose to use spaces rather than tabs. For character
>constants and string literals, a \t escape could be used (and
>this is probably good practice anyway).
When manually entering code that will include tabs on it's output, I often
while doing the strings, set my editor to 8 space tabs (most common) and
then visually enter the string using actual tab characters so that I can see
how it's going to look. Afterward, I change them to \t, but I DO sometimes
make mistakes and have left a couple behind.
The thing is: the initial comment was about a program to "make other source
printable with a line length limitation" - and you absolutely CANNOT control
what other people do. You might not put 0x09 characters in your strings, but
you can't be sure a general program you write to process C source would never
see one... So you would have to account for them in such a program.
>I think there are two things missing here. The first is what
>alternatives are being considered for comparison? No doubt the
>standardiation committee did consider possible alternatives, but
>they may not have considered - or may have ruled out - one or
>more alternatives that you think would be better.
>That is not to say that your ideas are wrong, but if you
>want your comments to be more than just empty voicing of opinion,
>I think you should say explicitly what alternatives you mean to
>compare against...
I thought I was pretty clear... what I would have preferred to see is that
"\\<nl>" not be given special consideration. I can't easily see a situation
where I would actually use this, and I do realize that it would probably an
error in manually entered code. So I would WANT it to cause an error, not
compile into something I didn't intend.
Compilers aren't just about turning source code into executables. They are
also about identifying and reporting mistakes.
The idea that a language should be "worsened" to make it easier for people to
write code to generate it seems counter productive. Sure I might have to put
very small additional effort into the program which generates code, but once
it is debugged it will continue to generate valid code without further effort.
In contrast I'm pretty sure the overall amount of code manually entered FAR
exceeds the amount generated by software ... so it seems counter productive
to modify the language standard to benefit the former while being less benefit
to the latter.
I can think of lots of things in C source which would cause errors -- so why
not extend the language to make these nonsense things do other valid stuff?
Because doing do would add work to make the language worse! - but why did
"\\<nl>" receive such special consideration - I expect it was because an
existing implementation did it this way and "we don't want to break existing
code" - this is the reason I initially suggested it might have been allowed but
not mandated.
>The second is what factors are important to take into consideration when
>comparing alternatives? It seems likely that the factors you would take
>into account are not the same as those considered by the people who wrote
>the C standard.
Indeed - that's the point of this whole continued discussion!
Here is YACPE (Yet Another Challenge Program Entry):
Note that like CPP it ignores "\<nl>" this CAN result in long lines
being produced. I could have dealt with this but it was not a stated
goal in the challenge, and would have made it more tricky to stay within
the 25 line function body limit.
Also, not the way I probably would have initially written it had I been aware
of this language "feature", but it was easy to change my previous entry to
accommodate this latest extra requirement.
---------------------------------------
/*
* 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.
*
* Dave Dunfield - Jan 2021
*/
#include <stdio.h>
unsigned short // at least 16 bits to insure '& 0xFF00' works
C0; // Last character read
unsigned char
C1, // Previous character read
Imode; // Input mode
// Read a single character, ignoring C sequence: \<nl>
unsigned rdchar1(void)
{
unsigned short x;
static unsigned short x1;
for(;;) {
if(x = x1)
x1 = 0;
else
x = getc(stdin);
if(x != '\\')
return x;
if((x = getc(stdin)) != '\n') {
x1 = x;
return '\\'; } }
}
// Read one character, excluding content of comments
unsigned char rdchar2(void)
{
for(;;) {
C1 = C0;
// Assumes 8-bit char set, not including 0 and EOF is >255
if((C0 = 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 = 0;
C0=' '; } // Replace /*...*/ with single space
continue;
case '/' : // Inside '//' comment
if(C1 == '\n')
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 single 'switch' is the only thing within an 'if'
if(C1 == '/') switch(C0) {
case '*': // Starting '/*' comment
case '/': // Starting '//' comment
Imode = C0;
continue; } }
return C1; }
}
// 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();
putc(C1, stdout);
} while(!(C0 & 0xFF00)); // Till EOF has been read
}
//Dave
//Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-01-17 14:18 +0000 |
| Message-ID | <YGXMH.896634$b5kb.733140@fx15.ams4> |
| In reply to | #158406 |
On 17/01/2021 12:13, Dave Dunfield wrote: >> That is not to say that your ideas are wrong, but if you >> want your comments to be more than just empty voicing of opinion, >> I think you should say explicitly what alternatives you mean to >> compare against... > > I thought I was pretty clear... what I would have preferred to see is that > "\\<nl>" not be given special consideration. I can't easily see a situation > where I would actually use this, and I do realize that it would probably an > error in manually entered code. So I would WANT it to cause an error, not > compile into something I didn't intend. Using \ as line continuation is fine. What's perverse with C is allowing it in the middle of any token! People try to justify it (makes code generation easier etc) but the fact remains that pretty much no other language, other than those also using the CPP, does it that way. If they have a line continuation character, it will be between tokens, simplifying lexers across a thousand languages. If injecting arbitrary line breaks into source code is useful for any reason, then it is something that can trivially be done outside the language. That way it can be used for any language, not just C. In fact I did that just now: a 20-line script to split up any text file into very short lines, and 30-line script to do the slightly more fiddly job of splicing lines back together to recreate the original. > Compilers aren't just about turning source code into executables. They are > also about identifying and reporting mistakes. > > The idea that a language should be "worsened" to make it easier for people to > write code to generate it seems counter productive. Sure I might have to put > very small additional effort into the program which generates code, but once > it is debugged it will continue to generate valid code without further effort. > In contrast I'm pretty sure the overall amount of code manually entered FAR > exceeds the amount generated by software ... so it seems counter productive > to modify the language standard to benefit the former while being less benefit > to the latter. > > I can think of lots of things in C source which would cause errors -- so why > not extend the language to make these nonsense things do other valid stuff? > Because doing do would add work to make the language worse! - but why did > "\\<nl>" receive such special consideration - I expect it was because an > existing implementation did it this way and "we don't want to break existing > code" - this is the reason I initially suggested it might have been allowed but > not mandated. Most of the bad features in C weren't fixed decades ago because they didn't want to break a few tens of thousands of lines of existing code. Now they can't be fixed because there are /billions/ of lines of existing code! (Plus a generation of programmers brainwashed into thinking they are must-have features.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-17 18:02 +0000 |
| Message-ID | <20210117095231.933@kylheku.com> |
| In reply to | #158408 |
On 2021-01-17, Bart <bc@freeuk.com> wrote: > On 17/01/2021 12:13, Dave Dunfield wrote: > >>> That is not to say that your ideas are wrong, but if you >>> want your comments to be more than just empty voicing of opinion, >>> I think you should say explicitly what alternatives you mean to >>> compare against... >> >> I thought I was pretty clear... what I would have preferred to see is that >> "\\<nl>" not be given special consideration. I can't easily see a situation >> where I would actually use this, and I do realize that it would probably an >> error in manually entered code. So I would WANT it to cause an error, not >> compile into something I didn't intend. > > Using \ as line continuation is fine. What's perverse with C is allowing > it in the middle of any token! > > People try to justify it (makes code generation easier etc) but the fact > remains that pretty much no other language, other than those also using > the CPP, does it that way. I dug up the original (or close to the orignal) /bin/cpp sources in the Version 7 Unix tree from 1979, and posted about it elsewhere in the thread. The original CPP did not implement this backslash everywhere in a token. It was strictly for continuing preprocessing directives, and was recognized as a token while lexically analyzing a directive. So for instance, this would not work: #define foo '\ a' The issue was that CPP did only a very light lexical analysis job, recognizing only decimal numbers, character constants and comments. It was oblivious to string literals for instance, so this was possible #define foo bar #define lit "foo" char *bar = lit; /* actually "bar" */ Since it was oblivious to string literals, it would allow the backslash inside them: #define lit "fo\ o" And of course, string literals can have backslash escapes; but since cpp runs in a separate process, the backslash-newline has precedence; it is eaten and the string literal token doesn't see it. So this set a precedent for the current situation. To make it consistent, the best thing was to require it to be that way regardless of tokens. The current C preprocessing still makes a difference between preprocessor tokens and tokens as they exist in the later translation stages. Therefore, the preprocessing stages *cannot* have a rule whereby the backslash continuation is recognized only outside of tokens. They could only have a broken rule whereby it's only allowed outside of preprocessor tokens (like in the 1979 cpp). That is worse than a consistent rule that it's recognized in the raw character stream before any tokenization. To recap, he original view of the backslash is that it's a preprocessor feature which enables long #define directives to be split across multiple lines. It was not introduced as a feature for chopping up long non-preprocessing lines in a C program. (That would only ever be needed for string literals, and C already supports splitting up string literals by juxtaposition.) The backslash is still largely used today in accordance with the original intent: for writing multi-line #define (and, more rarely, other) preprocessing directives. Using a continuation backslash outside of that use can be regarded as a blemish in a program, worthy of a diagnostic.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-01-17 15:12 -0500 |
| Message-ID | <lS0NH.15225$gs1.13822@fx26.iad> |
| In reply to | #158423 |
On 1/17/21 1:02 PM, Kaz Kylheku wrote: > On 2021-01-17, Bart <bc@freeuk.com> wrote: >> On 17/01/2021 12:13, Dave Dunfield wrote: >> >>>> That is not to say that your ideas are wrong, but if you >>>> want your comments to be more than just empty voicing of opinion, >>>> I think you should say explicitly what alternatives you mean to >>>> compare against... >>> >>> I thought I was pretty clear... what I would have preferred to see is that >>> "\\<nl>" not be given special consideration. I can't easily see a situation >>> where I would actually use this, and I do realize that it would probably an >>> error in manually entered code. So I would WANT it to cause an error, not >>> compile into something I didn't intend. >> >> Using \ as line continuation is fine. What's perverse with C is allowing >> it in the middle of any token! >> >> People try to justify it (makes code generation easier etc) but the fact >> remains that pretty much no other language, other than those also using >> the CPP, does it that way. > > I dug up the original (or close to the orignal) /bin/cpp sources > in the Version 7 Unix tree from 1979, and posted about it elsewhere > in the thread. > > The original CPP did not implement this backslash everywhere in a token. > > It was strictly for continuing preprocessing directives, and was > recognized as a token while lexically analyzing a directive. > > So for instance, this would not work: > > #define foo '\ > a' > > The issue was that CPP did only a very light lexical analysis job, > recognizing only decimal numbers, character constants and comments. > It was oblivious to string literals for instance, so this was possible > > #define foo bar > #define lit "foo" > char *bar = lit; /* actually "bar" */ > > Since it was oblivious to string literals, it would allow the backslash > inside them: > > #define lit "fo\ > o" > > And of course, string literals can have backslash escapes; but since > cpp runs in a separate process, the backslash-newline has precedence; > it is eaten and the string literal token doesn't see it. > > So this set a precedent for the current situation. > > To make it consistent, the best thing was to require it to be that way > regardless of tokens. > > The current C preprocessing still makes a difference between > preprocessor tokens and tokens as they exist in the later translation > stages. > > Therefore, the preprocessing stages *cannot* have a rule whereby the > backslash continuation is recognized only outside of tokens. They could > only have a broken rule whereby it's only allowed outside of > preprocessor tokens (like in the 1979 cpp). That is worse than a > consistent rule that it's recognized in the raw character stream before > any tokenization. > > To recap, he original view of the backslash is that it's a preprocessor > feature which enables long #define directives to be split across > multiple lines. It was not introduced as a feature for chopping up > long non-preprocessing lines in a C program. > (That would only ever be needed for string literals, and C already > supports splitting up string literals by juxtaposition.) > > The backslash is still largely used today in accordance with the > original intent: for writing multi-line #define (and, more rarely, > other) preprocessing directives. > > Using a continuation backslash outside of that use can be regarded > as a blemish in a program, worthy of a diagnostic. > Using a bit of speculative theoretical forensic historical analysis (or my own SWAG), my guess is that some significant platform, and not necessarily a 'Unix' source, needed this feature, likely for machine generated code. Maybe some platform with fairly rigid line length limits. The first ANSI/ISO Standard tried very hard to let as many possible 'conforming' programs (programs conforming to their current implementation) continue to be working programs. Making invalid systax valid isn't a big problem, as that doesn't break any code. This is one source of much of the inplementation defined behavior in the standard, like what does malloc(0) return, it allowed differing implementations to exist, with the programs written that assumed that behavior. SOmething as fundamental as token parsing probably didn't want to be left up to implementation defined rules, so they made everyone handle it a given way (or at least act like they did).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-01-17 21:39 +0000 |
| Message-ID | <782NH.293324$9X39.68832@fx26.ams4> |
| In reply to | #158423 |
On 17/01/2021 18:02, Kaz Kylheku wrote: > On 2021-01-17, Bart <bc@freeuk.com> wrote: > To recap, he original view of the backslash is that it's a preprocessor > feature which enables long #define directives to be split across > multiple lines. It was not introduced as a feature for chopping up > long non-preprocessing lines in a C program. > (That would only ever be needed for string literals, and C already > supports splitting up string literals by juxtaposition.) Actually that would have been useful to me at one point if I'd known, as I'd been generating C with very long string literals (eg. 100K characters in one string), that were not supported by a certain compiler (MSVC). Splitting into shorter strings is not so easy, as you can't do that in the middle of an escape sequence. Inserting \newline would have worked. But this really only needs support inside string literals, which is easy to do (just ignore any \newline instances). It doesn't need support anywhere else, other than for multi-line macros, and there it's not needed inside tokens. > The backslash is still largely used today in accordance with the > original intent: for writing multi-line #define (and, more rarely, > other) preprocessing directives. > > Using a continuation backslash outside of that use can be regarded > as a blemish in a program, worthy of a diagnostic. Given how it's supposed to be processed, that would be difficult to diagnose.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-20 10:57 -0800 |
| Message-ID | <864kjbo2ql.fsf@linuxsc.com> |
| In reply to | #158406 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
>> It would be surprising to find it in any code written by a
>> person. But not really surprising to find it in code that is
>> programmatically produced or processed.
>
>
>>> But the fix is easy and doesn't add any lines:
>>
>> Still has some problems.
>
> The "fix" did address the problem/code you originally suggested
> where the "\<nl>" was at the end of the comment, however you are
> correct that It did not address '\<nl>' sequences occurring within
> the "/*" or "//" which begins a comment (my bad).
My reply (dated January 4) to your first program had this example
(now indented, so please imagine the example with four leading
spaces on each line are removed):
#define START_START_START
int x = 0 /\
*blah*/ + 1;
#define END_END_END_END_END
> To fully implement this "feature" you pretty much have to do it
> like CPP does and ignore "\<nl>" sequences at the end of lines and
> carry any preceding \ to the start of the following line.
Not so. There are several different ways of approaching the
problem. My posted solution uses a pure state machine (plus
one counter) to take care of both circumstances appropriately.
Of the nine earliest participants, all wrote versions that
kept <backslant><newline> inside character constants and
string literals, and also looked for that in comments; most
were successful to a fairly high degree (four were exactly
right, three had minor bugs that were easy to identify and fix,
and two showed wrong behaviors in some cases that I didn't try
to track down).
>> If program source is being mechanically generated, there may be
>> no expection that it will be, and no special effort made to make
>> it be, readable especially. The use of (arbitrary) line breaking
>> may be simply a protection against lines that are accidentally
>> longer than some externally imposed limit.
>
> I've written a fair bit of code over the years which generated C
> code. I do in general try to generate at least somewhat readable
> code, [...]
Not everyone does that. The C standard needs to accommodate
both, if I understand what its authors say about their
motivations.
>>> Reason: '\t' - the TAB character [...]
>>
>> If program source is being mechanically generated, presumably it
>> would choose to use spaces rather than tabs. For character
>> constants and string literals, a \t escape could be used (and
>> this is probably good practice anyway).
>
> When manually entering code that will include [...]
My statement is about code that is mechanically generated, not
manually entered.
> The thing is: the initial comment was about a program to "make
> other source printable with a line length limitation" [...]
I'm not sure what other people may have said. In my first post
on the subject, I gave a quote from the Rationale document that
says this:
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.
Nothing there about printability or readability.
>> I think there are two things missing here. The first is what
>> alternatives are being considered for comparison? No doubt the
>> standardiation committee did consider possible alternatives, but
>> they may not have considered - or may have ruled out - one or
>> more alternatives that you think would be better.
>>
>> That is not to say that your ideas are wrong, but if you
>> want your comments to be more than just empty voicing of opinion,
>> I think you should say explicitly what alternatives you mean to
>> compare against...
>
> I thought I was pretty clear... what I would have preferred to see
> is that "\\<nl>" not be given special consideration.
This statement also is not clear. Are you talking about three
characters (that is, <backslant><backslant><newline>)? Or are you
talking about just two characters (that is, <backslant><newline>)?
As the C standard is now, it does not give any special consideration
to <backslant><backslant><newline>. The two final characters are
treated as a line continuation sequence, removed in translation
phase three, and the resulting logical line is processed as usual.
If you mean that <backslant><newline> not be taken as a sequence
that joins physical lines into logical lines, that option is not
one that could be taken by the C standard committee, because it
would break too much existing code. There is just no way they
could do that, considering the mission of what they were trying
to accomplish.
> I can't
> easily see a situation where I would actually use this, and I do
> realize that it would probably an error in manually entered code.
> So I would WANT it to cause an error, not compile into something I
> didn't intend.
The authors of the C standard had to consider the views (some very
strongly held!) of many different people when writing the standard.
Judging by the results, it seems a good bet that your view is not
close to any of the majority views.
> [...] The idea that a language should be "worsened" to make it
> easier for people to write code to generate it seems counter
> productive. [...]
My difficulty here is that you have asserted "worsened" but have
not yet articulated any sort of objective metric by which the
"worseness" can be tested. I get that you don't like it. What
reasons can you offer for other people not to like it, including
in particular people who may not share your opinions?
> Here is YACPE (Yet Another Challenge Program Entry):
>
> Note that like CPP it ignores "\<nl>" this CAN result in long lines
> being produced. I could have dealt with this but it was not a stated
> goal in the challenge,
The requirement was implicit in the original problem statement:
there was no allowance mentioned for changing the source outside
of comments. Furthermore there was a clarifying posting made
shortly after the original problem statement that addressed this
requirement explicitly.
> and would have made it more tricky to stay within the 25 line
> function body limit.
The requirement to keep <backslant><newline> sequences that are
not within comments is absolute. The 25 line limit on function
bodies can be viewed as a soft requirement (this relaxing was
mentioned in an earlier posting, but you may not have seen that).
> Also, not the way I probably would have initially written it had I
> been aware of this language "feature", but it was easy to change
> my previous entry to accommodate this latest extra requirement.
> [...source...]
For reference here is a reposting of the clarifying comments
I posted earlier (December 7, 2020).
================================================================
I see there has been a fair amount of activity. Also some
questions and some confusions, so I am prompted to give some
clarifications.
The program is to remove (see below) C comments from a C source
file input, and nothing else. An input with no C comments in it
should be transmitted unchanged (provided its compile-time
behavior is defined, see below). To give an obvious example,
a multi-line macro definition that uses \ at the end of lines
to continue the definition (but has no comments) should appear
in the output exactly as in the input.
The remark about "something sensible" for EOF might be phrased as
anything that doesn't violate The Law of Least Astonishment.
Simply stopping output is okay, either with or without an error
return or diagnostic.
The statement about corner cases is meant to apply to compile-time
undefined behavior (meaning, in the input), and nothing else. Any
input whose compile-time specification has defined behavior,
including implementation-defined behavior, should be processed
correctly. If an input has compile-time undefined behavior, do
something reasonable (like in the previous paragraph), but it
doesn't matter so much what exactly as long as the user is given
some idea of what that will be.
An important property is that the program should transform working
programs into the same working programs. In other word compiling
an input before it is transformed should give the same semantics
as compiling it after it is transformed. There is an exception to
this rule in cases where the C pre-processor stringize operator is
used. In some cases removing a comment and doing nothing else
cannot be done because doing so will change the meaning of the
program. To deal with that problem, it is allowed to put in a
space for a removed comment. Note, putting in a space is allowed
but not required, as long as the input program semantics (not
counting stringize) is unchanged. Hence it is permissible for
programs that use the stringize operator to exhibit different
behavior before and after being transformed. Except for that
though the output semantics should match the input semantics.
Re: removing comments. This might be done by removing comments
entirely (and putting in a single space in some cases), or it
might be done by replacing comments with some "filler" white
space to, for example, preserve line numbers. Undoubtedly it
is easier to simply take the comments out and put in a single
space in their place; more elaborate replacements are allowed
as long as the output has no comments and preserves the program
semantics of the original input.
Part of my motivation in offering the exercise is to see how
people handle a non-trivial "state machiney" kind of program
without using goto statements and without using "big" functions.
The choice of 25 lines is meant to codify that, but it isn't meant
as an exact hard limit - maybe five lines over (to accommodate
style differences) is okay, ten lines over is pushing it.
Incidentally, the problem statement isn't something I just made up
for the newsgroup, but is a simplified version of a utility
program that is used as part of a larger toolkit. Of course I
knew this when I first posted the problem, so I had a more fixed
idea than the original problem statement presented clearly, giving
rise to the resulting confusions etc. I'm sorry the original
problem wasn't stated more clearly, and I hope the statements here
clear up any remaining uncertainties. Please, please, ask about
something if there is any doubt about what is meant.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-21 11:37 -0800 |
| Message-ID | <44c73f50-33af-43bb-afa2-a3b0244c7160n@googlegroups.com> |
| In reply to | #158498 |
>This statement also is not clear. Are you talking about three
>characters (that is, <backslant><backslant><newline>)? Or are you
>talking about just two characters (that is, <backslant><newline>)?
There seems to be a fair bit of confusion on how C constructs and non-
printable characters are shown in postings. Please assume the following
for this message:
<text> means non-printable character: text
[text] Means text exactly as it appears in C source
0xnn for single characters I will use the ASCII encoding:
eg: 0x09 = <tab>, 0x0A = <newline>, 0x20 = <space>
>> I do in general try to generate at least somewhat readable
>> code, [...]
>Not everyone does that. The C standard needs to accommodate
>both, if I understand what its authors say about their motivations.
Agreed completely, the reason I mentioned this was because of a suggestion
that generated code would have significantly differenct lines... It may,
but nothing says it has to.
>>> If program source is being mechanically generated, presumably it
>>> would choose to use spaces rather than tabs. For character
>>> constants and string literals, a \t escape could be used (and
>>> this is probably good practice anyway).
>> When manually entering code that will include [...]
>My statement is about code that is mechanically generated,
>not manually entered.
See above - the point was that nothing prohibits code from being generated
containing [<tab>] characters. Either by design or accident "I intended to change
all [<tab>]s I used for visual feedback while coding the generator with [\t]
but I must have missed some..."
> The thing is: the initial comment was about a program to "make
> other source printable with a line length limitation" [...]
>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 in general have no problem with this.
>As the C standard is now, it does not give any special consideration
>to <backslant><backslant><newline>. The two final characters are
>treated as a line continuation sequence, removed in translation
>phase three, and the resulting logical line is processed as usual.
>> [...] The idea that a language should be "worsened" to make it
>> easier for people to write code to generate it seems counter
>> productive. [...]
By "worse" I meant "less intuitive" - I agree/know that the [\] character
serves two distinct purposes: 1) insert "special" characters, and 2) avoid
processing [<newline>] ... but both cases are generally consistent with the
notion "a special function defined on the next character". Even if this
notion is not stated in the standard, I expect that many programmers would
come to think of it this way.
[\n\t] means: special function 'n' (insert 0x0A) followed by special
function 't' (insert 0x09). [\n\<newline>] means: special function 'n'
(insert 0x0A) followed by special function <newline> (avoid processing
the <newline>). This idea seems to work in almost all cases ... except:
[\\<newline>n] which this notion would suggest to mean: special function
'\' (insert 0x5C) followed by <newline> followed by 'n'. When according
to the standard it really means: special function <newline> (avoid
processing <newline> followed by special function 'n' (insert 0x0A).
Notice that the [n] does NOT immediately follow a [\].
And it's already been established that there would be very few cases where
a programmed would WANT to manually code using this "feature". Which is
another way of saying that many of them might not know about it, or at least
would not likely be thinking of it while coding.
One of the most common typos I make it caused by key bounce. A character gets
entered twice - and I have at least once made this error when entering
[\<newline>] - this usually doesn't cause me a problem because lines so ended
almost always cause another compile error (unless preceded by [\]). It
errors like most other typo's. Bit consider:
[text\\<newline>now...] where I meant [text\n\<newline>now...]
If it compiles, I *might* notice "text\<newline>ow..." in some output where I
should have seen "text<newline>now..." but for quick and dirty things I write
where more of the testing happens (on the fly) ... I might not.
I (personally) think this "feature" makes the language worse, and "the
interest of easing machine generation of C" isn't worth it (IMHO). When
writing a program to generating code, guaranteeing that escape sequences
don't cross lines isn't very hard at all.
FYI, despite the amount of discussion on this one aspect, this isn't a big
problem for me. I only pointed it out because I (personally) wasn't aware of
it before, it seemed somewhat unintuitive, and (IMHO) the standard could have
defined a slightly better (less "worse") language.
>> I thought I was pretty clear... what I would have preferred to see
>> is that "\\<nl>" not be given special consideration.
>If you mean that <backslant><newline> not be taken as a sequence
>that joins physical lines into logical lines, that option is not
>one that could be taken by the C standard committee, because it
>would break too much existing code.
Which is why I originally said something like "may be allow (possibly
with a warning) but should not be mandated". Yeah, you might have to
fix your "generates long C lines" program when moving to a newer compiler
but is this enough of a problem to actually mandate a feature that
makes the language "worse"?
>My difficulty here is that you have asserted "worsened" but have
>not yet articulated any sort of objective metric by which the
>"worseness" can be tested. I get that you don't like it. What
>reasons can you offer for other people not to like it, including
>in particular people who may not share your opinions?
Hopefully my description just above describes better what I mean by "worse".
It has already been established several time that people wouldn't likely
manually code this way .. so the question really becomes:
How many people would like C less if they had to think about generating
very long lines in code containing escape sequences .vs. how many people
would like C more if the notion that [\] affects the next character in
their source was always true - I think I've made my opinion excruciatingly
clear :) but I can only speak for myself!
> Here is YACPE (Yet Another Challenge Program Entry):
>
>> Note that like CPP it ignores "\<nl>" this CAN result in long lines
>> being produced. I could have dealt with this but it was not a stated
>> goal in the challenge,
>The requirement was implicit in the original problem statement:
Sigh! - YACPE:
/*
* whole line comments could easily be absent and should not
* count against to 25 lime function body limit.
*
* Assumes a valid 'C' program as input, will not detect
* certain errors affecting comments, quotes or escapes.
*
* Dave Dunfield - Feb 2021
*/
#include <stdio.h>
unsigned short // at least 16 bits to insure '& 0xFF00' works
Cp, // Pending input character
C0; // Last character read
unsigned char
C1, // Previous character read
Enl, // Escaped NewLine seen
Imode; // Input mode
// Line continuation sequences occurring within comments are removed.
// But what about comments starting with [/\<newline>*] or [/<newline>/] ?
// I decided to remove them, but if you prefer those [\<newline>]s to
// remain, change all [/*1] in this file to [//1], and all [//2] to [/*2].
// You could also remove all references to [Enl].
// 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 = 255; // So we can re-insert it in output
//2*/ if(!Imode)
//2*/ fputs("\\\n", stdout);
}
}
// 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;
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; }
}
// 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();
/*1*/ if(Enl) { // If '\\', '\n' was seen outside of comment, reinsert
/*1*/ fputs("\\\n", stdout);
/*1*/ Enl = 0; }
putc(C1, stdout);
} while(!(C0 & 0xFF00)); // Till EOF has been read
}
//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-22 00:30 -0500 |
| Message-ID | <rudnt5$8db$1@dont-email.me> |
| In reply to | #158524 |
On 1/21/21 2:37 PM, Dave Dunfield wrote: [Missing attribution]: > On Wednesday, January 20, 2021 at 1:57:54 PM UTC-5, Tim Rentsch wrote: ... >> As the C standard is now, it does not give any special consideration >> to <backslant><backslant><newline>. The two final characters are >> treated as a line continuation sequence, removed in translation >> phase three, and the resulting logical line is processed as usual. That should be translation phase 2. ... > [\n\t] means: special function 'n' (insert 0x0A) followed by special > function 't' (insert 0x09). [\n\<newline>] means: special function 'n' > (insert 0x0A) followed by special function <newline> (avoid processing > the <newline>). This idea seems to work in almost all cases ... except: > > [\\<newline>n] which this notion would suggest to mean: special function > '\' (insert 0x5C) followed by <newline> followed by 'n'. When according > to the standard it really means: special function <newline> (avoid > processing <newline> followed by special function 'n' (insert 0x0A). > Notice that the [n] does NOT immediately follow a [\]. The right way to think about this is in terms of translation phases, which is precisely how the C standard defines it. [\<newline>] gets removed during translation phase 2, converting [\\<newline>n] into [\n], which gets interpreted as what you call "special function 'n'" during translation phase 5 (the C standard calls them escape sequences). Using your way of thinking about these constructs make them seem more complicated than they really are. > I (personally) think this "feature" makes the language worse, and "the > interest of easing machine generation of C" isn't worth it (IMHO). When I don't use machine generated code, but many people do - a large enough number that the committee is unlikely to change this any time within the next couple of decades. > writing a program to generating code, guaranteeing that escape sequences > don't cross lines isn't very hard at all. Yes, but writing code that doesn't worry about that issue, because it doesn't have to, is even easier. >>> I thought I was pretty clear... what I would have preferred to see >>> is that "\\<nl>" not be given special consideration. As Tim pointed out above, is it NOT given special consideration, the behavior you see is a consequence of the translation phases. >> If you mean that <backslant><newline> not be taken as a sequence >> that joins physical lines into logical lines, that option is not >> one that could be taken by the C standard committee, because it >> would break too much existing code. > > Which is why I originally said something like "may be allow (possibly > with a warning) but should not be mandated". Yeah, you might have to > fix your "generates long C lines" program when moving to a newer compiler > but is this enough of a problem to actually mandate a feature that > makes the language "worse"? Yes.
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-22 09:09 -0800 |
| Message-ID | <eb6b098c-a3cc-4ee5-9351-fdb33a5e6e66n@googlegroups.com> |
| In reply to | #158544 |
> >> As the C standard is now, it does not give any special consideration > >> to <backslant><backslant><newline>. The two final characters are > >> treated as a line continuation sequence, removed in translation > >> phase three, and the resulting logical line is processed as usual. > That should be translation phase 2. > > [\\<newline>n] which this notion would suggest to mean: special function > > '\' (insert 0x5C) followed by <newline> followed by 'n'. When according > > to the standard it really means: special function <newline> (avoid > > processing <newline> followed by special function 'n' (insert 0x0A). > > Notice that the [n] does NOT immediately follow a [\]. > The right way to think about this is in terms of translation phases, > which is precisely how the C standard defines it. [\<newline>] gets > removed during translation phase 2, converting [\\<newline>n] into [\n], > which gets interpreted as what you call "special function 'n'" during > translation phase 5 (the C standard calls them escape sequences). Using > your way of thinking about these constructs make them seem more > complicated than they really are. I actually understand/get all of this. As someone who over the years had designed many products (including a few compilers and interpreters), and dealt with many users, I guess the main reason for my little concern is that it's generally not great if a user has to know about the way your product is technically designed. I know a LOT of people who couldn't tell you how the engine works in their car. When your product is a compiler, they your "users" are programmers. Hopefully more "software engineer" type, but I know a number C programmers who have never written a compiler and could only "guess" at how one works. So my concern is why expose to your users a characteristic of your product which most of them will never want to use, those that do don't need it (in this case very little extra code would be required to avoid breaking escape sequences) and all those that don't might get "bitten" by it if it occurs by accident in their code. And more specifically why mandate it. > > writing a program to generating code, guaranteeing that escape sequences > > don't cross lines isn't very hard at all. > Yes, but writing code that doesn't worry about that issue, because it > doesn't have to, is even easier. And if the number of different people writing code that generates code is very large, this might be a good reason for it. I can think of a few things which might make writing certain specific types of programs easier. But I don't think if C as "a language for producing machine generated code".. you can certainly do that, but it's far more general purpose that that. 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-22 13:47 -0500 |
| Message-ID | <ruf6k8$fi$1@dont-email.me> |
| In reply to | #158555 |
On 1/22/21 12:09 PM, Dave Dunfield wrote: >>>> As the C standard is now, it does not give any special consideration >>>> to <backslant><backslant><newline>. The two final characters are >>>> treated as a line continuation sequence, removed in translation >>>> phase three, and the resulting logical line is processed as usual. >> That should be translation phase 2. > >>> [\\<newline>n] which this notion would suggest to mean: special function >>> '\' (insert 0x5C) followed by <newline> followed by 'n'. When according >>> to the standard it really means: special function <newline> (avoid >>> processing <newline> followed by special function 'n' (insert 0x0A). >>> Notice that the [n] does NOT immediately follow a [\]. > >> The right way to think about this is in terms of translation phases, >> which is precisely how the C standard defines it. [\<newline>] gets >> removed during translation phase 2, converting [\\<newline>n] into [\n], >> which gets interpreted as what you call "special function 'n'" during >> translation phase 5 (the C standard calls them escape sequences). Using >> your way of thinking about these constructs make them seem more >> complicated than they really are. > > I actually understand/get all of this. > > As someone who over the years had designed many products (including a few compilers and > interpreters), and dealt with many users, I guess the main reason for my little concern is that > it's generally not great if a user has to know about the way your product is technically designed. > I know a LOT of people who couldn't tell you how the engine works in their car. When your product > is a compiler, they your "users" are programmers. Hopefully more "software engineer" type, but I know > a number C programmers who have never written a compiler and could only "guess" at how one works. > > So my concern is why expose to your users a characteristic of your product which most of them will > never want to use, those that do don't need it (in this case very little extra code would be required to > avoid breaking escape sequences) and all those that don't might get "bitten" by it if it occurs by accident > in their code. And more specifically why mandate it. The translation phases are often misinterpreted as describing details of the implementation, but that's not what they are for. As it says in 5.1.1.2p1: "The precedence among the syntax rules of translation is specified by the following phases." Footnote 5 explains "The description is conceptual only, and does not specify any particular implementation." That precedence is sufficiently important that it deeply informs the design of C compilers. An implementation could consist of 8 different Unix-style filter routines, each of which implements one phase of translation, with the output from each of the first 7 phases used as input to the next phase. However, that's not actually mandated, and most real implementations merge multiple translation phases into a single actual process, split some translation phases between two or more different processes, and the communication between the processes that make up a compiler is often more complicated than implied by the translation phases model. The syntax rules defined by the C standard are specified in terms of transformations to the text being interpreted. The translation phases indicate that transformations described in lower numbered phases have priority over the transformations that occur in higher numbered phases. In particular, the transformation that removes [\<newline>] has priority over the transformation that recognizes [\n] as an escape sequence for a newline characters (if it occurs in a context where such an escape sequence is allowed), which means that [\\<newline>n] gets recognized as a newline character. If the standard merely left the priority unspecified, whether or not [\\<newline>n] was a syntax error would be unclear. You apparently desire that it would unambiguously be a syntax error. To change the standard to make that true would require more than simply merging translation phases 3-5. It would require special casing to prohibit the [\<newline>] removal from happening before [\n] is recognized as an escape sequence - without special casing, doing those two transformations in the same order that is currently mandatory would still be allowed.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-22 19:00 +0000 |
| Message-ID | <20210122103411.187@kylheku.com> |
| In reply to | #158555 |
On 2021-01-22, Dave Dunfield <dave.dunfield@gmail.com> wrote: > As someone who over the years had designed many products (including a few compilers and > interpreters), and dealt with many users, I guess the main reason for my little concern is that > it's generally not great if a user has to know about the way your > product is technically designed. This is absolutely mandatory when the product is a programming language, and the user is a software engineer. The user of a programming language must understand the requirements, which give the interface contract between the program and the implementation. This is still true even of soft, high-level, "forgiving" languages in which undefined behavior doesn't happen every time you look away from the monitor to have a sneeze, unlike C. I'm amazed anyone would think otherwise, let alone with decades of experience. > I know a LOT of people who couldn't tell you how the engine works in > their car. When your product is a compiler, they your "users" are > programmers. How backslash line continuations work in C is not "how the compiler works". It's an external requirement, visible to the program. It's like whether the gas pedal is to the left or right of the brake. > So my concern is why expose to your users a characteristic of your > product which most of them will never want to use, those that do don't > need it (in this case very little extra code would be required to Someone needed it because the feature was added in 1979, a decade before ANSI C. It was added in a goofy way, and imitated in incompatible ways by others, so the spec had to do something reasonable. > avoid breaking escape sequences) and all those that don't might get > "bitten" by it if it occurs by accident in their code. And more > specifically why mandate it. > >> > writing a program to generating code, guaranteeing that escape sequences >> > don't cross lines isn't very hard at all. >> Yes, but writing code that doesn't worry about that issue, because it >> doesn't have to, is even easier. > > And if the number of different people writing code that generates code > is very large, this might be a The amount of C generation out there is huge. There are entire programming languages that generate C as their back end (and C++ started as one of them, for that matter). The way backslash line continuations work in C is the simplest, most intuitive possible thing for the end user (programmer) to understand: If the last character of a line is a backslash, that is absolutely a line continuation. That backslash and the following newline are deleted, no matter what comes before them. A backslash in this position has no other meaning. A backslash anywhere else does not have this meaning; it is free to have other meanings assigned by the language, such as its role in string and character literal tokens. This is a very simple encoding matter of the raw program text, having nothing to do with its token syntax. Just like, say, the division of the bytes in a TCP/IP stream into packets has nothing to do with that stream's content. The C program is made out of "packets" which are lines, and the backslash is the flag which indicates a "fragmented packet": one or more fragments follow and the last one is indicated by not having trailing backslash. The byte stream is understood after defragmentation. Fragmentation issues should not leak into the higher level of the protocol; that is a good design. Furthermore, fragments hould not be constrained to only occur on semantic boundaries within the application byte stream. A protocol receiving an IP datagram should get a complete one that has been reassembled from fragments, so that fragmentation re-assembly doesn't have to be repeated in every IP-based protocol. In other words, clean layering is good. Good for implementations, good for human understanding, because the requirements for different layers that do not interact can be understood independently. Clean layering is more testable. You can have separate test cases that show each layer is doing its job, and from that, correct end to end operation should follow. Line continuation could be tested with a completely random character stream. I.e that test cases like: <randomchars>\ <morerandomchars>\ <fewmorerandomchars> produce <randomchars><morerandomchars><fewmorerandomchars> The next translation phase can then be tested with cases that do not include line continuation; that matter is settled by a correctly working previous translation phase. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-01-22 19:42 +0000 |
| Message-ID | <CUFOH.426866$ca39.420263@fx28.ams4> |
| In reply to | #158559 |
On 22/01/2021 19:00, Kaz Kylheku wrote: > <randomchars>\ > <morerandomchars>\ > <fewmorerandomchars> > > produce > > <randomchars><morerandomchars><fewmorerandomchars> > > The next translation phase can then be tested with cases that do not > include line continuation; that matter is settled by a correctly working > previous translation phase. This is what makes the challenge in the OP harder. Some of those \newline sequences need to be retained, depending on context which normally a compiler will know nothing about at this stage. Which raises an important point, that even if this extra pass seems simple enough, it can make creating tools to work on source code more difficult. (Personally I'd object to the requirement for an extra pass for such purposes at all. You don't need an explict pass, but without it, character scanning of source code is more fiddly. As far as I'm aware, the syntaxes I use myself are strongly line oriented: you could tokenise a random line of source completely independently from what precedes it, or what follows. So that, for example, makes syntax highlighting in code editors much simpler. You seem intent however to make excuses for every badly thought out feature in C!)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-22 21:16 +0000 |
| Message-ID | <20210122130300.245@kylheku.com> |
| In reply to | #158560 |
On 2021-01-22, Bart <bc@freeuk.com> wrote: > On 22/01/2021 19:00, Kaz Kylheku wrote: > >> <randomchars>\ >> <morerandomchars>\ >> <fewmorerandomchars> >> >> produce >> >> <randomchars><morerandomchars><fewmorerandomchars> >> >> The next translation phase can then be tested with cases that do not >> include line continuation; that matter is settled by a correctly working >> previous translation phase. > > This is what makes the challenge in the OP harder. No, it doesn't; you just read input from state machine which handles that requirement, and then the rest of the code is completely oblivious to any line continuation requirement. > \newline sequences need to be retained, depending on context which > normally a compiler will know nothing about at this stage. The requirement for retaining uncommented line continuations was something that was needed by Tim in the original situation where the original program was deployed; it's not coming from the C language. I found my program quite easy to modify to accomodate the requirement, even though it was based on abuse of goto, which supposedly makes maintenance harder. > Which raises an important point, that even if this extra pass seems > simple enough, it can make creating tools to work on source code more > difficult. I'm afraid that is a foregone conclusion, because C preprocessing, as such, makes creation of tools difficult! That would be the case even if preprocessing didn't have line continuations. Line continuations are an error in an nth-decimal place in the equation of "C preprocessing = difficult tooling". Any tool that wants to analyze C to do anything has to preprocess it before parsing it, or else it's just doing a hack job. So for instance, say we want a refactoring tool: to be accurate it has to preprocess the code, then do the transformations, and then somehow put back all the preprocessing and macrology in order to create the smallest possible diff to the original. For instance, suppose we want to add "context *" argument to every function that starts with foo_. Problem: some of those functions are defined by a macro like this: DEF_BLARG(foo, x) the macro does not heven have a place where to insert that argument "context *", even if the tool could work backwards to the macro.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-22 16:41 -0500 |
| Message-ID | <rufgpq$8te$1@dont-email.me> |
| In reply to | #158562 |
On 1/22/21 4:16 PM, Kaz Kylheku wrote: > On 2021-01-22, Bart <bc@freeuk.com> wrote: >> On 22/01/2021 19:00, Kaz Kylheku wrote: >> >>> <randomchars>\ >>> <morerandomchars>\ >>> <fewmorerandomchars> >>> >>> produce >>> >>> <randomchars><morerandomchars><fewmorerandomchars> >>> >>> The next translation phase can then be tested with cases that do not >>> include line continuation; that matter is settled by a correctly working >>> previous translation phase. >> >> This is what makes the challenge in the OP harder. > > No, it doesn't; you just read input from state machine which > handles that requirement, and then the rest of the code is completely > oblivious to any line continuation requirement. I haven't attempted this challenge due to lack of interest, but what's been posted on this thread suggests that the need to retain line continuations outside of comments (which is NOT the case for standard C translation), adds significant complexities. >> \newline sequences need to be retained, depending on context which >> normally a compiler will know nothing about at this stage. > > The requirement for retaining uncommented line continuations > was something that was needed by Tim in the original situation where > the original program was deployed; it's not coming from the C language. Correct, and its "the challenge in the OP", not the rules of the C language, that Bart was talking about.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-23 17:46 -0800 |
| Message-ID | <861rebm7ic.fsf@linuxsc.com> |
| In reply to | #158563 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 1/22/21 4:16 PM, Kaz Kylheku wrote: > >> On 2021-01-22, Bart <bc@freeuk.com> wrote: >> >>> On 22/01/2021 19:00, Kaz Kylheku wrote: >>> >>>> <randomchars>\ >>>> <morerandomchars>\ >>>> <fewmorerandomchars> >>>> >>>> produce >>>> >>>> <randomchars><morerandomchars><fewmorerandomchars> >>>> >>>> The next translation phase can then be tested with cases that do >>>> not include line continuation; that matter is settled by a >>>> correctly working previous translation phase. >>> >>> This is what makes the challenge in the OP harder. >> >> No, it doesn't; you just read input from state machine which >> handles that requirement, and then the rest of the code is >> completely oblivious to any line continuation requirement. > > I haven't attempted this challenge due to lack of interest, but > what's been posted on this thread suggests that the need to retain > line continuations outside of comments (which is NOT the case for > standard C translation), adds significant complexities. If line continuations can be stripped out the problem is quite easy, even bordering on trivial. If line continuations (that are not in comments) must be retained then certainly the problem is harder, but still not all that hard. Some of the /programs/ posted have a fair amount of complexity, but the /problem/ doesn't have that much complexity. If you're going to offer an opinion on the complexity of the _problem_, as opposed to the complexity of the programs people have written, it seems fair to ask that you give writing a solution to the problem a try.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-01-23 09:51 -0800 |
| Message-ID | <86im7nmti5.fsf@linuxsc.com> |
| In reply to | #158562 |
Kaz Kylheku <563-365-8930@kylheku.com> writes: > On 2021-01-22, Bart <bc@freeuk.com> wrote: > >> On 22/01/2021 19:00, Kaz Kylheku wrote: >> >>> <randomchars>\ >>> <morerandomchars>\ >>> <fewmorerandomchars> >>> >>> produce >>> >>> <randomchars><morerandomchars><fewmorerandomchars> >>> >>> The next translation phase can then be tested with cases that do not >>> include line continuation; that matter is settled by a correctly working >>> previous translation phase. >> >> This is what makes the challenge in the OP harder. > > No, it doesn't; you just read input from state machine which > handles that requirement, and then the rest of the code is completely > oblivious to any line continuation requirement. > >> \newline sequences need to be retained, depending on context which >> normally a compiler will know nothing about at this stage. > > The requirement for retaining uncommented line continuations > was something that was needed by Tim in the original situation where > the original program was deployed; it's not coming from the C language. > > I found my program quite easy to modify to accomodate the requirement, > even though it was based on abuse of goto, which supposedly makes > maintenance harder. Note that there are still cases that your program gets wrong.
[toc] | [prev] | [next] | [standalone]
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web