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 19 of 20 — ← Prev page 1 … 17 18 [19] 20 Next page →
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-25 12:21 -0800 |
| Message-ID | <aad9a910-84e2-4d5d-899b-751bdca3d82cn@googlegroups.com> |
| In reply to | #158605 |
Interesting things keep turning up - when I built my compiler back in
the 80's. I didn't implement 'short' - it was a 16-bit pre-ANSI compiler
making the default size of 'int' 16-bits. so 'short' seemed ilrevellenent
and I didn't bother to implement it as it would have done "nothing".
But nowadays I wish I had. Thought about updating it, but so far haven't
done that - what I do instead if I want to generate portable code is put:
#ifdef _MICROC_
#define short
#endif
Which makes 'short' disappear. I thought about adding this to one of my
standard headers files. but seems silly to have a blank definition taking
up space in MCPs string pool... It also concerned me a little that
#define short and defined(short)
would be TRUE when they shouldn't.
But it all this discussion, it occurred to me: What it I could #define it
in the limited preprocessor built into the compiler. It's string pool is
wasted anyway when MCP is being used. and #if[n]defs and defined(..,) in
expressions would be handled by MCP which wouldn't know about it making it
behave as it were truly "built in". So how to get a '#define' statement
past MCP - just put it in another #define
Just for fun I tried it with GCC, and that's where the questions came up.
--- I tried this program ---
#include <stdio.h>
#define _DeFiNe_ #define
_DeFiNe_ short
#undef _DeFiNe_
unsigned short A;
main()
{
unsigned short B;
B = A;
printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
#ifndef short
printf("!defined!\n");
#endif
}
--- My MCP produced this ---
// 11 lines from the include file snipped
#define short
unsigned short A;
main()
{
unsigned short B;
B = A;
printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
printf("!defined!\n");
}
--- GPP (LCC -EP) produced this ---
// 247 lines from the include snipped
#define short
unsigned short A;
main()
{
unsigned short B;
B = A;
printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
printf("!defined!\n");
}
--- Both programs compiled and produced exactly the same output --
2 2 2
!defined!
--
This surprised me. I understand why it does this on my compiler (it's
what I was trying for), because the #define short
is being handled by the limited built in internal pre-processor, and the
#ifdef is handled by MCP which didn't see the definition for "short".
But I don't understand LCC/GCC - clearly it didn't see the
definition of "short" (which I didn't expect), and the #define short
DID make it past GPP - so why didn't it get a compile error?
As it turns out anything in the passed "#" command gets
ignored (ie: #farkle) - shouldn't this cause an error if it
occurs in the source AFTER GPP. Are lines beginning with '#'
handled/removed by a later "translation phase"?
And Borland Turbo-C DOES generate errors:
---
Error a.c 3: # operator not followed by macro argument name
Error a.c 4: Declaration syntax error
Error a.c 11: Undefined symbol 'A' in function main
*** 3 errors in Compile ***
---
What's GCC doing with a '#'line getting past GPP. Does the standard cover
this or is it just something "special" with GCC.
Inquiring minds want to know!
Dave
Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-01-25 14:27 -0800 |
| Message-ID | <87zh0w7ius.fsf@nosuchdomain.example.com> |
| In reply to | #158612 |
Dave Dunfield <dave.dunfield@gmail.com> writes:
> Interesting things keep turning up - when I built my compiler back in
> the 80's. I didn't implement 'short' - it was a 16-bit pre-ANSI compiler
> making the default size of 'int' 16-bits. so 'short' seemed ilrevellenent
> and I didn't bother to implement it as it would have done "nothing".
>
> But nowadays I wish I had. Thought about updating it, but so far haven't
> done that - what I do instead if I want to generate portable code is put:
>
> #ifdef _MICROC_
> #define short
> #endif
>
> Which makes 'short' disappear.
[...]
"short" by itself is a valid type name:
short var;
Your macro would change that to:
var;
which is a syntax error in modern C.
Also, short and int are still distinct types, even if they have the same
size and representation. A conforming C implementation must issue a
diagnostic for this:
int main(void) {
short s;
int i;
if (&s == &i)
;
}
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-25 19:41 -0800 |
| Message-ID | <9d286ef5-bcbc-42af-be13-f57eb819ab95n@googlegroups.com> |
| In reply to | #158614 |
On Monday, January 25, 2021 at 5:27:35 PM UTC-5, Keith Thompson wrote: >"short" by itself is a valid type name: >short var; >Your macro would change that to: >var; >which is a syntax error in modern C. Nice answer which is unrelated to the question I was asking other than that [int] and [short] were mentioned in my explanation of how/why I arrived at the test I described. Anyone want to address the actual question? To simplify it: GCC (at least the LCC variant of it) seems to ignore lines with preprocessor commands (in fact any line beginning with '#' if you go out of your way to get such lines past the preprocessor. At least two other non-standard complaint compilers I tried don't appear to do this. Is this set in the standard, or just something "special" in GCC (or possibly only the LCC variant)? --- Begin unrelated ramble --- BTW, FYI, if anyone really cares. here is a response to your statements. You probably "missed" my statement to the effect: "If I wanted to write truly portable code". It doesn't make sense to use only [short] in a declaration when one of the possible target compilers doesn't know [short]. As a general habit, I tend to use [unsigned] modifiers for any variables which don't need signedness (in my code, that's most of them). This comes in part from the fact that my compiler supported (at least) 11 different processor instruction sets which ranged from very limited (C unfriendly) ones like the 68HC08 or 8051 to more powerful ones like the 80x86, 8096 and my own C-FLEA (A CPU designed to be good for C). For a number of these processors, 16-bit signed arithmetic required library support functions where unsigned may not (or at least be a smaller/faster one). None of them support native 32-bit operations, so all versions of my compiler used 16 bits for [int]. So I essentially never write [short var] I would almost always write more like [unsigned short var;] or [short int var;]. Especially if I wanted the code to be easily portable to my compiler using [#define short] to "make [short] disappear" and relying on the native int/unsigned size to be 16 bits. >Also, short and int are still distinct types, even if they have the same >size and representation. My compiler was written well before the standards became known (or posssibly even existed). I certainly had not been exposed to them when I wrote it. I have NEVER claimed it to be "standards compliant". When I wrote it my main reference was "The C programming language by K&R" 1978 edition. It states: --- Begin quote, lower page 33 --- 3.3 Data Types There are only a few basic data types in C: char - a single byte, capable of holding one character in the local character set. int - an integer, typically reflecting the native size of integer on the host machine. float - single precision floating point. double - double precision floating point. I addition, there are a number of qualifiers which can be applied to the int's: short, long and unsigned. ... The declarations for the qualifiers look like: short int x; long int y; unsigned int z; The word int can be omitted in such situations, and typically is. --- End Quote --- I (perhaps mistakenly) took [int] to be a basic data type and [short] as a qualifier - My compiler always had an extension to the above that the [unsigned] modifier could be applied to the [char] type, but since the default was the same as [short] I (not knowing better at the time) omitted implementing it. I do agree that the above statement would mean that [short x;] would have been a valid declaration, and [x;] would not. As stated above, in writing "portable" code, knowing that [short] could disappear in some cases, I would always include the [int] type name if there was no other modifier. But this really does not address that original question... Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-26 04:46 +0000 |
| Message-ID | <20210125203153.323@kylheku.com> |
| In reply to | #158621 |
On 2021-01-26, Dave Dunfield <dave.dunfield@gmail.com> wrote: > On Monday, January 25, 2021 at 5:27:35 PM UTC-5, Keith Thompson wrote: > >>"short" by itself is a valid type name: >>short var; > >>Your macro would change that to: >>var; >>which is a syntax error in modern C. > > Nice answer which is unrelated to the question I was asking other > than that [int] and [short] were mentioned in my explanation of > how/why I arrived at the test I described. > > Anyone want to address the actual question? To simplify it: > > GCC (at least the LCC variant of it) seems to ignore lines with > preprocessor commands (in fact any line beginning with '#' if you > go out of your way to get such lines past the preprocessor. At > least two other non-standard complaint compilers I tried don't appear > to do this. GCC should process #line directives coming from the preprocessor, so that errors and debug information are reported agains the specified line numbers. (According to ISO C, #line directives are just regular directives; it doesn't say anything about them surviving preprocessing.) However, note that modern GCC doesn't use a separate preprocessor; it's built into the compiler. The GNU version of cpp is not used by GCC. I think that perhaps it still can be, but it's likely subtly broken and unsupported, I'm guessing. > Is this set in the standard, or just something "special" in GCC (or > possibly only the LCC variant)? The standard doesn't say anything about feeding input to a compiler sideways, bypassing some of is processing. That is out of scope. How exactly did you get the input "past the preprocessor?" Under GCC, the documented way to do that is to save a file with the .i suffix. A file with .i will not be preprocessed. GCC internally communicates between the preprocessor and compiler using some sort of token data structure, and not raw text. If you capture the preprocessed output with -E, put it into a .i file and then pass that to GCC again, I wouldn't bet on the result being 100% the same as just compiling the code straight. If you use cpp instead of gcc -E, even less so. There are some tools that depened on this For isntance, there exists something called "ccache". The ccache program runs source through gcc -E, tokenizes it, and produces a hash. It uses this information to pull out a cached .o file. If there is a cache miss, then it compiles the preprocessed output it previously captured as text. Incidentally ccache was originally written by the same developer as rsync (which I believe came up in recent discussion here), namely Andrew Tridgell, the developer of Samba. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-26 06:30 -0800 |
| Message-ID | <43083428-ef02-496d-85eb-08a92fff0405n@googlegroups.com> |
| In reply to | #158622 |
On Monday, January 25, 2021 at 11:46:38 PM UTC-5, Kaz Kylheku wrote:
> GCC should process #line directives coming from the preprocessor,
> so that errors and debug information are reported agains the
> specified line numbers.
That's exactly what mine does.
> (According to ISO C, #line directives are just regular directives;
> it doesn't say anything about them surviving preprocessing.)
Note that in "mine" case the #line directives are GENERATE by MCC and
processed by MCC they don't appear in my example output because I manually
ran MCP and didn't give it the argument to cause it to generate [#line].
> However, note that modern GCC doesn't use a separate preprocessor;
> it's built into the compiler. The GNU version of cpp is not used
> by GCC. I think that perhaps it still can be, but it's likely
> subtly broken and unsupported, I'm guessing.
That's useful to know and it does chance the question a bit.
> How exactly did you get the input "past the preprocessor?"
-- Simplified test code ---
#include <stdio.h>
#define DeFiNe #define
DeFiNe SYMBOL
int main(void)
{
#ifdef SYMBOL
printf("DEFINE!\n");
#else
printf("Not DEFINE!\n");
#endif
}
---
> Under GCC, the documented way to do that is to save a file with the .i
> suffix. A file with .i will not be preprocessed.
I was doing this with LCC, which as you describe GCC doesn't have a separate
GCC/LCP. I didn't know for sure if this was just something LCC had built in,
which is why I was referring to GPP.
To get the preprocessor output, I was using: LCC -EP
'P' to not get the line numbers. This gave a .i file which contained
the preprocessor output:
--- stdio.h snipped ---
#define SYMBOL
int main(void)
{
printf("Not DEFINE!\n");
}
---
Which is what I expected and trying for. MCP produces basically the same
thing. My compiled has a limited internal preprocessor which does know about
#define, so I expected MCC to accept it (which it does).
I did NOT expect GCC(LCC) to accept it. Not knowing I could specify the .i to
LCC, I was actually compiling the .c WITHOUT the -EP argument. I (foolishly
apparently) though this would be the same as .c -> .i -> .exe
In this case (no -EP) it compiled without error, and printed:
---
Not DEFINE!
---
Which indicated to me that the me that the [#define SYMBOL] line is being
accepted and ignored.
AND it does exactly the same thing when the "hidden" #define is changed
to [#farkle] - this suggested to me that GCC after the preprocessor was
ignoring ANY line starting with '#'.
BUT.. if I LCC the .i file instead of the .c without -EP I get:
cpp: x.i:249 Unknown preprocessor control farkle
So clearly LCC .c -EP then LCC .i is NOT the same as LCC .c !
> GCC internally communicates between the preprocessor and compiler
> using some sort of token data structure, and not raw text.
>
> If you capture the preprocessed output with -E, put it into a .i
> file and then pass that to GCC again, I wouldn't bet on the result
> being 100% the same as just compiling the code straight.
Would a good "not bet"!
On Monday, January 25, 2021 at 11:52:14 PM UTC-5, james... wrote:
> "All identifiers that begin with an underscore and either an uppercase
> letter or another underscore are always reserved for any use." (7.1.3p1)
Fair enough, a repeated the test with DeFiNe instead, and got the same
result. I don't think that was a factor, but I don't *know*.
> "If the program declares or defines an identifier in a context in which
> it is reserved (other than as allowed by 7.1.4), or defines a reserved
> identifier as a macro name, the behavior is undefined." (7.1.3p2)
Good to know.
> "The resulting completely macro-replaced preprocessing token sequence is
> not processed as a preprocessing directive even if it resembles one ..."
> (6.10.3.4p3).
>
> Your _DeFiNe_ macro's expansion only resembles a preprocessing
> directive; it doesn't get processed as one.
That's what I expected and why I thought it would cause an error. As noted
above I have determined that it does cause an error with #garbage but not with
#define, a valid preprocessor directive name. I'm guessing that GCC has to
look for #line, and somehow it recognizes other valid directives in this
context but does not act on them.
> Because your macro's expansion doesn't get recognized as a preprocessing
> directive, the following explanation doesn't actually apply in this
> case. However, it would apply if you used #farkle directly.
>
> One of the permitted forms of a pre-processing directive listed in
> 6.10p1 is:
>
> # non-directive
>
> where non-directive is defined as consisting of an arbitrary sequences
> of valid pre-processing tokens (except that the first such token must
> not match any of the standard-defined directives such as if, else, etc.)
> followed by a newline character. Footnote 172 points out that
>
> "Despite the name, a non-directive is a preprocessing directive."
>
> This is a prime example of the fact that when the C standard defines a
> specific meaning for a phrase, then in the context of the C standard,
> that meaning overrides any meaning that you might otherwise expect it to
> have.
>
> The standard says nothing about the behavior of a non-directive. It is
> therefore undefined "by omission of any explicit definition of the
> behavior." (4p6). Since the behavior is undefined, no diagnostic message
> is required. What this basically means is that an implementation is free
> to add its own pre-processing directives to those defined by the
> standard. A high quality implementation should at least warn you about
> directives that it does not itself implement.
Ok, that does mostly answer the question - it's defined in the standard but
the exact behavior in this is up to GCC (I think) - thanks.
> Undefined behavior (for any one of the three reasons given above) allows
> an implementation to handle your code any way it wants to handle it -
> the standard imposes no requirements.
That's good - My own compiler has a fairly complete external preprocessor
(MCP) as well as a more limited internal one ... So it the [#define] version
is actually accepted and works only in the context of the internal one.
[#farkle] is not recognized by either and would cause an error.
I still don't quite know why "LCC .c" accepts the [#farkle] version but
"LCC .c -EP" followed by "LCC .i" doesn't. Apparently some difference in the
internal processing.
On Tuesday, January 26, 2021 at 6:37:49 AM UTC-5, Ben Bacarisse wrote:
> I think a simpler, more modern, program would make it easier to comment.
> People might be distracted from the question you are asking by the
> various UB constructs in this version.
Agreed, I tried to make it simpler in this response. Hopefully that will
make more sense. Has long been an "issue" with me, when doing (and asking
about) something "odd", I almost always provide more in-depth detail than
is actually needed - just the way I tend to think, I would want to know
"how/why you came here" so I do tend to expound on some things :)
> Also, I think you should say, right up front, that you are not treating
> this as a C program. As a C program it has syntax errors, but as source
> to a C macro processor it's fine.
Also agreed. I *thought* it would be obvious in my description of what I
had originally hoped to accomplish, but now I see that this was not a good
assumption.
> OK, so far. The only difference is that GPP (LCC -EP) (which I don't
> know) has put in a few more spacing characters here and there.
Yep, LCC appears to (among other things) put single spaces in where
comments were -- presumably so [A/**/B] doesn't become [AB]. I didn't
in MCP because I know that identifer/**/identifier is generally not
good, and have actually used this "feature" at least once to create symbols
out of multiple #defines - now I know that such a thing would NOT be
portable :)
I originally tested this because thought GPP/LCC -E might be "smart" enough
to recognize a preprocessor directive is I attempted to #define it, so I
used [#def/**/ine] - this resulted in "#def ine" which I didn't want.
> Just to be sure I've got this clear: you ran the original through the
> pre-processor of two different C compilers and then compiled the
> resulting program with that C compiler, thereby passing the source
> through the pre-processor twice? Using gcc's command-line syntax, you
> are doing
>
> gcc -E source.c | gcc -xc -
Not quite - I didn't know I could specify the .i to LCC so I was compiling
the .c with -E to get the .i and then compiling the .c without -E thinking
it would be the same as (old reference to give my idea) GPP then GCC.
> Have I got that right? If so, I am not surprised that both programs
> produce the same result since they are essentially identical, but I am
> surprised that the sizes are 2, so I suspect I don't know what you are
> doing.
Kinda funny because right now I might say "me either"! :)
> If you have access to gcc, what do you get for this command?
I don't easily but I could set up a linux system with GCC often do that
for various small jobs, but my test systems get reinstalled with
something else eventually so I don't have an active one right now.
> Now this makes me think you are treating the original code as C code
> when it isn't. No standard C compiler should accept it without
> complaint (sadly, that is pretty much the most the standard requires --
> a diagnostic).
in the [#define] case LCC *does* accept it without a diagnostic, but in the
[#farkle] case it does not. I guess that my only remaining "concern", I would
prefer that it generate a diagnostic if it sees [#define] that it won't
process - admittedly I had to go out of my way to make that happen, so it's
not at all a big "concern".
>Pre-ANSI compilers are not so constrained. Are you
> talking about a old K&R C compilers here?
MCC and TCC which I also tested are not fully standards conforming so in a
way yes, but the question was actually about what GCC was doing so in another
way no :)
Dave
Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-26 15:46 +0100 |
| Message-ID | <rup9vs$tj0$1@dont-email.me> |
| In reply to | #158621 |
On 26/01/2021 04:41, Dave Dunfield wrote: > GCC (at least the LCC variant of it) seems to ignore lines with LCC is a /completely/ separate project from GCC. Or are you talking about something other than <https://en.wikipedia.org/wiki/LCC_(compiler)> ? (I don't know what the expected behaviour might be for what you are trying to do - it's a little obscure for me.)
[toc] | [prev] | [next] | [standalone]
| From | Dave Dunfield <dave.dunfield@gmail.com> |
|---|---|
| Date | 2021-01-27 03:43 -0800 |
| Message-ID | <557f0f1c-b1b1-4ef4-93cc-0984cc073dd0n@googlegroups.com> |
| In reply to | #158629 |
On Tuesday, January 26, 2021 at 9:46:33 AM UTC-5, David Brown wrote: > LCC is a /completely/ separate project from GCC. Thanks, useful to know. I have to confess that for years now I have had the notion that LCC was a "windows port" of GCC much like DJGCC was a "DOS port". I recall seeing a statement to that effect when I first discovered LCC. Don't see any such reference in the docs and now suspect that it was just a misinformed posting. I've used both and find non-C aspects (like command options/syntax) similar enough that it reinforced the idea. But... most likely the LCC authors new and used GCC and naturally made their creation work like what the were familiar with. > (I don't know what the expected behaviour might be for what you are > trying to do - it's a little obscure for me.) Agreed, and now that I can't trust LCC to do what GCC (which I tend to think of as the "gold standard") would do in these "edge" cases, I may have to set up a Linux VM to have GCC always available. Not that I normally think/care about these things... this "discussion" has lead me to explore aspects of compilers that I otherwise would not have. Dave Search "Dave's Old Computers" see my "personal" at bottom!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-27 13:43 +0100 |
| Message-ID | <rurn4q$4ia$1@dont-email.me> |
| In reply to | #158643 |
On 27/01/2021 12:43, Dave Dunfield wrote: > On Tuesday, January 26, 2021 at 9:46:33 AM UTC-5, David Brown wrote: >> LCC is a /completely/ separate project from GCC. > > Thanks, useful to know. I have to confess that for years now I have had the > notion that LCC was a "windows port" of GCC much like DJGCC was a "DOS port". > The LCC expert around here is Jacob Navia, who writes/maintains the lcc-win port of LCC. (I don't know the extent to which he wrote it, or ported it, but he has certainly maintained it for years and added many new features.) DJGCC was more than just a port of gcc to DOS - it was also a project to port a number of standard *nix utilities to DOS. There have been a few similar concepts for Windows - Cygwin, Mingw/Msys and Mingw-64/Msys2. (Despite the similar names, these are actually separate projects with a certain degree of common ancestry.) If you want gcc and related tools for Windows, look at the Mingw-64 and Msys2 projects. > I recall seeing a statement to that effect when I first discovered LCC. > Don't see any such reference in the docs and now suspect that it was just a > misinformed posting. > > I've used both and find non-C aspects (like command options/syntax) similar > enough that it reinforced the idea. But... most likely the LCC authors new > and used GCC and naturally made their creation work like what the were > familiar with. > When making a new C compiler, it makes sense to copy the non-standard aspects from existing tools if you provide the same functionality. gcc is the nearest there is to a "practical standard" or "reference" C compiler (despite it not being strictly standard C by default), and many other tools copy at least some of its flags and extensions. > >> (I don't know what the expected behaviour might be for what you are >> trying to do - it's a little obscure for me.) > > Agreed, and now that I can't trust LCC to do what GCC (which I tend to think > of as the "gold standard") would do in these "edge" cases, I may have to set > up a Linux VM to have GCC always available. Not that I normally think/care > about these things... this "discussion" has lead me to explore aspects of > compilers that I otherwise would not have. > You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also the "Windows Subsystem for Linux" where Win10 provides a Linux-like environment on Windows. There have been many similar setups for different Windows versions over the years. I am not a Win10 user, and have no experience with it (or its predecessors on other Windows versions) - you may or may not find it useful. But while I recommend Linux for anyone doing programming seriously, you don't /need/ it just to run gcc. (And if you have a Mac rather than Windows, you should already have a compiler called "gcc". It is not gcc, but the completely independent clang/llvm compiler which Apple confusingly renames.) > Dave > Search "Dave's Old Computers" see my "personal" at bottom! >
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2021-01-27 17:51 +0300 |
| Message-ID | <20210127175154.6c87c942dbfdd1ae6fc555ea@g{oogle}mail.com> |
| In reply to | #158644 |
David Brown:
> DJGCC was more than just a port of gcc to DOS - it was
> also a project to port a number of standard *nix utilities
> to DOS.
Why the past tense? DJPP is alive:
http://www.delorie.com/djgpp/
> There have been a few similar concepts for Windows -
> Cygwin, Mingw/Msys and Mingw-64/Msys2. (Despite the
> similar names, these are actually separate projects with a
> certain degree of common ancestry.
All these are also alive.
> If you want gcc and related tools for Windows, look at the
> Mingw-64 and Msys2 projects.
Why not the original MinGW, which remains true to its name:
Minimalist GNU for Windows. MinGW64 not minimalist.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-27 11:02 -0500 |
| Message-ID | <rus2qq$qfi$1@dont-email.me> |
| In reply to | #158646 |
On 1/27/21 9:51 AM, Anton Shepelev wrote: > David Brown: ... >> If you want gcc and related tools for Windows, look at the >> Mingw-64 and Msys2 projects. > > Why not the original MinGW, which remains true to its name: > Minimalist GNU for Windows. MinGW64 not minimalist. I'd imagine he's recommending it because he doesn't want something that's minimalist.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-27 17:03 +0100 |
| Message-ID | <rus2rq$s7g$1@dont-email.me> |
| In reply to | #158646 |
On 27/01/2021 15:51, Anton Shepelev wrote: > David Brown: > >> DJGCC was more than just a port of gcc to DOS - it was >> also a project to port a number of standard *nix utilities >> to DOS. > > Why the past tense? DJPP is alive: > > http://www.delorie.com/djgpp/ I only meant that it was created in the past, not that it has disappeared. (DOS still exists, at least in the FreeDOS implementation.) > >> There have been a few similar concepts for Windows - >> Cygwin, Mingw/Msys and Mingw-64/Msys2. (Despite the >> similar names, these are actually separate projects with a >> certain degree of common ancestry. > > All these are also alive. They are indeed. Again, I did not intend to imply that they were not (it would have been strange for me to recommend a dead project). > >> If you want gcc and related tools for Windows, look at the >> Mingw-64 and Msys2 projects. > > Why not the original MinGW, which remains true to its name: > Minimalist GNU for Windows. MinGW64 not minimalist. > "Minimalist" is not necessarily a good thing. In most circumstances, it is just as bad as being overly bloated. Mingw gives you more limited tools and in particular, a more limited C library (being based on MS's external DLL with limited C99 support). Mingw64 gives you a more efficient library, as well as 64-bit support. (This is based on my understanding from the last time I looked at these projects, which was a good while ago. I am happy to be corrected if I've got something wrong here.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-01-27 07:21 -0800 |
| Message-ID | <ad25e4fa-cc61-4925-98fd-508cffa3fa2en@googlegroups.com> |
| In reply to | #158644 |
On Wednesday, 27 January 2021 at 12:43:20 UTC, David Brown wrote: > > But while I recommend Linux for anyone doing programming seriously, you > don't /need/ it just to run gcc. > Embedded programming is usually done with tools hosted on a desktop Linux system. However for applications programming, you don't normally have that choice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-27 17:09 +0100 |
| Message-ID | <rus37s$vnh$1@dont-email.me> |
| In reply to | #158647 |
On 27/01/2021 16:21, Malcolm McLean wrote: > On Wednesday, 27 January 2021 at 12:43:20 UTC, David Brown wrote: >> >> But while I recommend Linux for anyone doing programming seriously, you >> don't /need/ it just to run gcc. >> > Embedded programming is usually done with tools hosted on a desktop > Linux system. No, it is not. Most embedded programmers use Windows. I recommend Linux as a better platform for that task, but I can hardly expect "most developers" to follow /my/ recommendations! And of course people have other reasons for running Windows (including "that's what the company says I must use") even if they agree Linux would be better for the programming part. > > However for applications programming, you don't normally have that choice. > That depends entirely on the type of applications programming you are doing. For example, I don't do much desktop application programming for Windows or Linux, and for the programs I do make, they are generally in Python (for desktop applications programming, C is almost always a poor choice of language). The end users are typically running Windows - but I use Linux for the development. My Windows machine gets involved for some final testing and for making the "single exe file" installers. But I agree that a lot of developers (of all kinds) have little choice in the system they use.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-27 17:04 +0000 |
| Message-ID | <rus6f0$q9s$1@dont-email.me> |
| In reply to | #158644 |
On 2021-01-27, David Brown <david.brown@hesbynett.no> wrote: > You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also > the "Windows Subsystem for Linux" where Win10 provides a Linux-like > environment on Windows. There have been many similar setups for > different Windows versions over the years. I am not a Win10 user, and > have no experience with it (or its predecessors on other Windows > versions) - you may or may not find it useful. If you need to port C/POSIX programs to Windows and then redistribute them to Windows users, I recommend something called Cygnal, which I made myself: http://www.kylheku.com/cygnal.html You compile your program in the Cygwin environment, in the normal, convenient way, using Cygwin's native toolchain. Then you just package it with the cygwin1.dll from the Cygnal project. Background: When it was announced in the Cygwin mailing list that Cygwin is going to be LGPL, sometime in 2016, I immediately saw the opportunity and started this project. LGPL means you can use Cygwin as redistributable run-time library for programs without requiring them to be GPL-compatible. They could be full-blown proprietary programs. The licensing problem being solved, the rest are just technical challenges: Cygwin programs being saddled with conventions like /cygdrive/c/... instead of c:/, PATH that is colon separated instead of semicolon, and whatnot. This could be addressed with a permanent fork of Cygwin that makes a few necessary changes here and there, and that rebases to Cygwin from time to time. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-28 10:41 +0100 |
| Message-ID | <ruu0s2$prq$1@dont-email.me> |
| In reply to | #158664 |
On 27/01/2021 18:04, Kaz Kylheku wrote: > On 2021-01-27, David Brown <david.brown@hesbynett.no> wrote: >> You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also >> the "Windows Subsystem for Linux" where Win10 provides a Linux-like >> environment on Windows. There have been many similar setups for >> different Windows versions over the years. I am not a Win10 user, and >> have no experience with it (or its predecessors on other Windows >> versions) - you may or may not find it useful. > > If you need to port C/POSIX programs to Windows and then redistribute > them to Windows users, I recommend something called Cygnal, which > I made myself: > > http://www.kylheku.com/cygnal.html > > You compile your program in the Cygwin environment, in the > normal, convenient way, using Cygwin's native toolchain. > > Then you just package it with the cygwin1.dll from the Cygnal project. > That's new to me - thanks for the pointer. My experience with cygwin is that it gives more accurate POSIX support (such as a filesystem emulation that supports different kinds of links, full fork(), etc.) but that this comes at the cost of being somewhat inefficient (inevitable, as the translation layer has to do more work), being a bit more "alien" on Windows, and leading to dll hell. So in the past I have used cygwin where necessary, but /only/ when necessary. (It used to be necessary for gcc C and C++ cross-compilers hosted on Windows, for example - but the "fork then exec" calls were helpfully replaced by vfork or posix_spawn, giving far more efficient Windows porting.) But it sounds like your system here will at least avoid the third issue with cygwin - the dll hell you face when you have more than one cygwin-based program running at the same time. > > Background: > > When it was announced in the Cygwin mailing list that Cygwin is > going to be LGPL, sometime in 2016, I immediately saw the > opportunity and started this project. > > LGPL means you can use Cygwin as redistributable run-time library for > programs without requiring them to be GPL-compatible. > > They could be full-blown proprietary programs. > > The licensing problem being solved, the rest are just technical > challenges: Cygwin programs being saddled with conventions > like /cygdrive/c/... instead of c:/, PATH that is colon separated > instead of semicolon, and whatnot. > > This could be addressed with a permanent fork of Cygwin that makes a few > necessary changes here and there, and that rebases to Cygwin from time > to time. > I don't remember the details, but I believe either one or both of the mingw and mingw64 projects were based on Cygwin forks in precisely this way. I must admit that it's been a while since I have dealt with the details of these things. There was a time, long ago, when I had to build my own gcc cross-compilers on Windows. These days, gcc is a mainstream compiler for many embedded targets and is easily available pre-built for different targets, so I don't bother doing it myself (while I use Linux for most of my development, it is often important that the same tools can be used on Windows).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-28 18:25 +0000 |
| Message-ID | <20210128100403.851@kylheku.com> |
| In reply to | #158677 |
On 2021-01-28, David Brown <david.brown@hesbynett.no> wrote: > On 27/01/2021 18:04, Kaz Kylheku wrote: >> On 2021-01-27, David Brown <david.brown@hesbynett.no> wrote: >>> You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also >>> the "Windows Subsystem for Linux" where Win10 provides a Linux-like >>> environment on Windows. There have been many similar setups for >>> different Windows versions over the years. I am not a Win10 user, and >>> have no experience with it (or its predecessors on other Windows >>> versions) - you may or may not find it useful. >> >> If you need to port C/POSIX programs to Windows and then redistribute >> them to Windows users, I recommend something called Cygnal, which >> I made myself: >> >> http://www.kylheku.com/cygnal.html >> >> You compile your program in the Cygwin environment, in the >> normal, convenient way, using Cygwin's native toolchain. >> >> Then you just package it with the cygwin1.dll from the Cygnal project. >> > > That's new to me - thanks for the pointer. > > My experience with cygwin is that it gives more accurate POSIX support > (such as a filesystem emulation that supports different kinds of links, > full fork(), etc.) but that this comes at the cost of being somewhat > inefficient (inevitable, as the translation layer has to do more work), > being a bit more "alien" on Windows, and leading to dll hell. This is why the Cygnal project is useful; you get that accurate POSIX support, which is great for porting POSIX programs to windows. At the same time, those programs are no longer saddled with some of the most ugly user-visible conventions of Cygwin that are unfamiliar to the users of Windows applications. Cygwin has inefficiencies, but you can avoid them. For instance, you don't have to use fork. Cygwin has a spawn implementation. Use spawnvp if you just want to run an executable, and that avoids the fork/exec emulation. You have access to Win32 calls; you can make a GUI application if you want, that doesn't open a console window when it starts. So, basically, you can use Cygnal as an alternative to the Microsoft Visual C redistributable run-time. E.g. you can use its malloc and printf and whatnot, in an otherwise Windows program which avoids the bits you don't want, like fork. A really nice thing is that termios works, and so do ANSI/VT100 escape sequences: there is an interpreter for them in the Cygwin DLL, which translates to the Console API. POSIX console programs that use termios and escape sequences will port to a cmd.exe console! In Cygnal, I put in some bugfixes in the ANSI handling code to improve this. > So in the past I have used cygwin where necessary, but /only/ when > necessary. (It used to be necessary for gcc C and C++ cross-compilers > hosted on Windows, for example - but the "fork then exec" calls were > helpfully replaced by vfork or posix_spawn, giving far more efficient > Windows porting.) Long before posix_spawn, there was Microsoft spawn, and Cygwin has its own, compatible implementation of it. The functions just don't have the original leading underscore in the name. >> This could be addressed with a permanent fork of Cygwin that makes a few >> necessary changes here and there, and that rebases to Cygwin from time >> to time. >> > > I don't remember the details, but I believe either one or both of the > mingw and mingw64 projects were based on Cygwin forks in precisely this way. Not really, though. The original MinGW's *environment* (the utilities and such) is a fork of some early version of Cygwin, and is called MSYS. When you build MinGW programs, you're running MSYS tools, but you're not building a MSYS application. The original MinGW is obsolete by the way, in the following way (besides the obvious). If you need to use it for any reason (someone hands you a program designed to be built with MinGW); you can install the MinGW cross-compiler as a Cygwin package! Then you can maintain that program in a more up-to-date environment, with more tools. The new Mingw64 is a "mega-project" with its own libraries; I don't think it's a fork of Cygwin at all or if it is, it's a heavy one. My Cygnal idea is smarter; it's less than 20 patches to Cygwin, that's it, and it affects only the cygwin1.dll, in a way that is drop-in compatible. Cygnal is just a modified DLL, not a whole environment. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-28 10:44 +0100 |
| Message-ID | <ruu11t$qpp$1@dont-email.me> |
| In reply to | #158664 |
On 27/01/2021 18:04, Kaz Kylheku wrote: > On 2021-01-27, David Brown <david.brown@hesbynett.no> wrote: >> You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also >> the "Windows Subsystem for Linux" where Win10 provides a Linux-like >> environment on Windows. There have been many similar setups for >> different Windows versions over the years. I am not a Win10 user, and >> have no experience with it (or its predecessors on other Windows >> versions) - you may or may not find it useful. > > If you need to port C/POSIX programs to Windows and then redistribute > them to Windows users, I recommend something called Cygnal, which > I made myself: > > http://www.kylheku.com/cygnal.html > That link doesn't work - it tells me the document is missing, and threatens to ban my IP if I get the address wrong too many times. (I can understand doing that as a security measure, but it makes it hard to use trial-and-error to find the right address.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2021-01-28 21:33 +0000 |
| Message-ID | <20210128133156.218@kylheku.com> |
| In reply to | #158678 |
On 2021-01-28, David Brown <david.brown@hesbynett.no> wrote:
> On 27/01/2021 18:04, Kaz Kylheku wrote:
>> On 2021-01-27, David Brown <david.brown@hesbynett.no> wrote:
>>> You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also
>>> the "Windows Subsystem for Linux" where Win10 provides a Linux-like
>>> environment on Windows. There have been many similar setups for
>>> different Windows versions over the years. I am not a Win10 user, and
>>> have no experience with it (or its predecessors on other Windows
>>> versions) - you may or may not find it useful.
>>
>> If you need to port C/POSIX programs to Windows and then redistribute
>> them to Windows users, I recommend something called Cygnal, which
>> I made myself:
>>
>> http://www.kylheku.com/cygnal.html
>>
>
> That link doesn't work - it tells me the document is missing, and
My apologies; the correct domain name is actually:
http://www.kylheku.com/cygnal/
You may omit the trailing slash. This internaly redirects to:
http://www.kylheku.com/cygnal/index.html
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-01-29 10:39 +0100 |
| Message-ID | <rv0l3l$7bs$1@dont-email.me> |
| In reply to | #158711 |
On 28/01/2021 22:33, Kaz Kylheku wrote: > On 2021-01-28, David Brown <david.brown@hesbynett.no> wrote: >> On 27/01/2021 18:04, Kaz Kylheku wrote: >>> On 2021-01-27, David Brown <david.brown@hesbynett.no> wrote: >>>> You can get gcc for Windows. I recommend Mingw-64/Msys2. There is also >>>> the "Windows Subsystem for Linux" where Win10 provides a Linux-like >>>> environment on Windows. There have been many similar setups for >>>> different Windows versions over the years. I am not a Win10 user, and >>>> have no experience with it (or its predecessors on other Windows >>>> versions) - you may or may not find it useful. >>> >>> If you need to port C/POSIX programs to Windows and then redistribute >>> them to Windows users, I recommend something called Cygnal, which >>> I made myself: >>> >>> http://www.kylheku.com/cygnal.html >>> >> >> That link doesn't work - it tells me the document is missing, and > > My apologies; the correct domain name is actually: > > http://www.kylheku.com/cygnal/ > > You may omit the trailing slash. This internaly redirects to: > > http://www.kylheku.com/cygnal/index.html > Thanks - the link is fine now. I'll read through the information there.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-01-25 23:52 -0500 |
| Message-ID | <ruo75j$uu8$1@dont-email.me> |
| In reply to | #158612 |
On 1/25/21 3:21 PM, Dave Dunfield wrote:
...
> Just for fun I tried it with GCC, and that's where the questions came up.
>
> --- I tried this program ---
> #include <stdio.h>
>
> #define _DeFiNe_ #define
"All identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use." (7.1.3p1)
"If the program declares or defines an identifier in a context in which
it is reserved (other than as allowed by 7.1.4), or defines a reserved
identifier as a macro name, the behavior is undefined." (7.1.3p2)
However, there's still a problem even if you replace _DeFiNe_ with
something that is not a reserved identifier.
> _DeFiNe_ short
The standard says this about macro replacement:
"The resulting completely macro-replaced preprocessing token sequence is
not processed as a preprocessing directive even if it resembles one ..."
(6.10.3.4p3).
Your _DeFiNe_ macro's expansion only resembles a preprocessing
directive; it doesn't get processed as one.
> #undef _DeFiNe_
>
> unsigned short A;
> main()
> {
> unsigned short B;
> B = A;
> printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
> #ifndef short
> printf("!defined!\n");
> #endif
> }
>
> --- My MCP produced this ---
> // 11 lines from the include file snipped
> #define short
>
> unsigned short A;
> main()
> {
> unsigned short B;
> B = A;
> printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
> printf("!defined!\n");
> }
>
> --- GPP (LCC -EP) produced this ---
> // 247 lines from the include snipped
>
> #define short
>
>
> unsigned short A;
> main()
> {
> unsigned short B;
> B = A;
> printf("%u %u %u\n", sizeof(A), sizeof(B), sizeof(unsigned short));
>
> printf("!defined!\n");
>
> }
>
> --- Both programs compiled and produced exactly the same output --
> 2 2 2
> !defined!
> --
>
> This surprised me. I understand why it does this on my compiler (it's
> what I was trying for), because the #define short
> is being handled by the limited built in internal pre-processor, and the
> #ifdef is handled by MCP which didn't see the definition for "short".
>
> But I don't understand LCC/GCC - clearly it didn't see the
> definition of "short" (which I didn't expect), and the #define short
> DID make it past GPP - so why didn't it get a compile error?
>
> As it turns out anything in the passed "#" command gets
> ignored (ie: #farkle) - shouldn't this cause an error if it
> occurs in the source AFTER GPP. Are lines beginning with '#'
> handled/removed by a later "translation phase"?
Because your macro's expansion doesn't get recognized as a preprocessing
directive, the following explanation doesn't actually apply in this
case. However, it would apply if you used #farkle directly.
One of the permitted forms of a pre-processing directive listed in
6.10p1 is:
# non-directive
where non-directive is defined as consisting of an arbitrary sequences
of valid pre-processing tokens (except that the first such token must
not match any of the standard-defined directives such as if, else, etc.)
followed by a newline character. Footnote 172 points out that
"Despite the name, a non-directive is a preprocessing directive."
This is a prime example of the fact that when the C standard defines a
specific meaning for a phrase, then in the context of the C standard,
that meaning overrides any meaning that you might otherwise expect it to
have.
The standard says nothing about the behavior of a non-directive. It is
therefore undefined "by omission of any explicit definition of the
behavior." (4p6). Since the behavior is undefined, no diagnostic message
is required. What this basically means is that an implementation is free
to add its own pre-processing directives to those defined by the
standard. A high quality implementation should at least warn you about
directives that it does not itself implement.
>
> And Borland Turbo-C DOES generate errors:
> ---
> Error a.c 3: # operator not followed by macro argument name
> Error a.c 4: Declaration syntax error
> Error a.c 11: Undefined symbol 'A' in function main
> *** 3 errors in Compile ***
> ---
>
> What's GCC doing with a '#'line getting past GPP. Does the standard cover
> this or is it just something "special" with GCC.
Undefined behavior (for any one of the three reasons given above) allows
an implementation to handle your code any way it wants to handle it -
the standard imposes no requirements.
[toc] | [prev] | [next] | [standalone]
Page 19 of 20 — ← Prev page 1 … 17 18 [19] 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web