Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146566 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-10-04 13:00 -0400 |
| Last post | 2019-10-15 11:19 -0700 |
| Articles | 20 on this page of 483 — 31 participants |
Back to article view | Back to comp.lang.c
Sort char array DFS <nospam@dfs.com> - 2019-10-04 13:00 -0400
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-04 17:06 +0000
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-04 21:55 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 19:24 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-05 13:08 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-04 21:06 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 01:21 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 01:23 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 20:49 -0400
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-04 20:45 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 13:14 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 14:35 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:12 +0100
Re: Sort char array luser droog <luser.droog@gmail.com> - 2019-10-05 09:26 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:51 +0100
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 09:00 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 19:29 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 18:13 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 21:09 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-05 13:22 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 21:45 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 00:17 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:32 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 15:54 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 08:07 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 17:39 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 12:52 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-06 21:26 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-07 01:37 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 01:10 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 17:32 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 02:02 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 09:41 +0200
Re: Sort char array mark.bluemel@gmail.com - 2019-10-07 00:39 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 10:59 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 13:19 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 12:42 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 13:57 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 15:01 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 17:42 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:20 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 19:33 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 18:22 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 02:27 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 17:02 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 08:53 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 12:28 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-08 11:47 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 02:02 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 00:50 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 03:03 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 01:51 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 10:31 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 11:57 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 14:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 14:41 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 16:17 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 18:09 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 17:38 +0000
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 01:37 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 11:05 -0700
Re: Sort char array Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-10 14:33 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 12:20 -0700
Re: Sort char array Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-10 16:00 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 23:43 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 14:12 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:04 +0300
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 22:17 +0000
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 15:24 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 12:57 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 00:53 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 00:50 +0100
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-12 03:42 +0800
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 22:16 +0100
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-14 16:08 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 19:20 +0100
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 07:40 +1300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 20:24 +0100
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 08:33 +1300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 20:52 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-14 16:18 -0700
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 23:42 +0000
Re: Sort char array Ian Collins <ian-news@hotmail.com> - 2019-10-15 16:40 +1300
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 05:10 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-14 12:00 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 12:33 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 14:22 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 15:35 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 16:15 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 20:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 20:42 +0100
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 10:40 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 20:31 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-09 12:02 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 22:21 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-09 21:31 +0000
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-09 15:35 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 00:32 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-10 10:40 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-10 10:42 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 15:58 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:37 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 19:56 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 00:56 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 11:04 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 13:33 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 10:57 +0100
Re: Sort char array mark.bluemel@gmail.com - 2019-10-18 05:56 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 06:10 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 15:24 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-18 09:41 -0400
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 07:20 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 15:29 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-19 06:04 -0700
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-18 13:36 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 15:17 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 16:44 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 08:49 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 17:56 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-18 09:03 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 19:14 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-18 23:06 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 00:49 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 01:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 11:16 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-19 03:56 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 13:29 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-19 08:44 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 14:05 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-19 07:35 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 18:01 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 20:14 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 23:12 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-20 00:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 10:24 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 14:39 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 06:11 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:36 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 14:36 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 16:47 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 19:16 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 21:37 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-20 09:54 -0400
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-19 13:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-19 13:40 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-19 13:13 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-19 13:57 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:04 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 06:21 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:40 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 07:29 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 16:49 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 15:10 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 21:26 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 19:56 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 23:06 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 23:08 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-21 00:25 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:33 +0000
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:57 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 00:14 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 23:48 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 11:20 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-21 12:36 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 22:48 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-21 01:20 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-22 18:00 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-22 10:51 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-22 19:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 21:27 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-20 14:46 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-20 23:34 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-18 16:35 +0100
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 17:01 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-18 19:15 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 19:01 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 13:14 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-20 11:25 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-20 15:07 +0200
Re: Sort char array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-18 16:58 +0000
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:06 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 19:55 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-15 03:24 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 12:39 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 04:03 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-15 14:30 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-18 05:59 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-19 00:31 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 04:46 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-14 12:06 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 10:30 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 02:26 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 12:41 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:34 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:06 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 11:55 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 13:23 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-13 13:30 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-14 16:13 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 02:00 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-11 10:33 +0200
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-10 01:01 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 11:19 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 12:18 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 16:15 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 15:32 +0000
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-10 21:03 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-10 20:36 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 17:16 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-11 03:25 +0100
Re: Sort char array David Kleinecke <dkleinecke@gmail.com> - 2019-10-10 22:36 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 12:10 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-12 00:26 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 00:44 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:18 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 12:42 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 15:00 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 15:29 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 19:13 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 19:04 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 20:13 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 01:36 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 22:52 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-12 23:06 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 10:25 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 16:42 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 18:03 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-13 19:50 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-14 12:27 -0700
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-15 10:26 +0200
Re: Sort char array Ike Naar <ike@sdf.lonestar.org> - 2019-10-14 21:02 +0000
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 01:39 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 01:51 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 12:16 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 10:45 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 13:16 +0300
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-14 03:34 -0700
Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 03:54 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 13:36 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-10-14 09:49 -0400
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 07:15 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 14:55 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) mark.bluemel@gmail.com - 2019-10-14 08:10 -0700
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) scott@slp53.sl.home (Scott Lurndal) - 2019-10-14 16:21 +0000
Re: Lack of language I/O support (was Re: Sort char array, many posts ago) Siri Cruise <chine.bleu@yahoo.com> - 2019-10-14 09:25 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 14:57 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:24 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 16:40 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-14 16:17 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-14 23:45 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 00:03 +0100
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 05:30 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 16:05 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 07:55 -0700
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 10:58 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 14:36 +0100
Re: Sort char array Thiago Adams <thiago.adams@gmail.com> - 2019-10-14 11:03 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-14 19:28 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:17 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-15 00:26 +0300
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 11:55 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 04:24 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 07:19 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-16 18:17 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 05:43 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-17 18:01 +0300
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-19 00:39 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-19 06:00 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-11-08 18:38 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 22:03 -0800
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 18:49 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 00:25 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 23:44 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-12 13:45 +0100
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-13 19:05 -0400
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-12 13:16 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-13 00:12 +0100
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-13 14:18 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-13 23:10 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 23:52 -0400
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-15 11:48 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 18:14 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-15 20:31 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 20:11 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-15 20:34 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-15 22:05 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 13:27 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-16 10:11 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-16 12:42 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-16 04:02 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 05:51 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-18 10:18 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-18 12:05 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 05:42 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-23 05:02 -0700
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-14 15:32 +0000
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:57 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-14 10:13 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-14 23:59 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 06:08 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-10 01:20 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-10 20:15 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-11 04:00 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-11 07:53 -0400
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-11 11:20 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:16 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-11 14:43 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-11 11:51 -0700
Re: Sort char array raltbos@xs4all.nl (Richard Bos) - 2019-10-12 07:46 +0000
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 09:49 -0400
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 12:29 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 12:20 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-12 13:38 +0200
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 12:17 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 20:20 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-12 20:39 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:32 +0300
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 07:38 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-14 08:13 -0700
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-15 07:45 -0400
Re: Sort char array chad <cdalten@gmail.com> - 2019-10-15 05:12 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-15 13:04 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-17 10:14 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-15 12:24 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-16 04:12 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-16 14:21 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-16 19:12 -0400
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-16 16:33 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-16 19:48 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-18 06:57 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:22 +0300
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:02 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 17:01 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 12:24 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 12:18 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 14:11 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 15:22 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 17:17 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-07 20:52 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 00:45 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-07 15:57 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 02:32 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 10:06 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:21 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:34 +0300
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 11:23 +0200
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 09:59 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 11:39 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 14:05 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 15:06 +0100
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 14:38 +0000
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:34 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 16:38 +0000
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-08 07:55 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 18:31 +0300
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-08 16:39 +0000
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 19:57 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 18:09 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 22:16 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 23:58 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 22:19 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:39 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:12 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 09:48 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 19:49 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 17:29 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-08 17:56 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-08 22:25 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 00:02 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 13:41 +0200
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 14:03 +0100
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-09 15:53 +0200
Re: Sort char array scott@slp53.sl.home (Scott Lurndal) - 2019-10-09 14:39 +0000
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 15:58 +0100
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-10 22:43 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-11 01:45 +0300
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-11 01:00 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-12 12:01 -0400
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-12 20:35 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-13 21:17 +0300
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-14 07:45 -0400
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-14 14:53 +0300
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-09 02:02 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-09 10:36 +0100
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 09:05 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 08:59 -0700
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-07 09:00 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:02 +0100
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-06 19:57 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 06:38 -0700
Re: Sort char array Bart <bc@freeuk.com> - 2019-10-05 17:14 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 13:06 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:24 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 05:13 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:04 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 07:13 -0700
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-06 18:23 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:41 +0300
Re: Sort char array Keith Thompson <kst-u@mib.org> - 2019-10-06 12:46 -0700
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-07 04:00 +0800
Re: Sort char array David Brown <david.brown@hesbynett.no> - 2019-10-07 09:46 +0200
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 22:49 -0400
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 12:24 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-08 09:28 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 23:49 +0300
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-08 18:18 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:34 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 14:36 +0300
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 15:34 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 05:54 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 16:01 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 06:31 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:30 +0300
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 10:14 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 06:26 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 02:46 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 00:19 -0400
Re: Sort char array Barry Schwarz <schwarzb@dqel.com> - 2019-10-04 22:26 -0700
Re: OT Re: Sort char array Barry Schwarz <schwarzb@delq.com> - 2019-10-05 06:33 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-05 16:46 +0200
Re: Sort char array "Oliver S." <Follow.Me@gmx.net> - 2019-10-05 16:54 +0200
Re: Sort char array "Oliver S." <Follow.Me@gmx.net> - 2019-10-05 17:14 +0200
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-05 11:34 -0400
Re: Sort char array Mateusz Viste <mateusz@wont.tell> - 2019-10-05 15:43 +0000
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-05 17:29 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:14 -0700
Re: Sort char array Mateusz Viste <mateusz@wont.tell> - 2019-10-06 09:58 +0000
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 03:11 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 03:35 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:57 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 16:12 +0100
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:06 -0700
Re: Sort char array Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-10-07 07:28 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 17:51 +0100
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-08 18:31 +0800
Re: Sort char array already5chosen@yahoo.com - 2019-10-08 03:59 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:14 -0700
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-08 14:34 +0300
Re: Sort char array Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-08 22:41 +0800
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 02:03 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 13:25 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 15:45 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 14:59 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:11 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 15:15 +0200
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:20 +0300
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 15:35 +0200
Re: Sort char array Richard Damon <Richard@Damon-Family.org> - 2019-10-06 13:04 -0400
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 08:44 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 18:01 +0200
Re: Sort char array already5chosen@yahoo.com - 2019-10-06 09:42 -0700
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-06 19:21 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 21:51 +0100
Re: Sort char array Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-07 04:41 +0200
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 16:45 +0100
Re: Sort char array Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-10-07 19:11 +0300
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 21:10 +0100
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-08 00:43 +0300
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-07 15:51 -0400
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 01:48 -0700
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-07 00:42 -0400
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-07 16:05 -0700
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 20:06 -0400
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-08 08:34 -0700
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:09 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 20:12 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:44 +0100
Re: Sort char array DFS <nospam@dfs.com> - 2019-10-07 22:02 -0400
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 03:24 +0100
Re: Sort char array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-09 01:42 +0100
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-09 11:14 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-10 00:52 +0300
Re: Sort char array John Bode <jfbode1029@gmail.com> - 2019-10-08 08:20 -0700
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 00:20 +0300
Re: Sort char array James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-08 18:48 -0400
Re: Sort char array Anton Shepelev <anton.txt@gmail.com> - 2019-10-09 02:07 +0300
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:29 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 09:43 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-09 09:37 -0700
Re: Sort char array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 02:22 -0700
Re: Sort char array already5chosen@yahoo.com - 2019-10-15 11:19 -0700
Page 3 of 25 — ← Prev page 1 2 [3] 4 5 … 25 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-07 17:20 +0100 |
| Message-ID | <87ftk4le7x.fsf@bsb.me.uk> |
| In reply to | #146689 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Bart:
>
>>BTW one of the programs uses a table of function addresses
>>like this:
>>
>>static void * msysc__fnaddresses[]= {
>> &start,
>> &qq_getinputoptions,
>> .....
>> &q_libs_getintlib,
>> 0};
>>
>>(Some 1400 entries.) What should the array element type be
>>if not void* ?
>
> If all of them are pointers to funcions, why not make it:
>
> void ( msysc__fnaddresses[] )( void )
I think you mean
void ( *msysc__fnaddresses[] )( void )
though I'd probably typedef a function type:
typedef void system_function(void);
...
static system_function *msysc__fnaddresses[] = {
...
};
(void system_function(void) may not be the right type. I'm just giving
an example.)
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-07 19:33 +0300 |
| Message-ID | <20191007193346.2a7b46a597fe362c479f0873@g{oogle}mail.com> |
| In reply to | #146699 |
Ben Bacarisse to Anton Shepelev:
>>If all of them are pointers to funcions, why not make it:
>>
>> void ( msysc__fnaddresses[] )( void )
>
>I think you mean
>
>void ( *msysc__fnaddresses[] )( void )
Yes, it was the first time that I have tried to delclare an
array of function pointers without a preceding #typedef for
the fucnction pointer itself.
>though I'd probably typedef a function type:
>
> typedef void system_function(void);
> ...
> static system_function *msysc__fnaddresses[] = {
> ...
> };
I too, but my intent was to make it fit into Bart's style.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-07 18:22 +0100 |
| Message-ID | <rvKmF.2513170$dw4.1447457@fx12.am4> |
| In reply to | #146689 |
On 07/10/2019 15:42, Anton Shepelev wrote:
> Bart:
>
>> BTW one of the programs uses a table of function addresses
>> like this:
>>
>> static void * msysc__fnaddresses[]= {
>> &start,
>> &qq_getinputoptions,
>> .....
>> &q_libs_getintlib,
>> 0};
>>
>> (Some 1400 entries.) What should the array element type be
>> if not void* ?
>
> If all of them are pointers to funcions, why not make it:
>
> void ( msysc__fnaddresses[] )( void )
Using void* as a generic pointer type for both kinds of pointers is
preferred in the original language, where it allows arbitrary
conversions to and from either kind of pointer.
With void(*)(void), it would need casts on all element types.
I prefer not to compromise the design of the original language to suit C.
With enough work, this is solvable. But I've spent several weeks getting
to the point where a non-pedantic compile with gcc works without
warnings on either OS and on either 32-bit or 64-bit targets.
(This latter is important because the original language is 64-bit
everything, and since it was targeted at 64-bit Windows, made various
assumptions which caused lots of mismatches in the C32 output. I hadn't
expected to have to target a 32-bit machine again, but it turned out the
64-bit RPi4 mainly comes with 32-bit OSes and system software still.)
Anyway, I'm not ready for additional (and unnecessary for the purpose of
getting working programs) effort to get past the -pedantic warnings, and
some may yet be insurmountable.
(For example, I use unsigned chars, and I define C library functions in
my language as using unsigned, but when code assuming that is written
out as C, the compiler will see the original function uses signed char,
and complain.
If I try and define my own version of the library function in the
generated C, and eschew all standard function like stdio.h, then gcc
will complain that my declarations don't match what they should be! I
can't win.)
>> If there is a way to legally convert such pointers, why
>> don't compilers do that? If it needs an explicit cast, then
>> (void*) should suffice as indication that the programmer
>> intends that to happen.
>
> Conversion between pointers to functions and data is absurd
> from the human viewpoint, for data and funcions belong to
> different conceptual domains. You cannot read from or write
> to a function pointer. You cannot invoke a data pointer.
1) It is also absurd to convert pointers to/from integers, but C allows
that for function pointers! It's conversion to/from object pointers that
it doesn't like.
2) You can't read or write via a void pointer either.
3) Nor with a label pointer (a gcc extension). Yet gcc allows a
conversion to/from void*. -pedantic will still generate a warning, but
only that it is non-standard. It doesn't say it is Verboten.
If you think of any pointer as an address, then these distinctions cease
to matter, especially when represented as a void*. C is famous for being
'close to the metal' after all.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-08 02:27 +0300 |
| Message-ID | <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> |
| In reply to | #146702 |
Bart:
> Using void* as a generic pointer type for both kinds of
> pointers is preferred in the original language, where it
> allows arbitrary conversions to and from either kind of
> pointer.
If it is a hardware-abstract, high-level language, then why
do you need such conversion? Surely you do not write to, or
perform address arithmetics on function pointers, nor do you
invoke memory blocks?
> With void(*)(void), it would need casts on all element
> types.
Yes. Automatic conversion to and from void (data) pointers
is useful because it often makes sense to work with a
pointer to some struct as if it were a pointer to its first
member, or even a pointer to diffrent type, say a char, for
serialisation. But you can do nothing of the sort with
function pointers, which must have their original type to
function (pardon the pun) properly.
> I prefer not to compromise the design of the original
> language to suit C.
Is "comprimise" the right word? How about "redesign",
"reconsider", implement a better type system with a clear
separation between data and logic?
Do you have a simple example demonstrating the need for
generic function/data pointers? (I have not been reading
many of your previous discussions)
> With enough work, this is solvable. But I've spent several
> weeks getting to the point where a non-pedantic compile
> with gcc works without warnings on either OS and on either
> 32-bit or 64-bit targets.
If it was impedance-matching the type systems of your
language and C, then it has been good and necessary work.
> This latter is important because the original language is
> 64-bit everything, and since it was targeted at 64-bit
> Windows, made various assumptions which caused lots of
> mismatches in the C32 output. I hadn't expected to have to
> target a 32-bit machine again, but it turned out the
> 64-bit RPi4 mainly comes with 32-bit OSes and system
> software still.)
So your language is tied to a certain bit depth?
> Anyway, I'm not ready for additional (and unnecessary for
> the purpose of getting working programs) effort to get
> past the -pedantic warnings, and some may yet be
> insurmountable.
I think it would not have been so difficult if you had
started with true C (aka -pedantic).
> (For example, I use unsigned chars, and I define C library
> functions in my language as using unsigned, but when code
> assuming that is written out as C, the compiler will see
> the original function uses signed char, and complain.
The orignal function uses neither signed nor unsigned char,
but the sign-agnostic char -- the only type provided for the
representation of characters. The explicitly singed and
unsigned char types are indtroduced for small-integer
arithmetics.
> If I try and define my own version of the library function
> in the generated C, and eschew all standard function like
> stdio.h, then gcc will complain that my declarations don't
> match what they should be! I can't win.)
That is new to me. Do you say you cannot define, implement,
and use your own version of strlen() in a file that does not
include string.h? I have no such problem in gcc:
#include <stdio.h>
static size_t strlen( unsigned char* s )
{ size_t len;
len = 0;
while( *s != '\0' )
{ len += 1;
s += 1;
}
return len;
}
int main( int argc, char** argv )
{ unsigned char s[10] = "Anton";
printf( "%i\n", strlen( s ) );
return 0;
}
> > Conversion between pointers to functions and data is
> > absurd from the human viewpoint, for data and funcions
> > belong to different conceptual domains. You cannot read
> > from or write to a function pointer. You cannot invoke
> > a data pointer.
>
> It is also absurd to convert pointers to/from integers, ->
More or less yes, for the result is implementation-defined.
Why would one need it except for debugging? This conversion
has no place in portable software.
> You can't read or write via a void point either.
I was comparing function and data domains, and you are
comparing typed and untyped pointers. You can both read and
write via a void pointer after a suitable conversion,
because in C that pointer indicates an object (data, not
function!) with a well-defined type generally amentable to
read and write operations via a pointer to that type.
> Nor with a label pointer (a gcc extension). Yet gcc allows
> a conversion to/from void*. -pedantic will still generate
> a warning, but only that it is non-standard. It doesn't
> say it is Verboten.
That's a problem with gcc, rather than with C. I belive gcc
has another set of options activating the treatment of some
warnings as errors.
> If you think of any pointer as an address, ->
That is true of data pointers, but are you sure that
function pointers in C must be addresses too? Can't an
implementation, in theory, index a function with anything
but an address, e.g. an offset, an incremental index, or
even a string identifer? That, I belive, shows a
fundamental difference between data and function pointers:
the former imply an addressable object in memory, the latter
do not.
> -> these distinctions cease to matter, especially when
> represented as a void*. C is famous for being 'close to
> the metal' after all.
Yet it is a high-level and hardware-agnostic language.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-07 17:02 -0700 |
| Message-ID | <lnlftwumt8.fsf@kst-u.example.com> |
| In reply to | #146714 |
Anton Shepelev <anton.txt@gmail.com> writes:
> Bart:
[...]
>> Nor with a label pointer (a gcc extension). Yet gcc allows
>> a conversion to/from void*. -pedantic will still generate
>> a warning, but only that it is non-standard. It doesn't
>> say it is Verboten.
>
> That's a problem with gcc, rather than with C. I belive gcc
> has another set of options activating the treatment of some
> warnings as errors.
C requires a diagnostic for any violation of a constraint or syntax
rule. It does not require the diagnostic to be fatal. A fully
conforming C implementation can compile and generate an executable
for a program with arbitrary errors, as long as it issues at least
one compile-time warning. (I personally dislike this, but that's
what the C standard says.) Only a #error directive that survives
preprocessing actually requires a conforming compiler to fail to
compile something.
"gcc -std=c11 -pedantic" issues non-fatal warnings for many
constraint violations -- which satisfies the C standard's
requirements. "gcc -std=c11 -pedantic-errors" turns those
warnings into fatal errors -- which also satisfies the C standard's
requirements.
("gcc ... -Werror" turns all warnings into fatal errors, which is
not conforming. The fact that it's not conforming doesn't mean
it's not useful.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 08:53 +0200 |
| Message-ID | <qnhbq7$thb$1@dont-email.me> |
| In reply to | #146714 |
On 08/10/2019 01:27, Anton Shepelev wrote: > Bart: > >> >> It is also absurd to convert pointers to/from integers, -> > > More or less yes, for the result is implementation-defined. > Why would one need it except for debugging? This conversion > has no place in portable software. > There is a gap here, between "debugging" and "portable software". Converting pointers to integers can have a number of uses in code, but it is almost entirely for data pointers. Amongst the more portable uses, you might have need of them when handling offsets within structures that are serialised or part of file formats. You /might/ also find them handy for complicated array structures (like triangular arrays rather than rectangular ones) - but you'd probably be better using a pointer to the start and a calculated integer-type offset. For non-portable uses, an example would be DMA hardware - you will need to pass addresses back and forth to the hardware as integers, typically uint32_t or uin64_t. And on some embedded systems, at the very lowest level, you might want to handle interrupt vectors as pointers to functions converted to an integer type. (I've seen other very low level, highly non-portable, uses of function pointers as integers in embedded systems. Usually, however, it was not the best way to write the code in modern C.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-08 12:28 +0100 |
| Message-ID | <1q_mF.841756$Zy3.585129@fx33.am4> |
| In reply to | #146714 |
On 08/10/2019 00:27, Anton Shepelev wrote:
> If it is a hardware-abstract, high-level language, then why
> do you need such conversion? Surely you do not write to, or
> perform address arithmetics on function pointers, nor do you
> invoke memory blocks?
No but you sometimes want a generic function pointer type, and the void*
type ('ref void' in my language) suits that.
I sometimes use 'ref proc' (void(*)(void) in C), but that is not a true
generic function type, it could be a real one!
Generic function pointers occur in many places in the programs I write
(so global tables of functions, all of mixed type, or dealing with
accessing external DLL/so functions in programs such as interpreters).
>> I prefer not to compromise the design of the original
>> language to suit C.
>
> Is "comprimise" the right word? How about "redesign",
> "reconsider", implement a better type system with a clear
> separation between data and logic?
C has the restriction with object/function pointers because of its
history of dealing with odd architectures, still ongoing with its use in
micro-controllers. It could be that object and function pointers are
very different on those devices.
That also explains its chaotic type system.
So why should a new language make the same choices as C? I decided that
void* should accommodate all kinds of pointers, and that all would also
use the same 32/64-bit representation.
>> This latter is important because the original language is
>> 64-bit everything, and since it was targeted at 64-bit
>> Windows, made various assumptions which caused lots of
>> mismatches in the C32 output. I hadn't expected to have to
>> target a 32-bit machine again, but it turned out the
>> 64-bit RPi4 mainly comes with 32-bit OSes and system
>> software still.)
>
> So your language is tied to a certain bit depth?
The language supports 8/16/32/64/128-bit data types but the default
'int' size is 64 bits, and calculations are done at at least 64 bits.
But the generated C has to be either C32 or C64 form, because the C code
contains embedded assumptions about the size of the target.
(Some people have suggested it is possible to generate C without those
assumptions; well those people can try writing their own C code generators!)
> That is new to me. Do you say you cannot define, implement,
> and use your own version of strlen() in a file that does not
> include string.h? I have no such problem in gcc:
>
> #include <stdio.h>
>
> static size_t strlen( unsigned char* s )
I don't always see the message, so I'm not sure what will trigger it.
But with this for example, by itself in a file:
extern int sprintf(unsigned char*, ...);
gcc will say: 'warning: conflicting types for built-in function
‘sprintf’'. This is a not a correct sprint declaration, but it indicates
it knows about the 'official' sprintf and is keeping tabs.
Maybe there is a way around this but eliminating all or most standard
headers is something for which I don't know the full implications.
And for now, everything works fine, except for the people who will say
that C isn't C unless it passes -std=cx -pedantic. I guess my code is
not for them, then.
All my code is experimental. It means I can run my own language on
LINUX/ARM now without needing a full aarch64 native code generator,
which can follow later. If the intermediate C offends some people, then
so be it.
I think any additional efforts are better directed at a proper native
code back-end, thus eliminating the C stage completely, than at keeping
people here happy.
(Or I might just keep on using my C backend, which in actuality works
remarkably well, especially with a brisk compiler like tcc in the chain,
and not tell anyone about it!)
> I was comparing function and data domains, and you are
> comparing typed and untyped pointers. You can both read and
> write via a void pointer after a suitable conversion,
> because in C that pointer indicates an object (data, not
> function!) with a well-defined type generally amentable to
> read and write operations via a pointer to that type.
A pointer is simply an indirect reference to something else.
If dealing with collections of non-matching pointers, or writing a
function that can deal generically with any kind of pointer, then a
common representation (like C's void*) is useful.
C's arbitrary restriction (which you can get around with a double cast
anyway) is not helpful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-08 11:47 -0700 |
| Message-ID | <lnh84jul9p.fsf@kst-u.example.com> |
| In reply to | #146737 |
Bart <bc@freeuk.com> writes:
> On 08/10/2019 00:27, Anton Shepelev wrote:
>> If it is a hardware-abstract, high-level language, then why
>> do you need such conversion? Surely you do not write to, or
>> perform address arithmetics on function pointers, nor do you
>> invoke memory blocks?
>
> No but you sometimes want a generic function pointer type, and the void*
> type ('ref void' in my language) suits that.
Of course you already know how to implement a generic function pointer
type in valid and portable C, because I've explained it to you before.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-09 02:02 +0300 |
| Message-ID | <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> |
| In reply to | #146737 |
Bart:
> I sometimes use 'ref proc' (void(*)(void) in C), but that
> is not a true generic function type, it could be a real
> one!
But is it a significant obstacle to you, who disregard the C
standard and seem content with whatever code happens to work
a set of compilers invoked wihout any language-relaged
options?
> Generic function pointers occur in many places in the
> programs I write (so global tables of functions, all of
> mixed type, or dealing with accessing external DLL/so
> functions in programs such as interpreters).
Understood.
> C has the restriction with object/function pointers
> because of its history of dealing with odd architectures,
> still ongoing with its use in micro-controllers. It could
> be that object and function pointers are very different on
> those devices.
I know not the reason but only the fact and find the
distinction quite logical from a purely abstract viewpoint.
> So why should a new language make the same choices as C?
The only possible reason is to simplify the generation of
intermediate C, although with more work you can of course
completely disentagle the types of your language form those
of C. Why not, for example, represent the generic pointer
as a struct or struct-union containing both void* and
void(*)(void) as members, and a flag or enum identifying the
currently effetive type of that pointer? Would that be
possible? Would that require months of work?
> I decided that void* should accommodate all kinds of
> pointers, and that all would also use the same 32/64-bit
> representation.
If that is a property of your language, I have no
objections. If that is a property that you impose upon the
non-standard dialect of C that your tools generate, I demur.
> > So your language is tied to a certain bit depth?
>
> The language supports 8/16/32/64/128-bit data types but
> the default 'int' size is 64 bits, and calculations are
> done at at least 64 bits.
Then I should say it is tie. Native types (with hardware-
dependent sizes) with minimal introspection (limits.h) are a
good idea in terms of both long-term scalability and
efficiency, whereas fixed-size types must also be supported
for obvious reasons. An alternative solution to fixed-with
types could be a macro or an extra-language facility that
would expand into the smallest native type that can
accomodate a specifed range or generate a compile-time error
if such a type is not available on the machine, e.g.
i: int // a/the native integer
j: int(6000); // the smallest native int that can hold 6000
My intuitive and simplified (mis)understanding and
justification of the basic C types is as follows:
-- Simple type identifiers unmodifed by adjectives
represent the most natural type for the machine, so
that `int' would be the most natural integer for the
CPU.
-- `long' identifes a extended size, perhaps unnatural or
even unsupported natively by the CPU.
-- `short' identifies a smaller size than the CPU can
easily handle.
> But the generated C has to be either C32 or C64 form,
> because the C code contains embedded assumptions about the
> size of the target.
I am not a systems programmer and have no idea what those
assumptions are, but the type sizes may also depend on the
compiler, unless they are the new C99 "extended integer-type
names"...
> (Some people have suggested it is possible to generate C
> without those assumptions; well those people can try
> writing their own C code generators!)
And you can follow their advice if it is sound, but I know
nothing of the subject.
> I don't always see the message, so I'm not sure what will
> trigger it. But with this for example, by itself in a
> file:
>
> extern int sprintf(unsigned char*, ...);
>
> gcc will say: 'warning: conflicting types for built-in
> function `sprintf'. This is a not a correct sprint
> declaration, but it indicates it knows about the
> 'official' sprintf and is keeping tabs.
Yes, the names of standard C functions are reserved for
external linkage. How do you want that declaration to work
and what implementation to have?
> Maybe there is a way around this but eliminating all or
> most standard headers is something for which I don't know
> the full implications.
How's about a wrapper:
#include <stdio.h>
#include <string.h>
static int bstrlen( unsigned char const *s )
{ return strlen( ( const char * )s ); }
int main( int argc, char** argv )
{ printf("%i\n", bstrlen( (unsigned char * )"Hi, Bart!" ) );
return 0;
}
> And for now, everything works fine, except for the people
> who will say that C isn't C unless it passes
> -std=cx -pedantic. I guess my code is not for them, then.
You are interested in code that works with a set of
compilers rather than in the standard. But do you have the
specificaion of the exact common subset of the C dialect
that your C compilers accept when invoked with default
options? If not, how can you guarrantee that "everything
works" in your code generator?
> I think any additional efforts are better directed at a
> proper native code back-end, thus eliminating the C stage
> completely, than at keeping people here happy.
What about the future generations of users and maintainers
of your tools? Whereas the standard is set in stone, the C
dialect that a set of currenly maintained compilers happen
to accept by default is subject to change!
> (Or I might just keep on using my C backend, which in
> actuality works remarkably well, especially with a brisk
> compiler like tcc in the chain, and not tell anyone about
> it!)
Especially if you build a specific version of TCC into your
tool.
> A pointer is simply an indirect reference to something
> else.
But this reference need not be made by means of an address.
A pointer is an abstract concept with many possible
implementations. Especially so in case of a function
pointer.
> If dealing with collections of non-matching pointers, or
> writing a function that can deal generically with any kind
> of pointer, then a common representation (like C's void*)
> is useful.
Not in true C, as you know.
> C's arbitrary restriction (which you can get around with a
> double cast anyway) is not helpful.
Well, I have already said why I think it is not arbitrary.
And no, you don't get around this restriction in true C. It
is just that the compilers you employ *happen* to let you do
that. They are not obliged to.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 00:50 +0100 |
| Message-ID | <Pg9nF.750165$bS1.468151@fx13.am4> |
| In reply to | #146783 |
On 09/10/2019 00:02, Anton Shepelev wrote:
> The only possible reason is to simplify the generation of
> intermediate C, although with more work you can of course
> completely disentagle the types of your language form those
> of C. Why not, for example, represent the generic pointer
> as a struct or struct-union containing both void* and
> void(*)(void) as members, and a flag or enum identifying the
> currently effetive type of that pointer? Would that be
> possible? Would that require months of work?
More work than I would like. It would be probably be less work to just
generate native code rather than C.
> If that is a property of your language, I have no
> objections.
My language comes first (its first crude version was about a dozen years
before I tried C). It already has plenty of things that don't yet/never
will translate to C so I can't use those features if the result must be
portable. But the intermediate C might turn out to be a stop-gap.
>> The language supports 8/16/32/64/128-bit data types but
>> the default 'int' size is 64 bits, and calculations are
>> done at at least 64 bits.
>
> Then I should say it is tie.
You can say pretty much the same about C, for typical desktop
implementations:
"The C language supports 8/16/32/64-bit data types but
the default 'int' size is 32 bits, and calculations are
done at at least 32 bits."
Native types (with hardware-
> dependent sizes) with minimal introspection (limits.h) are a
> good idea in terms of both long-term scalability and
> efficiency, whereas fixed-size types must also be supported
> for obvious reasons. An alternative solution to fixed-with
> types could be a macro or an extra-language facility that
> would expand into the smallest native type that can
> accomodate a specifed range or generate a compile-time error
> if such a type is not available on the machine, e.g.
>
> i: int // a/the native integer
> j: int(6000); // the smallest native int that can hold 6000
Range types: I don't like elaborate type systems, and things like this,
done properly, always end up with type systems like Ada's.
> My intuitive and simplified (mis)understanding and
> justification of the basic C types is as follows:
>
> -- Simple type identifiers unmodifed by adjectives
> represent the most natural type for the machine, so
> that `int' would be the most natural integer for the
> CPU.
Which is no longer true now that most desktop hardware is 64 bits. My
language uses these types with unspecified widths, with that 64-bit
hardware in mind:
Signed? Width
int Signed 64 bits
intm Signed Machine word size, 32 or 64
intp Signed Machine address size, 32 or 64
word Unsigned 64 bits
wordm Unsigned Machine word size, 32 or 64
wordp Unsigned Machine address size, 32 or 64
The -m and -p have only come into play again now that I need to support
a 32-bit target. (-p and -m sizes usually the same, but I did have one
compiler where the machine word was 64 bits, but pointers were 32)
> -- `long' identifes a extended size, perhaps unnatural or
> even unsupported natively by the CPU.
>
> -- `short' identifies a smaller size than the CPU can
> easily handle.
I don't find these long, short, long long etc useful, especially when
the language doesn't specify the default int size, and neither when does
it specify what affect each 'long' has on that.
If these types were used in an API to be used as a foreign function
library from other languages, then you'd see the problem.
>> But the generated C has to be either C32 or C64 form,
>> because the C code contains embedded assumptions about the
>> size of the target.
>
> I am not a systems programmer and have no idea what those
> assumptions are, but the type sizes may also depend on the
> compiler, unless they are the new C99 "extended integer-type
> names"...
What happens is that if I used the equivalent of 'sizeof(void*)', that
gets hard-coded in the C as either "4" or "8". Once that happens, C
source containing "4" must use a C compiler with 32-bit pointers, not
64, and similar for "8".
This reduction is made early in compilation (eg. constant expression
reduction), but would need delaying to a later stage for there to be a
single C target. That would be too much disruption, and has other
implications.
> How's about a wrapper:
>
> #include <stdio.h>
> #include <string.h>
>
> static int bstrlen( unsigned char const *s )
> { return strlen( ( const char * )s ); }
>
> int main( int argc, char** argv )
> { printf("%i\n", bstrlen( (unsigned char * )"Hi, Bart!" ) );
> return 0;
> }
Written in C or original language? If the latter, then that strlen still
appears in its source code, with the same problems. If in C, then it
means there is now a dependency on an actual C module (written in C, not
generated), separate from the main language.
My aim is to have as few dependencies as possible.
The real problem here is C's abstract 'char' type is a poor choice for a
language neutral API. It needs to be a concrete type, and ideally not
signed either. (What sense is there in a signed char type anyway?)
> What about the future generations of users and maintainers
> of your tools? Whereas the standard is set in stone, the C
> dialect that a set of currenly maintained compilers happen
> to accept by default is subject to change!
My C is code is fairly conservative and uses few features.
(A set of standard C headers defining only the library features I need,
would only be about 200 lines in total. The actual total is, iirc,
28,000 lines in gcc/Windows, 48,000 lines in gcc/Linux, and 1,400 lines
in my C compiler.)
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-10 03:03 +0300 |
| Message-ID | <20191010030322.2da081faffb190e4f5370362@gmail.com> |
| In reply to | #146785 |
Bart:
> My language comes first (its first crude version was about
> a dozen years before I tried C).
Naturally: you design your language and then translate it
into C.
> It already has plenty of things that don't yet/never will
> translate to C so I can't use those features if the result
> must be portable.
Why not, because it is too much work? Anything can be
translated into C: C++, Lua, Python, and BartLang.
> > > The language supports 8/16/32/64/128-bit data types
> > > but the default 'int' size is 64 bits, and
> > > calculations are done at at least 64 bits.
> >
> > Then I should say it is tie.
>
> You can say pretty much the same about C, for typical
> desktop implementations:
>
> "The C language supports 8/16/32/64-bit data types but the
> default 'int' size is 32 bits, and calculations are done
> at at least 32 bits."
I was comparing the languages, not their implementations.
The primary types of your language are hardware-bound. The
primary types of the C language are not, so that
implementations are free to choose whatever native types are
available on the platform, or even to provide software-based
types unavailable natively. As far as I understand, nothing
stands in the way of implementing for the 32-bit x86 patform
some "Extended-range C compiler" where `int' is 256 bits and
`long int' 512! That is the power of abstract types.
> Range types: I don't like elaborate type systems, and
> things like this, done properly, always end up with type
> systems like Ada's.
I meant not range types but a facility that can pick a
native type sufficient for storing a certain value. It is a
parametrised generalisation of the `int_least*' family of
types in C. I think it better to provide a couple of
predicates than to keep adding fixed types, e.g.:
Type(int, 8, least) for int_least8_t, &c
> I don't find these long, short, long long etc useful,
> especially when the language doesn't specify the default
> int size, and neither when does it specify what affect
> each 'long' has on that.
Well, the Netpbm setup utility makes good use of them. It
compiles a series of test programs to determine the exact
sizes of the basic types and adjusts the build parameters
accordingly.
> If these types were used in an API to be used as a foreign
> function library from other languages, then you'd see the
> problem.
Such an API can use the fixed-with types, either defined in
its own header or in inttypes.h.
> What happens is that if I used the equivalent of
> 'sizeof(void*)', that gets hard-coded in the C as either
> "4" or "8". Once that happens, C source containing "4"
> must use a C compiler with 32-bit pointers, not 64, and
> similar for "8".
Understood -- you have to know the sizes of abstract C types
if you want to use them. But can you generate code with
sizeof(), postponing its expansion till the stage where the
generated C is compiled?
You can write a single feature-test program in C that will
gather and print all the platform- and implementaiton-
specific information needed for your transpiler. If you
write it in standard C, the program shall work with any C
compiler and require no maintenance.
> > How's about a wrapper:
> >
> > #include <stdio.h>
> > #include <string.h>
> >
> > static int bstrlen( unsigned char const *s )
> > { return strlen( ( const char * )s ); }
> >
> > int main( int argc, char** argv )
> > { printf("%i\n", bstrlen( (unsigned char * )"Hi, Bart!" ) );
> > return 0;
> > }
> Written in C or original language?
My example is obviously a C program.
> If in C, then it means there is now a dependency on an
> actual C module (written in C, not generated), separate
> from the main language.
You can hardcode this wrapper for a standard function into
your tool and forget about it, because standard C is very
unlikely ever to break. A neat C unit with wrappers for
standard functions and the implementations, as functions or
macros, of operators present in your language and absent
from C seems an excellent idea. It is not so much a
dependency but a necessary stage of translating one language
into another. An alternative solution is to teach your
generator to convert the pointers on-the-fly.
> My aim is to have as few dependencies as possible.
The only dependency in your C generator will be on the C
language, but that one is unavoidable, exacty as knowledge
of Frech is for a English-to-French translator. Your tool
must be "aware" of C in some way or other in order to
generate it, no? Hardcoded wrappers for standard functions
are just a way to store that knowledge of C in the
generator. The modules shall not change unless the language
itself receives a change that breaks backward compatibility.
> The real problem here is C's abstract 'char' type is a
> poor choice for a language neutral API.
True, but you have to deal with it rather than thrust
incompatible types down C's throat.
> It needs to be a concrete type, and ideally not signed
> either. (What sense is there in a signed char type
> anyway?)
Therefore, a transpiler shall *implement* the types of the
source language in terms of the target language. In the
general case, it involves a process called (de)serialisation
or marshalling, in which the data of a source type is
recomposed on a binary level to get a correct representation
of the target type.
> > What about the future generations of users and
> > maintainers of your tools? Whereas the standard is set
> > in stone, the C dialect that a set of currenly
> > maintained compilers happen to accept by default is
> > subject to change!
>
> My C is code is fairly conservative and uses few features.
Yet very liberal in that it relies on compiler-specific
relaxations of C among those few features.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 01:51 +0100 |
| Message-ID | <ogvnF.2759746$c8w1.2458376@fx08.am4> |
| In reply to | #146826 |
On 10/10/2019 01:03, Anton Shepelev wrote: > Bart: > >> My language comes first (its first crude version was about >> a dozen years before I tried C). > > Naturally: you design your language and then translate it > into C. > >> It already has plenty of things that don't yet/never will >> translate to C so I can't use those features if the result >> must be portable. > > Why not, because it is too much work? Anything can be > translated into C: C++, Lua, Python, and BartLang. There's quite few things that C can't represent without a good deal of trouble, or without it being practical, or where it can only be done by emulating a VM for my target. Examples of some features I have or had: * Stack, Unstack statements as I once had (this pushes/pops expressions to/from the hardware stack) * Synthesising function calls at runtime, eg. given a function pointer - a generic one - and data that lists the number of parameters and their types. I don't a special feature for that, but I could have. At present I use ... * Inline assembly * 'Equivalence' statement where two variables/data structures share memory, eh. int A @ B[3] * Multiple function return types * Interchangeable statements and expressions (gcc has some extensions for this I think) * Structs containing other than normal fields (eg. actual functions) * N-way selection, inside an expression. (This would need a switch statement, one that returns a value, inside an expression. Currently emulated with a ?: chain.) * Type-punning an expression (usual way requires an lvalue) * Threaded functions (needs ability to jump to, not call, a function) There are plenty of other ideas that can be played with (overflow detection for example), which are easy when generating native code, but much harder when generating a HLL. (Will reply to other points later.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-10 10:31 +0200 |
| Message-ID | <qnmq8j$kej$1@dont-email.me> |
| In reply to | #146827 |
On 10/10/2019 02:51, Bart wrote: > On 10/10/2019 01:03, Anton Shepelev wrote: >> Bart: >> >>> My language comes first (its first crude version was about >>> a dozen years before I tried C). >> >> Naturally: you design your language and then translate it >> into C. >> >>> It already has plenty of things that don't yet/never will >>> translate to C so I can't use those features if the result >>> must be portable. >> >> Why not, because it is too much work? Anything can be >> translated into C: C++, Lua, Python, and BartLang. > > There's quite few things that C can't represent without a good deal of > trouble, or without it being practical, or where it can only be done by > emulating a VM for my target. Examples of some features I have or had: You have two serious, fundamental problems here. It has left you stuck in a rut for many years in regards to your languages. When a language designer wants to make a new language, there are several parts involved. There is a front-end to interpret the language and generate some kind of internal trees and other structures. There is one or more generators for producing output, perhaps assembly, binaries, C code, or something else. There is a language library with functions, classes, etc., for easy use in the new language. There is a run-time support library with code needed by the implementation, written in the output formats. This applies, at least roughly, to all languages I have known. In the case of C, the output is usually assembly or binaries but I have seen other options (including other C variants). The language library covers functions like strcmp, malloc, printf, etc., and can often be quite general and portable (like newlib or glibc). The run-time support libraries are additional code such as startup (pre-main) code, software floating point routines, implementation code used by the language libraries, and are highly target and compiler specific, and may be written in C or assembly. With your manic obsession about "put everything in one file", you have forgotten about libraries. I don't know much about your language libraries - maybe you consider them baked into the language itself. But you are missing your run-time support library. You are missing the "bartlanglib.c" and "bartlanglib.h" files that would provide run-time functions for handling a stack, synthesising function calls, and all the other features that can't be implemented easily in a few lines of C. It would contain whatever type definitions you want in order to abstract from details of the target system. It would contain functions for doing integer arithmetic with your choice of promotion rules, overflow handling, etc. And perhaps partly because of this, you have an even more fundamental mistake. You are trying to do a direct translation from your language to C, even though the concepts and semantics don't match. If you are proficient in another human language (or can remember your French from schooldays), you will appreciate that you cannot translate from one human language to another by looking up each word in a dictionary and writing down the translated words. The same applies for computer languages. You can't translate "i32" in your language to "int" in C, because they don't do the same thing. You can't translate "return multiple" in your language into "return" in C, because they don't do the same thing. You have to figure out ways to write C code that does what you want, rather than bemoaning that a blind translation does not cover it. That might mean having a type "bartlang_int_32" that is a union of "int32_t" and "uint32_t", and use inline functions to do arithmetic on it with the overflow behaviour you want. It might mean that each "bartlang" function gets a corresponding C function that takes a pointer to a struct for its return value, leaving the standard C return as an indicator of success or failure. Once you understand that, I don't think any of your features below (except perhaps inline assembly) would be impractical to implement. > > * Stack, Unstack statements as I once had (this pushes/pops expressions > to/from the hardware stack) > > * Synthesising function calls at runtime, eg. given a function pointer - > a generic one - and data that lists the number of parameters and their > types. I don't a special feature for that, but I could have. At present > I use ... > > * Inline assembly > > * 'Equivalence' statement where two variables/data structures share > memory, eh. int A @ B[3] > > * Multiple function return types > > * Interchangeable statements and expressions (gcc has some extensions > for this I think) > > * Structs containing other than normal fields (eg. actual functions) > > * N-way selection, inside an expression. (This would need a switch > statement, one that returns a value, inside an expression. Currently > emulated with a ?: chain.) > > * Type-punning an expression (usual way requires an lvalue) > > * Threaded functions (needs ability to jump to, not call, a function) > > There are plenty of other ideas that can be played with (overflow > detection for example), which are easy when generating native code, but > much harder when generating a HLL. > > > (Will reply to other points later.) > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 11:57 +0100 |
| Message-ID | <m8EnF.2633749$dw4.664817@fx12.am4> |
| In reply to | #146830 |
On 10/10/2019 09:31, David Brown wrote:
> On 10/10/2019 02:51, Bart wrote:
> With your manic obsession about "put everything in one file", you have
> forgotten about libraries.
Mainly for distribution purposes, in the same way that people use .zip
or .tar.gz, for .exe for finished binaries.
I happen to use forms that are also legal source code.
You are also forgetting that my compilers (except for C because the
language is not designed for it) are whole-program compilers, so the
compilation unit - the smallest part of the program you can compile in
one go - is the whole program (all the modules that go into one .exe or
.dll), rather than the module.
Then intermediate output (.asm, .obj, .c) and full output (.exe, Linux
binary executable, .dll, .so; or .pc for byte-code) will necessarily be
one file too.
I don't think any unbiased, open-minded person reading this account will
find those aims at all unreasonable. They can be considered a natural
progression. Only you with your hatred and total misunderstanding of
everything I do.
As for libraries: my C compiler relies on the external library
msvcrt.dll on Windows, linked in when the .exe is loaded. For the small
number of support functions it needs, it uses bcclib.asm, but this is
usually handled transparently.
If you look at this file: https://github.com/sal55/qx/blob/master/cc.ma2
which lists the true-source modules of my C compiler (and which actually
contains all those modules) then:
- Files 2, 3, 4, 5 are the libraries used by the implementation language
M (here, they are chosen for a Windows target generating native code)
- File 29 is the bcclib.asm I alluded to above.
- Files 30 to 71 are the bundled standard headers of this compiler
- File 67 is the special bcc.h that is always implicitly included by the
compiler
All very straightforward and open.
Show me any other C compiler or like project where everything can be
laid out so clearly. You can turn this actual file into a working,
self-containing C compiler using:
mm cc.ma # (.ma2 used on github for tech reasons)
Eg:
C:\cx>mm cc.ma
Compiling cc.m to cc.exe
C:\cx>
It took 0.23 seconds. And it seems to work:
C:\cx>cc hello -run
Compiling hello.c to hello.exe
Hello World!
I don't know much about your language
> libraries - maybe you consider them baked into the language itself. But
> you are missing your run-time support library.
See above.
You are missing the
> "bartlanglib.c" and "bartlanglib.h" files that would provide run-time
> functions
In the implementation language, this is done by file 2 in the link,
msys.m, which takes care of static foreign function calls (the ones
known at compile time, since its call convention, and the standard ABI,
differ); read/print support; 128-bit arithmetic and so on.
for handling a stack, synthesising function calls, and all the
> other features that can't be implemented easily in a few lines of C.
Really? REALLY? Do you have an example (eg. push 4 or 8 bytes of 1234 to
the stack), is this something that won't quite fit in the margin of your
reply.
Have a look at the libffi library which provides exactly this
functionality for C. Half the modules there use assembly, BECAUSE YOU
CAN'T DO IT IN C.
I don't have stack/unstack any more, but here it is in an old language:
proc start=
stack 1234
end
And here is the output:
segment .text ;
_start: ; ;
L1: ; ;
push dword 1234 ;
retn ;
> And p
erhaps partly because of this, you have an even more fundamental
> mistake. You are trying to do a direct translation from your language
> to C, even though the concepts and semantics don't match.
I normally do a direct translation to x64 ASM, even though the concepts
don't match either!
Both my 'M' language and C have largely the same concepts - dealing with
low-level data structures, operations and pointers based on
8/16/32/64-bit ints, 32/64-bit floats, and 32/64-bit pointers.
Those data types are also common to Java, D, Go, Rust, C#, Scala and Kotlin.
Guess which of these languages makes a complete mess of it all.
> don't do the same thing. You can't translate "return multiple" in your
> language into "return" in C, because they don't do the same thing. You
> have to figure out ways to write C code that does what you want, rather
> than bemoaning that a blind translation does not cover it.
I'm not moaning that C doesn't do multiple return returns. I'm just
saying it's one of those things that can't easily be expressed in C, so
that a C target can only support a subset of the original language.
> Once you understand that, I don't think any of your features below
> (except perhaps inline assembly) would be impractical to implement.
I said:
"There's quite few things that C can't represent without a good deal of
trouble, or without it being practical, or where it can only be done by
emulating a VM for my target."
'.. a good deal of trouble ..'
The C target is anyway largely a stop-gap.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-10 14:24 +0200 |
| Message-ID | <qnn7up$l0$1@dont-email.me> |
| In reply to | #146834 |
On 10/10/2019 12:57, Bart wrote: > On 10/10/2019 09:31, David Brown wrote: >> On 10/10/2019 02:51, Bart wrote: > >> With your manic obsession about "put everything in one file", you have >> forgotten about libraries. > > Mainly for distribution purposes, in the same way that people use .zip > or .tar.gz, for .exe for finished binaries. > > I happen to use forms that are also legal source code. > > You are also forgetting that my compilers (except for C because the > language is not designed for it) are whole-program compilers, so the > compilation unit - the smallest part of the program you can compile in > one go - is the whole program (all the modules that go into one .exe or > .dll), rather than the module. > I'm not forgetting it at all - but it doesn't matter. Whole-program compilation is fine for small programs, or when you want the most efficient possible output - it is less good for programs under development. (It can allow cross-module static checking, however.) C was not designed with whole-program compilation in mind, but there is nothing to hinder it - there are plenty of compilers that do whole-program and cross-module compilation, and link-time optimisation. Still, this does not matter. It would even be fine to you to paste the run-time support library code into the single generated C code. The point remains that you shy away from code to support your language requirements. > Then intermediate output (.asm, .obj, .c) and full output (.exe, Linux > binary executable, .dll, .so; or .pc for byte-code) will necessarily be > one file too. The full output (exe file or whatever) is usually one file anyway if the program is not too big. That applies regardless of the number of source files or intermediate files. > > I don't think any unbiased, open-minded person reading this account will > find those aims at all unreasonable. They can be considered a natural > progression. Only you with your hatred and total misunderstanding of > everything I do. I don't hate what you do - I am trying to /help/ you. When I think you are doing something wrong, or there are better ways to do it, or you are failing to understand something, I tell you. When I think you are saying something interesting, or have good ideas, I say that too. There have been few of these in our recent conversations, unfortunately. (Maybe that's simply because the bits you can handle well, such as the front-end to your tools, haven't been discussed here.) I have been trying - and many will say it's a fool's errand - to help you with turning your source code into decent C code in a way that is correct, portable, and easier for you. > > As for libraries: my C compiler relies on the external library > msvcrt.dll on Windows, linked in when the .exe is loaded. For the small > number of support functions it needs, it uses bcclib.asm, but this is > usually handled transparently. > > If you look at this file: https://github.com/sal55/qx/blob/master/cc.ma2 > which lists the true-source modules of my C compiler (and which actually > contains all those modules) then: > > - Files 2, 3, 4, 5 are the libraries used by the implementation language > M (here, they are chosen for a Windows target generating native code) > > - File 29 is the bcclib.asm I alluded to above. > > - Files 30 to 71 are the bundled standard headers of this compiler > > - File 67 is the special bcc.h that is always implicitly included by the > compiler > > All very straightforward and open. > > Show me any other C compiler or like project where everything can be > laid out so clearly. You can turn this actual file into a working, > self-containing C compiler using: > > mm cc.ma # (.ma2 used on github for tech reasons) > > Eg: > > C:\cx>mm cc.ma > Compiling cc.m to cc.exe > C:\cx> > > It took 0.23 seconds. And it seems to work: > > C:\cx>cc hello -run > Compiling hello.c to hello.exe > Hello World! > > > I don't know much about your language >> libraries - maybe you consider them baked into the language itself. But >> you are missing your run-time support library. > > See above. > > You are missing the >> "bartlanglib.c" and "bartlanglib.h" files that would provide run-time >> functions > > In the implementation language, this is done by file 2 in the link, > msys.m, which takes care of static foreign function calls (the ones > known at compile time, since its call convention, and the standard ABI, > differ); read/print support; 128-bit arithmetic and so on. > > > for handling a stack, synthesising function calls, and all the >> other features that can't be implemented easily in a few lines of C. > > Really? REALLY? Do you have an example (eg. push 4 or 8 bytes of 1234 to > the stack), is this something that won't quite fit in the margin of your > reply. > There are three possible ways to view this. One is you are talking about a general stack - or something that could be implemented as a general stack. You do that by writing code for a stack in C - choosing whatever suits regarding sizes, underlying structures, etc. One is that it is a language specific stack - like the parameter stack in Lua or Forth. Again, just write suitable C functions for it - possibly with a different balance of efficiencies. But if you are talking about pushing data onto the cpu's main stack, then it doesn't make sense - certainly not when you are targeting a language at a higher level than that. > Have a look at the libffi library which provides exactly this > functionality for C. Half the modules there use assembly, BECAUSE YOU > CAN'T DO IT IN C. > > I don't have stack/unstack any more, but here it is in an old language: > > proc start= > stack 1234 > end > > And here is the output: > > segment .text ; > _start: ; ; > L1: ; ; > push dword 1234 ; > retn ; > And the use-case of this is... what? A new way to crash your software? The C way to get this effect would be: ((void (*)(void)) 1234)(); You could, if you like, use: #define start asm volatile( "push dword 1234 ") But that is cheating a bit as C. > >> And p > > > erhaps partly because of this, you have an even more fundamental >> mistake. You are trying to do a direct translation from your language >> to C, even though the concepts and semantics don't match. > > I normally do a direct translation to x64 ASM, even though the concepts > don't match either! > > Both my 'M' language and C have largely the same concepts - dealing with > low-level data structures, operations and pointers based on > 8/16/32/64-bit ints, 32/64-bit floats, and 32/64-bit pointers. There may be a fair amount of similarities, but there is a fair amount of difference too. And you don't seem to grasp that /you/ need to understand and handle those differences - you can't just pretend they are not there, then blame C for not working like your language. > > Those data types are also common to Java, D, Go, Rust, C#, Scala and > Kotlin. > > Guess which of these languages makes a complete mess of it all. > > >> don't do the same thing. You can't translate "return multiple" in your >> language into "return" in C, because they don't do the same thing. You >> have to figure out ways to write C code that does what you want, rather >> than bemoaning that a blind translation does not cover it. > > I'm not moaning that C doesn't do multiple return returns. I'm just > saying it's one of those things that can't easily be expressed in C, so > that a C target can only support a subset of the original language. > Of course it can easily be expressed in C. >> Once you understand that, I don't think any of your features below >> (except perhaps inline assembly) would be impractical to implement. > > I said: > > "There's quite few things that C can't represent without a good deal of > trouble, or without it being practical, or where it can only be done by > emulating a VM for my target." > > '.. a good deal of trouble ..' > > The C target is anyway largely a stop-gap. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 14:41 +0100 |
| Message-ID | <%xGnF.818636$Nw3.297741@fx40.am4> |
| In reply to | #146837 |
On 10/10/2019 13:24, David Brown wrote:
> On 10/10/2019 12:57, Bart wrote:
>> I don't have stack/unstack any more, but here it is in an old language:
>>
>> proc start=
>> stack 1234
>> end
>>
>> And here is the output:
>>
>> segment .text ;
>> _start: ; ;
>> L1: ; ;
>> push dword 1234 ;
>> retn ;
>>
>
> And the use-case of this is... what? A new way to crash your software?
Example 1:
stack x # save old value
... code changes x
unstack x # restore old value
(Often when recursive functions were involved, x might have been a
struct or array, and when x was global )
Example 2:
stack a, b
unstack a, b
This swaps a and b. (I used this before I had 'swap', sometimes like
this (actual example from an old program):
stack x; x:=y; unstack y
Saves creating an explicitly named and typed temporary; would be great
for a C macro, yes?)
Example 3:
stack x # x is an array of 3 ints (1st element on top)
unstack a, b, c # store elements into 3 ints vars a, b and c
(Here attention must be paid to stack granularity which was 32-bits for
this language, and to match number of elements)
Example 4:
You have a generic function pointer fn, which you know takes N
parameters from params[] (double-width params take two slots):
for i:=N downto 1 do
stack params[i]
od
fn() # calls as a function taking 0 params
(This requires that the target uses a simple stack-based call
convention, as my current ones do, otherwise it gets messier.)
It is easy to think of applications FOR LOW LEVEL WORK.
Bear in mind I starting using this in the 80s on 8 and 16-bit machines,
including ones I'd designed and prototyped myself (with a couple of
thousand soldered wires on the back as this didn't use a pcb). I was
very, very familiar with my machine. AND I was using my own language. I
could do what I liked - and it worked.
>
> The C way to get this effect would be:
>
> ((void (*)(void)) 1234)();
Huh? This calls a function at address 1234; how is that relevant?
> You could, if you like, use:
>
> #define start asm volatile( "push dword 1234 ")
>
> But that is cheating a bit as C.
It's not C, and it's not portable.
> There may be a fair amount of similarities, but there is a fair amount
> of difference too. And you don't seem to grasp that /you/ need to
> understand and handle those differences
There aren't any, or shouldn't be. C has made it harder for no reason.
>> I'm not moaning that C doesn't do multiple return returns. I'm just
>> saying it's one of those things that can't easily be expressed in C, so
>> that a C target can only support a subset of the original language.
>>
>
> Of course it can easily be expressed in C.
'Easily'? No it can't, otherwise I would have done it. And you would see
C code using such a simple feature. The nearest you can get is for a
function to return one value: a struct.
As used in my language, for a function F returning 3 distinct scalar types:
F() # discard 3 return values
a := F() # use first, discard 2
(a, b[i]) := F() # use two, discard one
(a, b[i], c) : = F() # use all three
a, b and c don't need to match types exactly, provided each value can be
implicitly converted to match.
Further, inside F, a return statement could be 'return (x, y+1, z*2)'.
In C, as a struct, that requires compound literals. (My compiler doesn't
support those so I can't use that.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-10 16:17 +0200 |
| Message-ID | <qnnehn$9hj$1@dont-email.me> |
| In reply to | #146838 |
On 10/10/2019 15:41, Bart wrote:
> On 10/10/2019 13:24, David Brown wrote:
>> On 10/10/2019 12:57, Bart wrote:
>
>>> I don't have stack/unstack any more, but here it is in an old language:
>>>
>>> proc start=
>>> stack 1234
>>> end
>>>
>>> And here is the output:
>>>
>>> segment .text ;
>>> _start: ; ;
>>> L1: ; ;
>>> push dword 1234 ;
>>> retn ;
>>>
>>
>> And the use-case of this is... what? A new way to crash your software?
>
> Example 1:
>
> stack x # save old value
> ... code changes x
> unstack x # restore old value
>
> (Often when recursive functions were involved, x might have been a
> struct or array, and when x was global )
>
> Example 2:
>
> stack a, b
> unstack a, b
>
> This swaps a and b. (I used this before I had 'swap', sometimes like
> this (actual example from an old program):
>
> stack x; x:=y; unstack y
>
> Saves creating an explicitly named and typed temporary; would be great
> for a C macro, yes?)
In C, you'd have:
int oldX = x;
...
x = oldX;
(If you want to improve on C, you could copy the "typeof" extension from
gcc. But that would be unnecessary for generated C code, as you know
the type of "x".)
I can see you might want a "stack" and "unstack" facility if you are
making some kind of marginally portable assembler. But then you would
not be generated C code.
When generating C, you have neither the need for nor the desire to
manipulate the stack directly. If you want to have a temporary store,
you make a local variable for it - and the it is the C compiler that
decides if this is in a register, on the stack, or whatever.
>
> Example 3:
>
> stack x # x is an array of 3 ints (1st element on top)
> unstack a, b, c # store elements into 3 ints vars a, b and c
>
> (Here attention must be paid to stack granularity which was 32-bits for
> this language, and to match number of elements)
>
> Example 4:
>
> You have a generic function pointer fn, which you know takes N
> parameters from params[] (double-width params take two slots):
>
> for i:=N downto 1 do
> stack params[i]
> od
>
> fn() # calls as a function taking 0 params
>
> (This requires that the target uses a simple stack-based call
> convention, as my current ones do, otherwise it gets messier.)
>
> It is easy to think of applications FOR LOW LEVEL WORK.
All of this is straightforward to implement in C - once you forget the
idea that you have to store it on the stack directly, like in assembly.
>
> Bear in mind I starting using this in the 80s on 8 and 16-bit machines,
> including ones I'd designed and prototyped myself (with a couple of
> thousand soldered wires on the back as this didn't use a pcb). I was
> very, very familiar with my machine. AND I was using my own language. I
> could do what I liked - and it worked.
>
I can appreciate that you preferred to do things differently at that
time. But we are no longer in the 1980's.
>>
>> The C way to get this effect would be:
>>
>> ((void (*)(void)) 1234)();
>
> Huh? This calls a function at address 1234; how is that relevant?
Your assembly was:
push dword 1234
ret
Put 1234 on the stack, then pop it off and use it as the address for a jump.
>
>> You could, if you like, use:
>>
>> #define start asm volatile( "push dword 1234 ")
>>
>> But that is cheating a bit as C.
>
>
> It's not C, and it's not portable.
>
Agreed. You don't have access to the stack in portable C - C has no
concept of a stack. If, for some reason, you want direct access to the
stack, then you need to go outside of C. But you can do it in a simple
way like this, adjusted for whatever compiler you want to use.
>
>> There may be a fair amount of similarities, but there is a fair amount
>> of difference too. And you don't seem to grasp that /you/ need to
>> understand and handle those differences
>
> There aren't any, or shouldn't be. C has made it harder for no reason.
>
Are you really so arrogant as to think that /you/, alone, have found the
perfect semantics for a programming language - and that the C language
designers have got it all wrong?
>>> I'm not moaning that C doesn't do multiple return returns. I'm just
>>> saying it's one of those things that can't easily be expressed in C, so
>>> that a C target can only support a subset of the original language.
>>>
>>
>> Of course it can easily be expressed in C.
>
> 'Easily'? No it can't, otherwise I would have done it. And you would see
> C code using such a simple feature. The nearest you can get is for a
> function to return one value: a struct.
Yes, exactly - easy.
>
> As used in my language, for a function F returning 3 distinct scalar types:
>
> F() # discard 3 return values
> a := F() # use first, discard 2
> (a, b[i]) := F() # use two, discard one
> (a, b[i], c) : = F() # use all three
/You/ are generating the C code here.
typedef struct { int r1; int r2; int r3; } F_return;
F_return F(void) {
F_return ret;
ret.r1 = 1;
ret.r2 = 2;
ret.r3 = 3;
return ret;
}
int test1(void) {
F_return f = F();
int a = f.r1;
return a;
}
int test12(void) {
F_return f = F();
int a = f.r1;
int b = f.r2;
return a + b;
}
int test13(void) {
F_return f = F();
int a = f.r1;
int b = f.r2;
int c = f.r3;
return a + b + c;
}
There is, as I have always said, plenty of hard stuff in making your own
language and tools. This is not one of them.
>
> a, b and c don't need to match types exactly, provided each value can be
> implicitly converted to match.
>
> Further, inside F, a return statement could be 'return (x, y+1, z*2)'.
> In C, as a struct, that requires compound literals. (My compiler doesn't
> support those so I can't use that.)
>
First, you can't blame C for your own compiler's limitations - C handles
compound literals just fine.
Secondly, as shown above you don't need compound literals. You never
/need/ compound literals - they are just a convenience syntax.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 18:09 +0100 |
| Message-ID | <oBJnF.1081751$aI7.405200@fx22.am4> |
| In reply to | #146839 |
On 10/10/2019 15:17, David Brown wrote:
> On 10/10/2019 15:41, Bart wrote:
>> Example 4:
>>
>> You have a generic function pointer fn, which you know takes N
>> parameters from params[] (double-width params take two slots):
> All of this is straightforward to implement in C - once you forget the
> idea that you have to store it on the stack directly, like in assembly.
Example 4 is the sort of thing that is handled by the LIBFFI library
because it can't done in standard C.
> Are you really so arrogant as to think that /you/, alone, have found the
> perfect semantics for a programming language - and that the C language
> designers have got it all wrong?
I have simpler semantics. How are you getting on what that chart of 64
int combinations whether a binary op is done as signed or unsigned?
>> F() # discard 3 return values
>> a := F() # use first, discard 2
>> (a, b[i]) := F() # use two, discard one
>> (a, b[i], c) : = F() # use all three
>
> /You/ are generating the C code here.
>
> typedef struct { int r1; int r2; int r3; } F_return;
>
> F_return F(void) {
> F_return ret;
> ret.r1 = 1;
> ret.r2 = 2;
> ret.r3 = 3;
> return ret;
> }
>
> int test1(void) {
> F_return f = F();
> int a = f.r1;
> return a;
> }
>
> int test12(void) {
> F_return f = F();
> int a = f.r1;
> int b = f.r2;
> return a + b;
> }
>
> int test13(void) {
> F_return f = F();
> int a = f.r1;
> int b = f.r2;
> int c = f.r3;
> return a + b + c;
> }
>
> There is, as I have always said, plenty of hard stuff in making your own
> language and tools. This is not one of them.
Lots of fiddly code, and a new global table of structs.
Since I only used that new feature in two places, it was easier to spend
a few minutes changing the code to avoid it, then spend hours extending
the C translator (this feature is part of the general multiple
assignments which has very specific semantics).
I would rather spend that fixing this:
case p++^
when 'A' then
when 'B' then
which translates to:
if (*p++ == 'A') {}
else if (*p++ == 'B') {}
With different behaviour.
It ought to be easy, but it is easier still to avoid that pattern.
Result: downgrading of the original language.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-10 17:38 +0000 |
| Message-ID | <G0KnF.73882$iJ2.22766@fx47.iad> |
| In reply to | #146843 |
Bart <bc@freeuk.com> writes: >On 10/10/2019 15:17, David Brown wrote: >> On 10/10/2019 15:41, Bart wrote: >> Are you really so arrogant as to think that /you/, alone, have found the >> perfect semantics for a programming language - and that the C language >> designers have got it all wrong? > >I have simpler semantics. How many programmers, other than yourself, use your language for production projects?
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-10 01:37 -0700 |
| Message-ID | <65b3e46e-3d3e-4a4b-8e5d-7bcc908019b6@googlegroups.com> |
| In reply to | #146826 |
On Thursday, October 10, 2019 at 3:03:32 AM UTC+3, Anton Shepelev wrote:
> Bart:
>
> > My language comes first (its first crude version was about
> > a dozen years before I tried C).
>
> Naturally: you design your language and then translate it
> into C.
>
> > It already has plenty of things that don't yet/never will
> > translate to C so I can't use those features if the result
> > must be portable.
>
> Why not, because it is too much work? Anything can be
> translated into C: C++, Lua, Python, and BartLang.
>
> > > > The language supports 8/16/32/64/128-bit data types
> > > > but the default 'int' size is 64 bits, and
> > > > calculations are done at at least 64 bits.
> > >
> > > Then I should say it is tie.
> >
> > You can say pretty much the same about C, for typical
> > desktop implementations:
> >
> > "The C language supports 8/16/32/64-bit data types but the
> > default 'int' size is 32 bits, and calculations are done
> > at at least 32 bits."
>
> I was comparing the languages, not their implementations.
> The primary types of your language are hardware-bound. The
> primary types of the C language are not, so that
> implementations are free to choose whatever native types are
> available on the platform, or even to provide software-based
> types unavailable natively. As far as I understand, nothing
> stands in the way of implementing for the 32-bit x86 patform
> some "Extended-range C compiler" where `int' is 256 bits and
> `long int' 512! That is the power of abstract types.
>
I think, your understanding is wrong.
C standards and pre-standard books define 'int' as the most efficient signed integer type on a given machine. At some point it was changed to the most efficient signed integer type with at least 15 bits of magnitude.
So, on IA-32 platform 256-bit int would be clearly non-standard.
The choice on this platform is really only between 16-bit and 32-bit. Historically there were IA-32 CPUs on which 16-bit was significantly faster (386SX and its embedded derivative 386EX) and there were platforms on which 32-bit was significantly faster (Pentium Pro), but on majority of IA-32 CPUs neither is clearly faster than the other.
> > Range types: I don't like elaborate type systems, and
> > things like this, done properly, always end up with type
> > systems like Ada's.
>
> I meant not range types but a facility that can pick a
> native type sufficient for storing a certain value. It is a
> parametrised generalisation of the `int_least*' family of
> types in C. I think it better to provide a couple of
> predicates than to keep adding fixed types, e.g.:
>
> Type(int, 8, least) for int_least8_t, &c
>
> > I don't find these long, short, long long etc useful,
> > especially when the language doesn't specify the default
> > int size, and neither when does it specify what affect
> > each 'long' has on that.
>
> Well, the Netpbm setup utility makes good use of them. It
> compiles a series of test programs to determine the exact
> sizes of the basic types and adjusts the build parameters
> accordingly.
>
> > If these types were used in an API to be used as a foreign
> > function library from other languages, then you'd see the
> > problem.
>
> Such an API can use the fixed-with types, either defined in
> its own header or in inttypes.h.
>
> > What happens is that if I used the equivalent of
> > 'sizeof(void*)', that gets hard-coded in the C as either
> > "4" or "8". Once that happens, C source containing "4"
> > must use a C compiler with 32-bit pointers, not 64, and
> > similar for "8".
>
> Understood -- you have to know the sizes of abstract C types
> if you want to use them. But can you generate code with
> sizeof(), postponing its expansion till the stage where the
> generated C is compiled?
>
> You can write a single feature-test program in C that will
> gather and print all the platform- and implementaiton-
> specific information needed for your transpiler. If you
> write it in standard C, the program shall work with any C
> compiler and require no maintenance.
>
> > > How's about a wrapper:
> > >
> > > #include <stdio.h>
> > > #include <string.h>
> > >
> > > static int bstrlen( unsigned char const *s )
> > > { return strlen( ( const char * )s ); }
> > >
> > > int main( int argc, char** argv )
> > > { printf("%i\n", bstrlen( (unsigned char * )"Hi, Bart!" ) );
> > > return 0;
> > > }
> > Written in C or original language?
>
> My example is obviously a C program.
>
> > If in C, then it means there is now a dependency on an
> > actual C module (written in C, not generated), separate
> > from the main language.
>
> You can hardcode this wrapper for a standard function into
> your tool and forget about it, because standard C is very
> unlikely ever to break. A neat C unit with wrappers for
> standard functions and the implementations, as functions or
> macros, of operators present in your language and absent
> from C seems an excellent idea. It is not so much a
> dependency but a necessary stage of translating one language
> into another. An alternative solution is to teach your
> generator to convert the pointers on-the-fly.
>
> > My aim is to have as few dependencies as possible.
>
> The only dependency in your C generator will be on the C
> language, but that one is unavoidable, exacty as knowledge
> of Frech is for a English-to-French translator. Your tool
> must be "aware" of C in some way or other in order to
> generate it, no? Hardcoded wrappers for standard functions
> are just a way to store that knowledge of C in the
> generator. The modules shall not change unless the language
> itself receives a change that breaks backward compatibility.
>
> > The real problem here is C's abstract 'char' type is a
> > poor choice for a language neutral API.
>
> True, but you have to deal with it rather than thrust
> incompatible types down C's throat.
>
> > It needs to be a concrete type, and ideally not signed
> > either. (What sense is there in a signed char type
> > anyway?)
>
> Therefore, a transpiler shall *implement* the types of the
> source language in terms of the target language. In the
> general case, it involves a process called (de)serialisation
> or marshalling, in which the data of a source type is
> recomposed on a binary level to get a correct representation
> of the target type.
>
> > > What about the future generations of users and
> > > maintainers of your tools? Whereas the standard is set
> > > in stone, the C dialect that a set of currenly
> > > maintained compilers happen to accept by default is
> > > subject to change!
> >
> > My C is code is fairly conservative and uses few features.
>
> Yet very liberal in that it relies on compiler-specific
> relaxations of C among those few features.
>
> --
> () ascii ribbon campaign -- against html e-mail
> /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
Page 3 of 25 — ← Prev page 1 2 [3] 4 5 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web