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 8 of 25 — ← Prev page 1 … 6 7 [8] 9 10 … 25 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 14:36 +0100 |
| Message-ID | <DpZqF.342383$3C5.95940@fx01.am4> |
| In reply to | #147107 |
On 20/10/2019 13:39, David Brown wrote: > On 19/10/2019 15:05, Bart wrote: >> Then defining a struct to match a specific layout becomes pretty much >> impossible, and you have to use unwieldy and costly (in programmer >> time) alternatives. > > Yes - now you are beginning to understand. > > C - the standard - does not have any facilities for defining a struct to > match a specific layout. Many aspects of a struct's representation is > implementation dependent, such as the sizes of the fields, the > alignments, the padding, the endianness. That's a shortcoming then in a purportedly low-level language. Although it is less important in C as the struct on the other side of an interface that you have to match will likely be defined in C too. My job is a bit harder and I need that extra ability. > When you have to match an external format, you have three choices. > Or you can write compiler and target specific code, that only works on > the platforms you need, and can rely on assumptions about the compiler > and target because these are fixed. It can use compiler extensions like > "packed" pragmas or attributes. Compile-time checks and static > assertions can ensure that the code fails to compile on other targets. > I suppose there is a third method What makes you think I don't use that second method? - write non-portable code in a > thoughtless, ignorant and lazy way and just hope it works. Or you can just write non-portable code in a thoughtful and knowledgeable way (I have been doing this stuff for 40 years after all). > Rather than using "pack", I much prefer to put any padding in manually. (I can't not use pack(1) in generated code as I can't be sure the original source has laid out any structs in a way that would exactly match C's. The original is effectively pack(1), the C version must be as as well.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 16:47 +0200 |
| Message-ID | <qohs27$cml$1@dont-email.me> |
| In reply to | #147114 |
On 20/10/2019 15:36, Bart wrote: > On 20/10/2019 13:39, David Brown wrote: >> On 19/10/2019 15:05, Bart wrote: > >>> Then defining a struct to match a specific layout becomes pretty much >>> impossible, and you have to use unwieldy and costly (in programmer >>> time) alternatives. >> >> Yes - now you are beginning to understand. >> >> C - the standard - does not have any facilities for defining a struct >> to match a specific layout. Many aspects of a struct's representation >> is implementation dependent, such as the sizes of the fields, the >> alignments, the padding, the endianness. > > That's a shortcoming then in a purportedly low-level language. C is a high level programming language - meaning it is defined in terms of an abstract machine, rather than in terms of a particular implementation, processor, or fixed representation. But it is a language that can be used for target and implementation-specific low-level coding as well as portable high level coding. Doing so relies on the implementation details. That's fine, of course. It is the second solution on my list. > > Although it is less important in C as the struct on the other side of an > interface that you have to match will likely be defined in C too. The only full guarantee you have for compatibility is when you are dealing with code from the same C compiler on the same target. On most platforms (Windows, as usual, being the exception) there are well-defined ABI's which C compilers and compilers for other languages conform to. As long as that is the case, and you stick to feature subsets that are available in the languages you use, you can easily coordinate and cross-call between compiled languages and tools on the platform. It doesn't matter if C is one of the languages, or if you are talking about Fortran, Ada and Ocaml. C is often used as the language to describe these ABI's, simply because it is such a well-known language. But the C standards don't define the ABI, and ABI's are not consistent across platforms and processors. > > My job is a bit harder and I need that extra ability. > > > >> When you have to match an external format, you have three choices. > >> Or you can write compiler and target specific code, that only works on >> the platforms you need, and can rely on assumptions about the compiler >> and target because these are fixed. It can use compiler extensions >> like "packed" pragmas or attributes. Compile-time checks and static >> assertions can ensure that the code fails to compile on other targets. > >> I suppose there is a third method > > What makes you think I don't use that second method? I didn't see any static assertions, compile-time checks, or other indications that you made the slightest effort to document or enforce the assumptions you make. You didn't use appropriate fixed-size integer types, which would have been fine for the purpose. You didn't even add a comment. > > - write non-portable code in a >> thoughtless, ignorant and lazy way and just hope it works. > > Or you can just write non-portable code in a thoughtful and > knowledgeable way (I have been doing this stuff for 40 years after all). If you had thought, you would have written it better. > >> Rather than using "pack", I much prefer to put any padding in manually. > > (I can't not use pack(1) in generated code as I can't be sure the > original source has laid out any structs in a way that would exactly > match C's. The original is effectively pack(1), the C version must be as > as well.) Since there is no standard definition of what "pack" means, it's hard to say if it matched the specification document. As far as I can see, the documented structures don't need any padding or unaligned accesses, but they do have sizes that are not multiples of the maximum alignments. I can't say if that would be dealt with by any given compiler's "pack" extension.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 19:16 +0100 |
| Message-ID | <ow1rF.1784225$HWr.954770@fx36.am4> |
| In reply to | #147120 |
On 20/10/2019 15:47, David Brown wrote:
> On 20/10/2019 15:36, Bart wrote:
> C is a high level programming language - meaning it is defined in terms
> of an abstract machine, rather than in terms of a particular
> implementation, processor, or fixed representation.
This is where my idea of how a /systems/ language should work differs.
It can hide hardware details where possible, but allow use of them when
necessary. And do so unequivocally.
> But it is a language that can be used for target and
> implementation-specific low-level coding as well as portable high level
> coding. Doing so relies on the implementation details. That's fine, of
> course. It is the second solution on my list.
You get the feeling this stuff doesn't come naturally to it (How long
did it take to acquire fixed width types? I could that in 1970s Fortran ).
>> What makes you think I don't use that second method?
>
> I didn't see any static assertions, compile-time checks, or other
> indications that you made the slightest effort to document or enforce
> the assumptions you make. You didn't use appropriate fixed-size integer
> types, which would have been fine for the purpose. You didn't even add
> a comment.
In which code didn't I do all that? I don't remember posting anything
other than a contrived 3-line C fragment. On the other hand, all my
generated C files start a little like this (all auto-generated):
/*
M to C Whole Program Translator
Input: hello.m plus imported modules
Output: hello.c (this file, or renamed from that)
File represents entire program
Target: C 64-bit
OS: Windows
Modules:
Module 1: hello.m
....
*********** Start of C Code **********/
#include <stdio.h>
...
#pragma pack(1)
typedef int8_t i8;
typedef int16_t i16;
typedef int32_t i32;
typedef int64_t i64;
typedef uint8_t u8;
typedef uint16_t u16;
typedef uint32_t u32;
typedef uint64_t u64;
#if (UINTPTR_MAX<0xFFFFFFFFFFFFFFFF)
#error "Need 64-bit target. Try -m64"
#endif
...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 21:37 +0200 |
| Message-ID | <qoid13$ad7$1@dont-email.me> |
| In reply to | #147122 |
On 20/10/2019 20:16, Bart wrote: > On 20/10/2019 15:47, David Brown wrote: >> On 20/10/2019 15:36, Bart wrote: > >> C is a high level programming language - meaning it is defined in >> terms of an abstract machine, rather than in terms of a particular >> implementation, processor, or fixed representation. > > This is where my idea of how a /systems/ language should work differs. > It can hide hardware details where possible, but allow use of them when > necessary. And do so unequivocally. gcc C targeting x86-64 can be used as a systems language. Keil's ARM compiler targeting 32-bit Cortex-M microcontrollers can be used as a systems language. Green Hills C compiler targeting bare-bones 64-bit PPC can be used as a systems language. IAR's C compiler targeting 8-bit AVR processors can be used as a systems language. Any particular implementation of C has solid rules for the sizes of types, padding, alignment, endianness, etc. You can write code for that particular implementation, using those assumptions, using extensions and compiler features, and write code as low level as you want. It is only at the higher level, using portable standard C, that you don't have that control. I fail completely to see how your idea of a "systems language" is any improvement on C, given that there is one implementation for one (or is it now two?) targets with similar features. > >> But it is a language that can be used for target and >> implementation-specific low-level coding as well as portable high >> level coding. Doing so relies on the implementation details. That's >> fine, of course. It is the second solution on my list. > > You get the feeling this stuff doesn't come naturally to it (How long > did it take to acquire fixed width types? I could that in 1970s Fortran ). I can't answer for what feelings /you/ get - please don't assume the feelings other people get. > > >>> What makes you think I don't use that second method? >> >> I didn't see any static assertions, compile-time checks, or other >> indications that you made the slightest effort to document or enforce >> the assumptions you make. You didn't use appropriate fixed-size >> integer types, which would have been fine for the purpose. You didn't >> even add a comment. > > In which code didn't I do all that? I don't remember posting anything > other than a contrived 3-line C fragment. On the other hand, all my > generated C files start a little like this (all auto-generated): You posted a snippet of C code, which was commented upon. > > /* > M to C Whole Program Translator > Input: hello.m plus imported modules > Output: hello.c (this file, or renamed from that) > File represents entire program > Target: C 64-bit > OS: Windows > > Modules: > Module 1: hello.m > .... > > *********** Start of C Code **********/ > > #include <stdio.h> > ... I assume "..." includes <stdint.h> or <inttypes.h> > > #pragma pack(1) > > typedef int8_t i8; > typedef int16_t i16; > typedef int32_t i32; > typedef int64_t i64; > > typedef uint8_t u8; > typedef uint16_t u16; > typedef uint32_t u32; > typedef uint64_t u64; > > #if (UINTPTR_MAX<0xFFFFFFFFFFFFFFFF) > #error "Need 64-bit target. Try -m64" > #endif > > ...
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-20 09:54 -0400 |
| Message-ID | <mGZqF.284202$iJ2.3104@fx47.iad> |
| In reply to | #147075 |
On 10/19/19 9:05 AM, Bart wrote:
> On 19/10/2019 13:44, Richard Damon wrote:
>> On 10/19/19 6:16 AM, Bart wrote:
>>> On 19/10/2019 01:19, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>
>>>> (Note: the context for "such code" has been lost: you added more
>>>> problems by suggesting a C struct could be used.)
>>>
>>> For this job, structs are used too. Example (generated version but the
>>> original also uses fixed-width types):
>>>
>>> struct coffrelocrec {
>>> i32 virtualaddr;
>>> i32 stindex;
>>> i16 reloctype;
>>> };
>>>
>>> (Notice this last has a size of 10 bytes when summing the individual
>>> fields, but in C has an overall size of 12 bytes.)
>>
>> WRONG. The C standard does NOT define the size of that struct (it
>> provides some rules for what are allowable values). Possible values for
>> the size that I can think if (if i16 is int_least16_t) would be: 3, 5,
>> 6, 10, 12, and even 24.
>
> Then defining a struct to match a specific layout becomes pretty much
> impossible, and you have to use unwieldy and costly (in programmer time)
> alternatives.
Yes, making a struct exactly match a specific external layout is not
something supported in Standard C (for use in something like a file or
network packet spec).
>
> Sometimes you HAVE to make some assumptions, eg. that char is one 8-bit
> byte; i16 is 2 bytes; i32 is 4; there are no padding bits and no padding
> bytes, and that pack(1) can be used to ensure no struct padding.
You never HAVE to make those assumptions, though sometimes it is handy.
You can be certain that char and uint8_t will have sizeof() == 1.
uint16_t will always have 16 bits (and thus 2 octets) and if uint8_t
exists, sizeof(uint16_t) == 2. If your implementation provides a pack
like GCC does, then you have an implementation specific way to make the
exact structure.
>
> But according to Ben, such a program would be incorrec. Well he can try
> explaining to my boss why my program is taking so much longer to write
> and is so convoluted! And full of new, more obscure bugs.
Typically, what I do is have a C struct in memory (with a similar but
maybe not exactly identical layout) and to write the struct to the file,
use a function to send it (rather than just a call to fwrite) and that
function either writes out data to the file with lower level calls (like
a self built fwrite16le function, or use a similar set of primitives to
fill a byte exact buffer that can be all sent with a single fwrite or
similar.
>
>>> (My own attempts to create a 64-bit-int C compiler ran into trouble
>>> because the binary C library it uses, still uses 32-bit ints, requiring
>>> a new set of standard headers for a start, as 'int' is used everywhere.)
>>
>> i.e., you were making a C compiler but didn't want to do the full job.
>
> Not just to test to test my assertion that many C projects would stop
> working. Although I might try again soon; it would still be simpler than
> going for a 16-bit int, as that involves extensive code-gen changes when
> the result must still run on x64).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-19 13:24 +0200 |
| Message-ID | <qoerq3$n5m$1@dont-email.me> |
| In reply to | #147049 |
On 19/10/2019 00:06, Bart wrote: > On 18/10/2019 16:44, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> This was overlooked since a 32-bit int is so widespread it can be >>> assumed. >> >> It can assumed only at the expense of errors. You led me astray as to >> what the problem was by saying that it occurs when int is 64 bits. > > The buffer overflow occurs when int is 64 bits. > > > No, >> the problem was already there, /even when the code was working/. If I >> were teaching C, this is a point I'd hammer home every day. >> >> The code assigns an int when that is not what is intended. You should >> try, as best you can, to write what is meant, not what works on this >> system on this machine with this compiler release. > > Here's an example of a COFF description: > > http://www.ti.com/lit/an/spraao8/spraao8.pdf > > Notice the type of most fields is one of Char, Short, and Long, used for > fields of 1, 2 and 4 bytes, which are begging to be represented in a C > struct as char, short and long. Sometimes the field types are called "Character" or "Integer" too. The fields have fixed sizes. The obvious C types to use would be the fixed size types - int8_t, uint16_t, etc. Apply two seconds of thought, rather than one second, and you'd reach the same conclusion. (You might call them i8, u16, etc., but the principle is the same.) Apply three seconds of thought and you'd want to do extra checks for alignments - as far as I can see from the document, the fields are "naturally" aligned, which is fine on almost all C platforms. I think it will take more thought, and some research (unless someone here knows the answer), to tell if the fields are stored in big-endian or little-endian format (this can be independent of the COFF target endianness). That will also be vital if you want to write a portable COFF handler. > > And most of the time it will work, unless the code is compiled on > Linux64 where long is 8 bytes. > > The point is it is very easy to use just a standard, non-fixed-width type. Easy, but wrong. I have always viewed the job of the programmer is to understand the problem, then start designing a solution, then start coding. Glancing briefly at the problem, guessing a lazy idea and then bashing it into the computer is not programming in my book.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-19 13:40 +0100 |
| Message-ID | <5vDqF.1358676$i14.425769@fx27.am4> |
| In reply to | #147069 |
On 19/10/2019 12:24, David Brown wrote: > On 19/10/2019 00:06, Bart wrote: >> http://www.ti.com/lit/an/spraao8/spraao8.pdf >> >> Notice the type of most fields is one of Char, Short, and Long, used >> for fields of 1, 2 and 4 bytes, which are begging to be represented in >> a C struct as char, short and long. > > Sometimes the field types are called "Character" or "Integer" too. Character is used for short character arrays. Integer for 4-byte signed integers, the same as Long. It's not clear why one such field is Integer, and the other Long. > The fields have fixed sizes. The obvious C types to use would be the > fixed size types - int8_t, uint16_t, etc. Yet it uses the C-like terms 'Char' (mainly for small integers), 'Short' and 'Long'. Why is that even necessary? Sometimes Short and Long have an 'Unsigned' prefix, indicating those are normally signed, just like C. An MS document describing the same format doesn't apply types to the fields at all; only offsets and sizes. >> The point is it is very easy to use just a standard, non-fixed-width >> type. > > Easy, but wrong. > > I have always viewed the job of the programmer is to understand the > problem, then start designing a solution, then start coding. Glancing > briefly at the problem, guessing a lazy idea and then bashing it into > the computer is not programming in my book. The problem in this case was identifying a program that was useless for my purposes (Nasm), and writing one (an assembler for which this is part) that did a far better job (ie. some 1000 times faster for my inputs, no exaggeration). If you think that is not programming, then that is your opinion. I'm the one now with an assembler that can effortlessly handle millions of lines per second. One like Nasm may be written in perfect, portable C (although I wonder if will pass with int=64 bits), but is hopelessly slow and impractical for data. So my program had one bug because I assumed int = 32 bits. How many C programs assume exactly the same. I certainly see plain 'int' used everywhere. The reason for the subthread was to provide a counter-example to the suggestion that switching to a wider int (64 bits) was harmless, compared to going to a narrower one. People are trying to say that it shouldn't matter if software has no bugs and makes no suggestions. Sure. But back in the real world, it does, and those affect portability.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-19 13:13 -0700 |
| Message-ID | <lnk190ebnq.fsf@kst-u.example.com> |
| In reply to | #147071 |
Bart <bc@freeuk.com> writes:
> On 19/10/2019 12:24, David Brown wrote:
>> On 19/10/2019 00:06, Bart wrote:
>>> http://www.ti.com/lit/an/spraao8/spraao8.pdf
>>>
>>> Notice the type of most fields is one of Char, Short, and Long, used
>>> for fields of 1, 2 and 4 bytes, which are begging to be represented in
>>> a C struct as char, short and long.
>>
>> Sometimes the field types are called "Character" or "Integer" too.
>
> Character is used for short character arrays. Integer for 4-byte signed
> integers, the same as Long. It's not clear why one such field is
> Integer, and the other Long.
The type name "Integer" is used in only one table, "File Header
Contents". All the other layout tables consistently use "Short" or
"Unsigned short" for 2-byte fields, and "Long" or "Unsigned long" for
4-byte fields, with footnotes saying "For C6000 the type is integer".
Note that C has no type named "Integer" or "integer". The document
doesn't refer to C types.
The tables show the byte range for each field, so the sizes are
unambiguous.
The fact that this particular document was sloppily written says
nothing about C.
You cannot portably define a C structure that exactly matches the
22-byte layout of the file header, for example (2 16-bit unsigned
integers, 3 32-bit signed integers, 3 16-bit unsigned integers).
That doesn't make it particularly difficult to write C code that
deals with files containing such headers. You just have to be able to
figure out that "Unsigned long" doesn't necessarily refer to C's
"unsigned long" type.
[...]
--
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 | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-19 13:57 -0700 |
| Message-ID | <79bd4ee3-1c54-4ea7-8227-a45c210de8c2@googlegroups.com> |
| In reply to | #147088 |
On Saturday, October 19, 2019 at 11:13:54 PM UTC+3, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> > On 19/10/2019 12:24, David Brown wrote:
> >> On 19/10/2019 00:06, Bart wrote:
> >>> http://www.ti.com/lit/an/spraao8/spraao8.pdf
> >>>
> >>> Notice the type of most fields is one of Char, Short, and Long, used
> >>> for fields of 1, 2 and 4 bytes, which are begging to be represented in
> >>> a C struct as char, short and long.
> >>
> >> Sometimes the field types are called "Character" or "Integer" too.
> >
> > Character is used for short character arrays. Integer for 4-byte signed
> > integers, the same as Long. It's not clear why one such field is
> > Integer, and the other Long.
>
> The type name "Integer" is used in only one table, "File Header
> Contents". All the other layout tables consistently use "Short" or
> "Unsigned short" for 2-byte fields, and "Long" or "Unsigned long" for
> 4-byte fields, with footnotes saying "For C6000 the type is integer".
>
> Note that C has no type named "Integer" or "integer". The document
> doesn't refer to C types.
>
> The tables show the byte range for each field, so the sizes are
> unambiguous.
>
> The fact that this particular document was sloppily written says
> nothing about C.
>
> You cannot portably define a C structure that exactly matches the
> 22-byte layout of the file header, for example (2 16-bit unsigned
> integers, 3 32-bit signed integers, 3 16-bit unsigned integers).
> That doesn't make it particularly difficult to write C code that
> deals with files containing such headers.
If you want it *to run* on C6000 then it's certainly requires non-trivial expertise.
But, hopefully, that's wasn't what Bart wanted.
> You just have to be able to
> figure out that "Unsigned long" doesn't necessarily refer to C's
> "unsigned long" type.
>
> [...]
>
> --
> 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-20 15:04 +0200 |
| Message-ID | <qohm1k$n0v$1@dont-email.me> |
| In reply to | #147071 |
On 19/10/2019 14:40, Bart wrote: > On 19/10/2019 12:24, David Brown wrote: >> On 19/10/2019 00:06, Bart wrote: > >>> http://www.ti.com/lit/an/spraao8/spraao8.pdf >>> >>> Notice the type of most fields is one of Char, Short, and Long, used >>> for fields of 1, 2 and 4 bytes, which are begging to be represented >>> in a C struct as char, short and long. >> >> Sometimes the field types are called "Character" or "Integer" too. > > Character is used for short character arrays. Integer for 4-byte signed > integers, the same as Long. It's not clear why one such field is > Integer, and the other Long. > Exactly. That is why I disagree with you that the document is "begging to be represented in a C struct as char, short and long". It does not specify the fields properly in C terms. >> The fields have fixed sizes. The obvious C types to use would be the >> fixed size types - int8_t, uint16_t, etc. > > Yet it uses the C-like terms 'Char' (mainly for small integers), 'Short' > and 'Long'. Why is that even necessary? Ask the people who wrote the document. It looks like they might expect readers to be familiar with C, and use that as a short-cut to giving more details of the types. Certainly the actual types and sizes in the document are entirely obvious to me - but equally, it is obvious to me that these are not portable C types. So when I read that document and see they have a 4-byte type called "Long", I know the C type to use is "int32_t" (/if/ alignment and endianness match). > > Sometimes Short and Long have an 'Unsigned' prefix, indicating those are > normally signed, just like C. > > An MS document describing the same format doesn't apply types to the > fields at all; only offsets and sizes. > That's another way to do it. Or it could be given with "integer" as the type and different sizes, or "WORD", "DWORD", etc. All that matters in a specification like this is that it is clear what the sizes and offsets are - it is up to the implementer to translate these into types in the language they are using. >>> The point is it is very easy to use just a standard, non-fixed-width >>> type. >> >> Easy, but wrong. >> >> I have always viewed the job of the programmer is to understand the >> problem, then start designing a solution, then start coding. Glancing >> briefly at the problem, guessing a lazy idea and then bashing it into >> the computer is not programming in my book. > > The problem in this case was identifying a program that was useless for > my purposes (Nasm), and writing one (an assembler for which this is > part) that did a far better job (ie. some 1000 times faster for my > inputs, no exaggeration). > I really hope you were not using the documentation for outdated file formats for TI's DSP devices for writing an assembler for Windows. > If you think that is not programming, then that is your opinion. The process you described, and the snippet of code you showed, is not good programming IMHO. > I'm the > one now with an assembler that can effortlessly handle millions of lines > per second. Writing fast programs is easy. Writing /correct/ programs is hard. I have no idea if your assembler is a good program or not - that would require looking at the detailed specifications for the program and the implementation code. Maybe it is a perfectly good program - maybe not. All I can say is that the speed of chewing through a million lines of code is utterly meaningless in comparison to correctness, and thus it is pointless to boast about it. > > One like Nasm may be written in perfect, portable C (although I wonder > if will pass with int=64 bits), but is hopelessly slow and impractical > for data. No one is suggesting that code always has to be portable. But it is a bit silly to write code that /unnecessarily/ makes assumptions and is non-portable when writing a more portable version is clearer and has no cost in efficiency or coding effort. > > So my program had one bug because I assumed int = 32 bits. How many C > programs assume exactly the same. I certainly see plain 'int' used > everywhere. Ah, you think it's fine for you to write poorer quality code because other people do so? I don't subscribe to that policy myself. > > The reason for the subthread was to provide a counter-example to the > suggestion that switching to a wider int (64 bits) was harmless, > compared to going to a narrower one. > > People are trying to say that it shouldn't matter if software has no > bugs and makes no suggestions. > > Sure. But back in the real world, it does, and those affect portability. > We all know that a great deal of code has bugs in it, or is poorly written, or has undocumented and unwarranted assumptions. (And as has been discussed, we also all know that sometimes this can happen for good reasons - code quality is not always the top priority.) That does not mean we should just lie back and say "Sure the code is bad - but so what? Other people write bad code too".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-20 06:21 -0700 |
| Message-ID | <3f9f7547-d66e-4da8-ab08-b305bfeade21@googlegroups.com> |
| In reply to | #147109 |
On Sunday, 20 October 2019 14:05:01 UTC+1, David Brown wrote: > > Writing fast programs is easy. Writing /correct/ programs is hard. I > have no idea if your assembler is a good program or not - that would > require looking at the detailed specifications for the program and the > implementation code. Maybe it is a perfectly good program - maybe not. > All I can say is that the speed of chewing through a million lines of > code is utterly meaningless in comparison to correctness, and thus it is > pointless to boast about it. > Often a fast and approximate answer is better than an exact one that is slow. If you ask, "What is an employee's average salary?", then the immediate answer, "Oh, about 25,000" is probably more useful than the person going to the database, writing a little script, then coming back with "25,125.45" a hour later.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 15:40 +0200 |
| Message-ID | <qoho4r$v3b$1@dont-email.me> |
| In reply to | #147112 |
On 20/10/2019 15:21, Malcolm McLean wrote: > On Sunday, 20 October 2019 14:05:01 UTC+1, David Brown wrote: >> >> Writing fast programs is easy. Writing /correct/ programs is hard. I >> have no idea if your assembler is a good program or not - that would >> require looking at the detailed specifications for the program and the >> implementation code. Maybe it is a perfectly good program - maybe not. >> All I can say is that the speed of chewing through a million lines of >> code is utterly meaningless in comparison to correctness, and thus it is >> pointless to boast about it. >> > Often a fast and approximate answer is better than an exact one > that is slow. If you ask, "What is an employee's average salary?", then > the immediate answer, "Oh, about 25,000" is probably more useful > than the person going to the database, writing a little script, then > coming back with "25,125.45" a hour later. > An approximate answer is acceptable if an approximate answer is all that is required by the specification of the problem. (And sometimes - nay, often - specifications are not as clear as they could be. That's another issue.) If an approximate answer is fine as an answer, then it will be a correct answer. If it is not acceptable, then it is not a correct answer - and it doesn't become "correct" by being calculated quickly. Correctness /always/ trumps speed.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-20 07:29 -0700 |
| Message-ID | <6a62b53b-2437-41c2-9b03-f96178347063@googlegroups.com> |
| In reply to | #147116 |
On Sunday, 20 October 2019 14:40:51 UTC+1, David Brown wrote: > On 20/10/2019 15:21, Malcolm McLean wrote: > > On Sunday, 20 October 2019 14:05:01 UTC+1, David Brown wrote: > >> > >> Writing fast programs is easy. Writing /correct/ programs is hard. I > >> have no idea if your assembler is a good program or not - that would > >> require looking at the detailed specifications for the program and the > >> implementation code. Maybe it is a perfectly good program - maybe not. > >> All I can say is that the speed of chewing through a million lines of > >> code is utterly meaningless in comparison to correctness, and thus it is > >> pointless to boast about it. > >> > > Often a fast and approximate answer is better than an exact one > > that is slow. If you ask, "What is an employee's average salary?", then > > the immediate answer, "Oh, about 25,000" is probably more useful > > than the person going to the database, writing a little script, then > > coming back with "25,125.45" a hour later. > > > > An approximate answer is acceptable if an approximate answer is all that > is required by the specification of the problem. (And sometimes - nay, > often - specifications are not as clear as they could be. That's > another issue.) > > If an approximate answer is fine as an answer, then it will be a correct > answer. If it is not acceptable, then it is not a correct answer - and > it doesn't become "correct" by being calculated quickly. > > Correctness /always/ trumps speed. > It's often better to be interactive but occasionally wrong than not interactive at all. If it doesn't work, just try again with a slightly different input.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 16:49 +0200 |
| Message-ID | <qohs5i$cml$2@dont-email.me> |
| In reply to | #147119 |
On 20/10/2019 16:29, Malcolm McLean wrote: > On Sunday, 20 October 2019 14:40:51 UTC+1, David Brown wrote: >> On 20/10/2019 15:21, Malcolm McLean wrote: >>> On Sunday, 20 October 2019 14:05:01 UTC+1, David Brown wrote: >>>> >>>> Writing fast programs is easy. Writing /correct/ programs is hard. I >>>> have no idea if your assembler is a good program or not - that would >>>> require looking at the detailed specifications for the program and the >>>> implementation code. Maybe it is a perfectly good program - maybe not. >>>> All I can say is that the speed of chewing through a million lines of >>>> code is utterly meaningless in comparison to correctness, and thus it is >>>> pointless to boast about it. >>>> >>> Often a fast and approximate answer is better than an exact one >>> that is slow. If you ask, "What is an employee's average salary?", then >>> the immediate answer, "Oh, about 25,000" is probably more useful >>> than the person going to the database, writing a little script, then >>> coming back with "25,125.45" a hour later. >>> >> >> An approximate answer is acceptable if an approximate answer is all that >> is required by the specification of the problem. (And sometimes - nay, >> often - specifications are not as clear as they could be. That's >> another issue.) >> >> If an approximate answer is fine as an answer, then it will be a correct >> answer. If it is not acceptable, then it is not a correct answer - and >> it doesn't become "correct" by being calculated quickly. >> >> Correctness /always/ trumps speed. >> > It's often better to be interactive but occasionally wrong than not > interactive at all. If it doesn't work, just try again with a slightly > different input. > No one was discussing interactive behaviour. You are not just moving the goalposts, you are picking a completely different game.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 15:10 +0100 |
| Message-ID | <fVZqF.882871$aq7.562239@fx09.am4> |
| In reply to | #147109 |
On 20/10/2019 14:04, David Brown wrote:
> On 19/10/2019 14:40, Bart wrote:
>> The problem in this case was identifying a program that was useless
>> for my purposes (Nasm), and writing one (an assembler for which this
>> is part) that did a far better job (ie. some 1000 times faster for my
>> inputs, no exaggeration).
>>
>
> I really hope you were not using the documentation for outdated file
> formats for TI's DSP devices for writing an assembler for Windows.
I used modern docs as I need 64-bit formats, but most docs are terrible,
and that particular file format (which unwisely tries to conflate OBJ
and EXE formats) is a nightmare.
>> If you think that is not programming, then that is your opinion.
>
> The process you described, and the snippet of code you showed, is not
> good programming IMHO.
Judge for yourself; here is the obj-generating module (little used now
as I mainly use .exe):
https://github.com/sal55/qx/blob/master/ax_writeobj.m
And the exact-layout structs used:
https://github.com/sal55/qx/blob/master/ax_objdecls.m
('proc writestringtable was the one with the bug. This code is not C as
should be obvious.)
> Writing fast programs is easy. Writing /correct/ programs is hard. I
> have no idea if your assembler is a good program or not - that would
> require looking at the detailed specifications for the program and the
> implementation code. Maybe it is a perfectly good program - maybe not.
> All I can say is that the speed of chewing through a million lines of
> code is utterly meaningless in comparison to correctness, and thus it is
> pointless to boast about it.
Here the speed IS important. The original Nasm backend could easily take
1 or 2 minutes to process ASM that took 100msec to generate. YOU might
be willing to wait that long; I'm not. For a long time it was a big
obstacle to being able to write a viable whole-project compiler.
And OBJ/EXE files, full of x64 machine code, are VERY unforgiving of
errors. If a resulting EXE crashes, it will ultimately be for reasons
nothing to do with the ASM->EXE assembly process.
It is very robust (bear in mind this assembler mainly processes
/generated/ ASM.)
(The speed of 2-4Mlps is nice, but still is slow enough, given that ASM
source is considerably larger than the original source, that it can half
the potential speed of a fast compiler. I'm in the process of removing
that dependency.)
> Ah, you think it's fine for you to write poorer quality code because
> other people do so? I don't subscribe to that policy myself.
I write code to /my/ standards. And my standards can be high when
applied to the languages I use.
I had to write my own linker (the same program as the above assembler)
because of serious problems with ld, used standalone, and golink, the
only other competitor.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 21:26 +0200 |
| Message-ID | <qoicda$6g3$1@dont-email.me> |
| In reply to | #147118 |
On 20/10/2019 16:10, Bart wrote:
> On 20/10/2019 14:04, David Brown wrote:
>> On 19/10/2019 14:40, Bart wrote:
>
>>> The problem in this case was identifying a program that was useless
>>> for my purposes (Nasm), and writing one (an assembler for which this
>>> is part) that did a far better job (ie. some 1000 times faster for my
>>> inputs, no exaggeration).
>>>
>>
>> I really hope you were not using the documentation for outdated file
>> formats for TI's DSP devices for writing an assembler for Windows.
>
> I used modern docs as I need 64-bit formats, but most docs are terrible,
> and that particular file format (which unwisely tries to conflate OBJ
> and EXE formats) is a nightmare.
>
The various formats for object code have their advantages and
disadvantages. There is invariably a balance between features and
complexity. COFF is quite an old format, and has been mostly replaced
by ELF (except, as you might guess, for Windows - PE is basically an
extension of COFF).
>>> If you think that is not programming, then that is your opinion.
>>
>> The process you described, and the snippet of code you showed, is not
>> good programming IMHO.
>
> Judge for yourself; here is the obj-generating module (little used now
> as I mainly use .exe):
I was only looking at the C code you posted.
>
> https://github.com/sal55/qx/blob/master/ax_writeobj.m
>
> And the exact-layout structs used:
>
> https://github.com/sal55/qx/blob/master/ax_objdecls.m
I note that your language uses size-specific types. Why don't you use
size-specific types in the generated C code?
>
> ('proc writestringtable was the one with the bug. This code is not C as
> should be obvious.)
In your language, it appears that you use fixed-size integer types. And
you probably have other assumptions that are absolutely fine in your own
language (like 8-bit bytes, little-endian order) but are not fine in
generated C code without additional checking.
So - judging only from a quick check at the linked code - the bug
appears to be in the way you generate C code from your own language, not
in the original ".m" file.
>
>> Writing fast programs is easy. Writing /correct/ programs is hard. I
>> have no idea if your assembler is a good program or not - that would
>> require looking at the detailed specifications for the program and the
>> implementation code. Maybe it is a perfectly good program - maybe not.
>
>> All I can say is that the speed of chewing through a million lines of
>> code is utterly meaningless in comparison to correctness, and thus it
>> is pointless to boast about it.
>
> Here the speed IS important. The original Nasm backend could easily take
> 1 or 2 minutes to process ASM that took 100msec to generate. YOU might
> be willing to wait that long; I'm not. For a long time it was a big
> obstacle to being able to write a viable whole-project compiler.
You may think speed is important. It /might/ be important. (It
certainly seems reasonable to want to be better than the ridiculously
slow Nasm.) But it is /never/ as important as making sure the code is
correct. A fast wrong answer is not better than a slow correct answer.
That is why speed in itself does not impress me at all.
(Sometimes speed requirements are part of the specification - in which
case they become part of correctness.)
>
> And OBJ/EXE files, full of x64 machine code, are VERY unforgiving of
> errors. If a resulting EXE crashes, it will ultimately be for reasons
> nothing to do with the ASM->EXE assembly process.
>
> It is very robust (bear in mind this assembler mainly processes
> /generated/ ASM.)
Writing a /correct/ assembler is impressive. You get plenty of kudos
for that. You don't get it for the speed.
>
> (The speed of 2-4Mlps is nice, but still is slow enough, given that ASM
> source is considerably larger than the original source, that it can half
> the potential speed of a fast compiler. I'm in the process of removing
> that dependency.)
>
>> Ah, you think it's fine for you to write poorer quality code because
>> other people do so? I don't subscribe to that policy myself.
>
> I write code to /my/ standards. And my standards can be high when
> applied to the languages I use.
>
> I had to write my own linker (the same program as the above assembler)
> because of serious problems with ld, used standalone, and golink, the
> only other competitor.
>
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-20 19:56 +0000 |
| Message-ID | <6_2rF.1005447$t92.391441@fx25.am4> |
| In reply to | #147123 |
On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: > On 20/10/2019 16:10, Bart wrote: >> >> Here the speed IS important. The original Nasm backend could easily take >> 1 or 2 minutes to process ASM that took 100msec to generate. YOU might >> be willing to wait that long; I'm not. For a long time it was a big >> obstacle to being able to write a viable whole-project compiler. > > You may think speed is important. It /might/ be important. (It > certainly seems reasonable to want to be better than the ridiculously > slow Nasm.) But it is /never/ as important as making sure the code is > correct. A fast wrong answer is not better than a slow correct answer. > That is why speed in itself does not impress me at all. There is fasm that is written in assembler, and it is self compiled. Blazingly fast. nasm is written in C, and it is not king of speed.... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 23:06 +0200 |
| Message-ID | <qoii8b$cs7$1@dont-email.me> |
| In reply to | #147125 |
On 20/10/2019 21:56, Melzzzzz wrote: > On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: >> On 20/10/2019 16:10, Bart wrote: >>> >>> Here the speed IS important. The original Nasm backend could easily take >>> 1 or 2 minutes to process ASM that took 100msec to generate. YOU might >>> be willing to wait that long; I'm not. For a long time it was a big >>> obstacle to being able to write a viable whole-project compiler. >> >> You may think speed is important. It /might/ be important. (It >> certainly seems reasonable to want to be better than the ridiculously >> slow Nasm.) But it is /never/ as important as making sure the code is >> correct. A fast wrong answer is not better than a slow correct answer. >> That is why speed in itself does not impress me at all. > > There is fasm that is written in assembler, and it is self compiled. > Blazingly fast. > nasm is written in C, and it is not king of speed.... > The language is irrelevant here. The problem lies in some algorithms within NASM that scale extremely badly with input size. From what I have read, it is something concerning jump size optimisations. It does not matter if you write your program in assembly, C, Python, or anything else - if you have an algorithm that scales badly with input sizes, it is going to be slow for large input. If you don't have any issues like that, you can write your assembler in any language you want - I'd expect an assembler written in Python to run at acceptable speeds for almost any situation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 23:08 +0100 |
| Message-ID | <eV4rF.837184$bv6.810218@fx04.am4> |
| In reply to | #147127 |
On 20/10/2019 22:06, David Brown wrote:
> On 20/10/2019 21:56, Melzzzzz wrote:
>> There is fasm that is written in assembler, and it is self compiled.
>> Blazingly fast.
>> nasm is written in C, and it is not king of speed....
>>
>
> The language is irrelevant here. The problem lies in some algorithms
> within NASM that scale extremely badly with input size. From what I
> have read, it is something concerning jump size optimisations. It does
> not matter if you write your program in assembly, C, Python, or anything
> else - if you have an algorithm that scales badly with input sizes, it
> is going to be slow for large input.
>
> If you don't have any issues like that, you can write your assembler in
> any language you want - I'd expect an assembler written in Python to run
> at acceptable speeds for almost any situation.
>
I think writing such a project in assembly is pointless, as I can't see
the result being significantly faster than one written in C, or in a
language that can be passed, somehow, through an optimising compiler
like gcc-O3.
Besides I've just tried Fasm on an input file of the same line repeated
1 million times; it took 0.8 to 2.0 seconds depending on the complexity
of the line ('inc eax' or 'mov eax,[ebx+ecx*2+123456]').
My assembler took 0.2 to 0.6 seconds, optimised via C/gcc/O3, or 0.3 to
0.8 seconds, using my compiler with its rubbish code, but the result was
still much faster than Fasm.
(Fasm was run with the -p1 option to minimise the number of passes,
otherwise it takes longer. It also seems to be a 32-bit assembler, while
mine handles 64-bit code.)
I think, if Fasm is considered fast, it's little to do with being
written in assembly. (I've written one assembler in machine code, and
one or two in assembly, but only because I had to.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-21 00:25 +0200 |
| Message-ID | <qoimsb$asi$1@dont-email.me> |
| In reply to | #147129 |
On 21/10/2019 00:08, Bart wrote:
> On 20/10/2019 22:06, David Brown wrote:
>> On 20/10/2019 21:56, Melzzzzz wrote:
>
>>> There is fasm that is written in assembler, and it is self compiled.
>>> Blazingly fast.
>>> nasm is written in C, and it is not king of speed....
>>>
>>
>> The language is irrelevant here. The problem lies in some algorithms
>> within NASM that scale extremely badly with input size. From what I
>> have read, it is something concerning jump size optimisations. It
>> does not matter if you write your program in assembly, C, Python, or
>> anything else - if you have an algorithm that scales badly with input
>> sizes, it is going to be slow for large input.
>>
>> If you don't have any issues like that, you can write your assembler
>> in any language you want - I'd expect an assembler written in Python
>> to run at acceptable speeds for almost any situation.
>>
>
> I think writing such a project in assembly is pointless, as I can't see
> the result being significantly faster than one written in C, or in a
> language that can be passed, somehow, through an optimising compiler
> like gcc-O3.
>
> Besides I've just tried Fasm on an input file of the same line repeated
> 1 million times; it took 0.8 to 2.0 seconds depending on the complexity
> of the line ('inc eax' or 'mov eax,[ebx+ecx*2+123456]').
>
> My assembler took 0.2 to 0.6 seconds, optimised via C/gcc/O3, or 0.3 to
> 0.8 seconds, using my compiler with its rubbish code, but the result was
> still much faster than Fasm.
>
> (Fasm was run with the -p1 option to minimise the number of passes,
> otherwise it takes longer. It also seems to be a 32-bit assembler, while
> mine handles 64-bit code.)
>
> I think, if Fasm is considered fast, it's little to do with being
> written in assembly. (I've written one assembler in machine code, and
> one or two in assembly, but only because I had to.)
As I said, it is all to do with the algorithms used - that outweighs the
cost of the language used. I completely agree with you that writing
such programs in assembly is pointless.
[toc] | [prev] | [next] | [standalone]
Page 8 of 25 — ← Prev page 1 … 6 7 [8] 9 10 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web