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 9 of 25 — ← Prev page 1 … 7 8 [9] 10 11 … 25 Next page →
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-20 22:33 +0000 |
| Message-ID | <ah5rF.1369332$i14.39685@fx27.am4> |
| In reply to | #147129 |
On 2019-10-20, Bart <bc@freeuk.com> wrote: > > 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. I really doubt... > > (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.) fasm is 32 bit, but generates 16bit - 64 bit code no problem. Linux,Windows and DOS, all object formats except x32-64 for Linux, for that you need fasmg. You even don't need linker as it can create Windows/Linux/DOS executables directly. Format is written in source file itself, so there are no switches except defines and how much memory to use. Next generation is fasmg which uses macros in such way that it can generate code for any processor. -- 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 | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-20 22:57 +0000 |
| Message-ID | <4D5rF.3005764$xm3.2774531@fx15.am4> |
| In reply to | #147132 |
On 2019-10-20, Melzzzzz <Melzzzzz@zzzzz.com> wrote: > On 2019-10-20, Bart <bc@freeuk.com> wrote: >> >> 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. > > I really doubt... > >> >> (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.) > > fasm is 32 bit, but generates 16bit - 64 bit code no problem. Linux,Windows > and DOS, all object formats except x32-64 for Linux, for that you need fasmg. > You even don't need linker as it can create Windows/Linux/DOS executables > directly. Format is written in source file itself, so there are no switches > except defines and how much memory to use. > > Next generation is fasmg which uses macros in such way that it can > generate code for any processor. > This is time to perfom self assemble on all 4 platforms it supports: ~/fasm/source >>> time (fasm DOS/fasm.asm && fasm libc/fasm.asm && fasm Linux/fasm.asm && fasm Win32/fasm.asm) flat assembler version 1.73.16 (16384 kilobytes memory) 5 passes, 106269 bytes. flat assembler version 1.73.16 (16384 kilobytes memory) 5 passes, 136736 bytes. flat assembler version 1.73.16 (16384 kilobytes memory) 5 passes, 105270 bytes. flat assembler version 1.73.16 (16384 kilobytes memory) 5 passes, 115712 bytes. ( fasm DOS/fasm.asm && fasm libc/fasm.asm && fasm Linux/fasm.asm && fasm ; ) 0.18s user 0.01s system 99% cpu 0.196 total -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-21 00:14 +0100 |
| Message-ID | <DT5rF.1130912$Nw3.1084732@fx40.am4> |
| In reply to | #147132 |
On 20/10/2019 23:33, Melzzzzz wrote:
> On 2019-10-20, Bart <bc@freeuk.com> wrote:
>>
>> 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.
>
> I really doubt...
Why?
My first test simply added 1M lines to the hello.asm example, but it
seems that drags in a lot of code. With a purer test of the same 1M line
file:
C:\fa>timeit "fasm u.asm"
flat assembler version 1.73.16 (1048576 kilobytes memory)
1 passes, 1.4 seconds, 9000000 bytes.
fasm u.asm 1.54
C:\fa>timeit "ax -time u"
Assembling/linking to u.exe
Time 435
ax -time u 0.53
My 'ax' was about 3 times as fast, using either overall run times, or
the assemblers' own timings. With a simpler instruction on each line, it
was only about twice as fast.
Actually I could compile 'ax' via C and tcc, and it still ran that test
in 0.9 seconds.
>
>>
>> (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.)
>
> fasm is 32 bit, but generates 16bit - 64 bit code no problem.
Well, there must be some directive in the .asm file then that turns on
64-bit instructions, since it doesn't recognise registers such as 'rax'.
Linux,Windows
> and DOS, all object formats except x32-64 for Linux, for that you need fasmg.
> You even don't need linker as it can create Windows/Linux/DOS executables
> directly. Format is written in source file itself, so there are no switches
> except defines and how much memory to use.
>
> Next generation is fasmg which uses macros in such way that it can
> generate code for any processor.
My product is streamlined for one processor (x64) and one target (.exe,
although there is still the .obj I used before I had .exe). It doesn't
support macros either as it's designed for generated ASM code such as a
compiler might produce.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-20 23:48 +0000 |
| Message-ID | <bn6rF.1024319$TY7.816342@fx29.am4> |
| In reply to | #147136 |
On 2019-10-20, Bart <bc@freeuk.com> wrote: > On 20/10/2019 23:33, Melzzzzz wrote: >> On 2019-10-20, Bart <bc@freeuk.com> wrote: >>> >>> 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. >> >> I really doubt... > > Why? > > My first test simply added 1M lines to the hello.asm example, but it > seems that drags in a lot of code. With a purer test of the same 1M line > file: That's not test. > > C:\fa>timeit "fasm u.asm" > flat assembler version 1.73.16 (1048576 kilobytes memory) > 1 passes, 1.4 seconds, 9000000 bytes. > fasm u.asm 1.54 > > C:\fa>timeit "ax -time u" > Assembling/linking to u.exe > Time 435 > ax -time u 0.53 > Well, you showed that you can encode same instruction faster in large file.... but I can bet that fasm blows your assembler any time for reallistic program. > My 'ax' was about 3 times as fast, using either overall run times, or > the assemblers' own timings. With a simpler instruction on each line, it > was only about twice as fast. > > Actually I could compile 'ax' via C and tcc, and it still ran that test > in 0.9 seconds. > > >> >>> >>> (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.) >> >> fasm is 32 bit, but generates 16bit - 64 bit code no problem. > > Well, there must be some directive in the .asm file then that turns on > 64-bit instructions, since it doesn't recognise registers such as 'rax'. format PE64 or format ELF64 or format MS64 COFF take a look into fasm.txt that's manual. -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-21 11:20 +0100 |
| Message-ID | <LDfrF.871562$3x5.69740@fx14.am4> |
| In reply to | #147138 |
On 21/10/2019 00:48, Melzzzzz wrote: > On 2019-10-20, Bart <bc@freeuk.com> wrote: >> On 20/10/2019 23:33, Melzzzzz wrote: >>> On 2019-10-20, Bart <bc@freeuk.com> wrote: >>>> >>>> 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. >>> >>> I really doubt... >> >> Why? >> >> My first test simply added 1M lines to the hello.asm example, but it >> seems that drags in a lot of code. With a purer test of the same 1M line >> file: > > That's not test. > >> >> C:\fa>timeit "fasm u.asm" >> flat assembler version 1.73.16 (1048576 kilobytes memory) >> 1 passes, 1.4 seconds, 9000000 bytes. >> fasm u.asm 1.54 >> >> C:\fa>timeit "ax -time u" >> Assembling/linking to u.exe >> Time 435 >> ax -time u 0.53 >> > > Well, you showed that you can encode same instruction faster > in large file.... > but I can bet that fasm blows your assembler any time for reallistic > program. I don't have realistic input big enough to easily measure, and they would anyway use a different syntax from Fasm. Biggest real test is 300,000 lines, and that takes 180ms overall, or 120ms internal. Another is 120,000 lines, taking 120ms overall, or 64ms internal Internal time is the important measure, since 'ax' is not usually run standalone, but is integrated into a compiler and its input is already in-memory. Those figures give assembly times of 2M to 2.5M lines per second, on my not very fast PC. I guess your machine is faster anyway, but what sort of throughput does Fasm give on big programs? You can use -p1 to speed it up. This is just to get an idea of whether writing it all in ASM was worthwhile. BTW what's going on with 1M lines of mov eax,[ebx+ecx*4+123456] that makes it take 3 times as long as my program? >> Well, there must be some directive in the .asm file then that turns on >> 64-bit instructions, since it doesn't recognise registers such as 'rax'. > > format PE64 > or format ELF64 > or format MS64 COFF > take a look into fasm.txt that's manual. OK. I just ran fasm with no input, that usually gives the options.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-21 12:36 +0100 |
| Message-ID | <iLgrF.871563$3x5.624984@fx14.am4> |
| In reply to | #147145 |
On 21/10/2019 11:20, Bart wrote: > On 21/10/2019 00:48, Melzzzzz wrote: >> >> Well, you showed that you can encode same instruction faster >> in large file.... >> but I can bet that fasm blows your assembler any time for reallistic >> program. > I guess your machine is faster anyway, but what sort of throughput does > Fasm give on big programs? You can use -p1 to speed it up. BTW here's a way for someone to test my 'ax' program on their machine (I assume they're running 64-bit Linux). Compile this C program: https://github.com/sal55/qx/blob/master/ax_u64.c using: gcc -O3 ax_u64.c -oax -lm -ldl Download this 120Kloc test file to the same place: https://raw.githubusercontent.com/sal55/qx/master/qq.asm And assemble like this (can only generate .obj output as .exe requires Windows DLLs): ./ax -time -obj qq (Displayed time will be local clock() counts, and now includes file load, which had been excluded. Note this is an assembler for Windows not Linux.)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-20 22:48 +0000 |
| Message-ID | <Bu5rF.975638$yH4.365412@fx18.am4> |
| In reply to | #147127 |
On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: > > 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 don't. > -- 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-21 01:20 +0200 |
| Message-ID | <qoiq37$rc3$1@dont-email.me> |
| In reply to | #147134 |
On 21/10/2019 00:48, Melzzzzz wrote: > On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: >> >> 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 don't. Suppose the Python assembler takes 50 times as long as the one written in C (or assembly) - not an unreasonable guess, if you are not using PyPy. From the numbers Bart posted, that would mean taking around 0.5 second for a 10,000 line file. It might be a bit slow for assembling a million copies of a single test line - but it would be fine for most situations other than Bart's favourite hobby.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-22 18:00 +0200 |
| Message-ID | <qon93b$rv7$1@dont-email.me> |
| In reply to | #147134 |
On 21/10/2019 00:48, Melzzzzz wrote: > On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: >> >> 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 don't. >> > > <https://blogs.oracle.com/solaris/reimplementing-a-solaris-in-python-gained-17x-performance-improvement-from-c> It is all about the algorithms - a good algorithm in Python will beat a poor algorithm in C or assembly.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-22 10:51 -0700 |
| Message-ID | <1bee9a7a-ef06-4256-afc2-e24a6c2223d9@googlegroups.com> |
| In reply to | #147163 |
On Tuesday, 22 October 2019 17:00:56 UTC+1, David Brown wrote: > On 21/10/2019 00:48, Melzzzzz wrote: > > On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: > >> > >> 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 don't. > >> > > > > > > <https://blogs.oracle.com/solaris/reimplementing-a-solaris-in-python-gained-17x-performance-improvement-from-c> > > It is all about the algorithms - a good algorithm in Python will beat a > poor algorithm in C or assembly. > Probably the runtime is dominated by the linked list sort. Back in the 1980s, memory accesses were cheaper relative to processor instructions than they are now. And requests for large contiguous chunks of memory were far more likely to fail. So use of a linked list made sense. Now it causes cache misses and poor performance.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-22 19:19 +0100 |
| Message-ID | <7LHrF.1058256$4F2.495675@fx26.am4> |
| In reply to | #147163 |
On 22/10/2019 17:00, David Brown wrote: > On 21/10/2019 00:48, Melzzzzz wrote: >> On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: >>> >>> 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 don't. >>> >> >> > > <https://blogs.oracle.com/solaris/reimplementing-a-solaris-in-python-gained-17x-performance-improvement-from-c> > > > It is all about the algorithms - a good algorithm in Python will beat a > poor algorithm in C or assembly. Not much info in that article, but it looks like Python is just making use of ready-made set-handling code written in C within its implementation. Being able to do that easily might well be a benefit of using a scripting language, but you are not really comparing a good algorithm in Python with a good algorithm in C. The article mentions data sets of 100,000 entries which doesn't sound too big.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 21:27 +0100 |
| Message-ID | <Dq3rF.3401120$c8w1.2619259@fx08.am4> |
| In reply to | #147123 |
On 20/10/2019 20:26, David Brown wrote:
> On 20/10/2019 16:10, Bart wrote:
>
> I note that your language uses size-specific types. Why don't you use
> size-specific types in the generated C code?
It does; this definition:
global record coffrelocrec =
var int32 virtualaddr
var int32 stindex
var int16 reloctype
end
ends up as this when targeting C:
struct ax_objdecls_coffrelocrec {
i32 virtualaddr;
i32 stindex;
i16 reloctype;
};
But the original source only uses size-specific types in cases like
this. Mostly non-specific ones are used, which are synonyms for
size-specific types:
int a # same as int64 or i64, from this year
word b # same as word64 or u64
real c # same as real64 or r64
Which in generated C become i64, u64 and double respectively (I'm not
aware of size-specific float types).
> 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.
The generated C is far from perfect, but doesn't warrant too much time
spent on it. If the results work, then fine; it's a bonus. Otherwise
it's not worth it; the effort is better placed into a native code
generator (and any sort of optimiser).
But, yes, I assume 8-bit bytes and the rest. Life is literally too short
to worry about other possibilities.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-20 14:46 -0700 |
| Message-ID | <9ebacf7d-a996-47f9-8df6-acb3eb629d1a@googlegroups.com> |
| In reply to | #147126 |
On Sunday, 20 October 2019 21:27:24 UTC+1, Bart wrote:
> On 20/10/2019 20:26, David Brown wrote:
> > On 20/10/2019 16:10, Bart wrote:
>
> >
> > I note that your language uses size-specific types. Why don't you use
> > size-specific types in the generated C code?
>
> It does; this definition:
>
> global record coffrelocrec =
> var int32 virtualaddr
> var int32 stindex
> var int16 reloctype
> end
>
> ends up as this when targeting C:
>
> struct ax_objdecls_coffrelocrec {
> i32 virtualaddr;
> i32 stindex;
> i16 reloctype;
> };
>
> But the original source only uses size-specific types in cases like
> this. Mostly non-specific ones are used, which are synonyms for
> size-specific types:
>
If a "global record" was exactly the same thing as a C struct,
there would be no point to your language. Just use C structs. But
since it is not the same thing, of course it can't be replaced
by a simple translation like this. If I understand rightly, the
difference is that a "global record" never has any padding, it
always specifies the layout of bits in memory. So on most compilers
you can coax a C struct to match, especially in the common case
of a global record not having any odd sized character members.
But you can't expect the code to fully conform to the ANSI standard.
To do that, you have to program at the bit level. Which makes the
compile to C translator more difficult to write and the generated
C less efficient and less readable, so probably not worth it if
you know you are only going to support one or two platforms anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 23:34 +0100 |
| Message-ID | <ci5rF.3038335$dw4.2518880@fx12.am4> |
| In reply to | #147128 |
On 20/10/2019 22:46, Malcolm McLean wrote:
> On Sunday, 20 October 2019 21:27:24 UTC+1, Bart wrote:
>> On 20/10/2019 20:26, David Brown wrote:
>>> On 20/10/2019 16:10, Bart wrote:
>>
>>>
>>> I note that your language uses size-specific types. Why don't you use
>>> size-specific types in the generated C code?
>>
>> It does; this definition:
>>
>> global record coffrelocrec =
>> var int32 virtualaddr
>> var int32 stindex
>> var int16 reloctype
>> end
>>
>> ends up as this when targeting C:
>>
>> struct ax_objdecls_coffrelocrec {
>> i32 virtualaddr;
>> i32 stindex;
>> i16 reloctype;
>> };
>>
>> But the original source only uses size-specific types in cases like
>> this. Mostly non-specific ones are used, which are synonyms for
>> size-specific types:
>>
> If a "global record" was exactly the same thing as a C struct,
> there would be no point to your language. Just use C structs.
There are between 100 and 200 points to my language. The simple example
above illustrates a few:
(1) My example creates new type called 'coffrelocrec', which in C
requires a typedef. So there is none of this confusion between
struct tags and typenames
(2) The 'global' attribute means the definition is exported from the
module where it is defined, without needing to separate out
things into a .h file and .c file (there are only module source
files; no headers)
(3) Different modules can export the same coffrelocrec type name, and
they can be disambiguated by using a qualifier, if more than one is
visible in any module
(4) The 'var' here is there because structs can contain other things,
such as types, enums, named constants and actual functions
(although I do little with that ATM)
(5) The types int16/32 (can also be written as i16/i32) are
built-in types of exactly 2 or 4 bytes. They are not bolted
on via inttypes.h and defined in terms of short and int.
(6) Plus, the layout of the fields is exactly as you specify them,
with no padding added either between fields, or at the end.
You don't need to apply pack(1) (or somehow un-apply after to
restore normal behaviour).
> But
> since it is not the same thing, of course it can't be replaced
> by a simple translation like this. If I understand rightly, the
> difference is that a "global record" never has any padding, it
> always specifies the layout of bits in memory.
It models how you might lay out such data in assembly:
A: dd 100 # dd=32 bits
dd 200
dw 300 # dw=16 bits
Here occupying 10 bytes, and forming, starting from A, an instance of
coffrelocrec.
> To do that, you have to program at the bit level. Which makes the
> compile to C translator more difficult to write and the generated
> C less efficient and less readable,
The readability of such code is a lost cause (although the fragment
above isn't too bad apart from the decorated name).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-18 16:35 +0100 |
| Message-ID | <87mudy2hik.fsf@bsb.me.uk> |
| In reply to | #147026 |
scott@slp53.sl.home (Scott Lurndal) writes: > Bart <bc@freeuk.com> writes: >>On 14/10/2019 11:33, Anton Shepelev wrote: >>> Bart: >> >> >>It is when you don't have the memory! Here is the C equivalent of a bug >>I found today: >> >> char *dataptr; >> int *p; >> >> p = (int*)dataptr; >> *p = x; >> dataptr += 4; > > Of course competent C programmer would have written > > dataptr += sizeof(int); I'd prefer void *dataptr ... ; int *p = dataptr; *p++ = x; dataptr = p; -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-18 17:01 +0000 |
| Message-ID | <HdmqF.3347617$c8w1.2029341@fx08.am4> |
| In reply to | #147026 |
On 2019-10-18, Scott Lurndal <scott@slp53.sl.home> wrote: > Bart <bc@freeuk.com> writes: >>On 14/10/2019 11:33, Anton Shepelev wrote: >>> Bart: >> >> >>It is when you don't have the memory! Here is the C equivalent of a bug >>I found today: >> >> char *dataptr; >> int *p; >> >> p = (int*)dataptr; >> *p = x; >> dataptr += 4; > > Of course competent C programmer would have written > > dataptr += sizeof(int); no, assert(sizeof(int)==4); /* :) */ -- 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-18 19:15 +0200 |
| Message-ID | <qocrv3$187$2@dont-email.me> |
| In reply to | #147040 |
On 18/10/2019 19:01, Melzzzzz wrote: > On 2019-10-18, Scott Lurndal <scott@slp53.sl.home> wrote: >> Bart <bc@freeuk.com> writes: >>> On 14/10/2019 11:33, Anton Shepelev wrote: >>>> Bart: >>> >>> >>> It is when you don't have the memory! Here is the C equivalent of a bug >>> I found today: >>> >>> char *dataptr; >>> int *p; >>> >>> p = (int*)dataptr; >>> *p = x; >>> dataptr += 4; >> >> Of course competent C programmer would have written >> >> dataptr += sizeof(int); > > no, assert(sizeof(int)==4); /* :) */ > At least make it _Static_assert ! (I'm fine with non-portable code that makes assumptions - even unnecessary ones - about the target. But the code should fail to compile if the assumptions don't hold.)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-18 19:01 +0000 |
| Message-ID | <H_nqF.1308858$Zy3.536358@fx33.am4> |
| In reply to | #147042 |
On 2019-10-18, David Brown <david.brown@hesbynett.no> wrote: > On 18/10/2019 19:01, Melzzzzz wrote: >> On 2019-10-18, Scott Lurndal <scott@slp53.sl.home> wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 14/10/2019 11:33, Anton Shepelev wrote: >>>>> Bart: >>>> >>>> >>>> It is when you don't have the memory! Here is the C equivalent of a bug >>>> I found today: >>>> >>>> char *dataptr; >>>> int *p; >>>> >>>> p = (int*)dataptr; >>>> *p = x; >>>> dataptr += 4; >>> >>> Of course competent C programmer would have written >>> >>> dataptr += sizeof(int); >> >> no, assert(sizeof(int)==4); /* :) */ >> > > At least make it _Static_assert ! I don't know about that... > > (I'm fine with non-portable code that makes assumptions - even > unnecessary ones - about the target. But the code should fail to > compile if the assumptions don't hold.) nice, but error message should be sufficient... > > -- 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 13:14 +0200 |
| Message-ID | <qohfi5$ikl$1@dont-email.me> |
| In reply to | #147044 |
On 18/10/2019 21:01, Melzzzzz wrote: > On 2019-10-18, David Brown <david.brown@hesbynett.no> wrote: >> On 18/10/2019 19:01, Melzzzzz wrote: >>> On 2019-10-18, Scott Lurndal <scott@slp53.sl.home> wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> On 14/10/2019 11:33, Anton Shepelev wrote: >>>>>> Bart: >>>>> >>>>> >>>>> It is when you don't have the memory! Here is the C equivalent of a bug >>>>> I found today: >>>>> >>>>> char *dataptr; >>>>> int *p; >>>>> >>>>> p = (int*)dataptr; >>>>> *p = x; >>>>> dataptr += 4; >>>> >>>> Of course competent C programmer would have written >>>> >>>> dataptr += sizeof(int); >>> >>> no, assert(sizeof(int)==4); /* :) */ >>> >> >> At least make it _Static_assert ! > > I don't know about that... _Static_assert(CHAR_BIT == 8, "Expected 8-bit bytes"); _Static_assert((sizeof(int) == 4, "Expected int to be size 4"); You can use #if and #error as well in some cases, but C11 _Static_assert is a bit more flexible. In my opinion, you should never use run-time checks like assert() if you can use a static assertion. > >> >> (I'm fine with non-portable code that makes assumptions - even >> unnecessary ones - about the target. But the code should fail to >> compile if the assumptions don't hold.) > > nice, but error message should be sufficient... > Exactly - an error message when /compiling/, rather than waiting until run-time. (It's a different matter if the code in question is not necessarily going to be run. Then you might want the check at run-time.)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-20 11:25 +0000 |
| Message-ID | <8vXqF.993908$Jh2.118120@fx39.am4> |
| In reply to | #147105 |
On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: > On 18/10/2019 21:01, Melzzzzz wrote: >> On 2019-10-18, David Brown <david.brown@hesbynett.no> wrote: >>> On 18/10/2019 19:01, Melzzzzz wrote: >>>> On 2019-10-18, Scott Lurndal <scott@slp53.sl.home> wrote: >>>>> Bart <bc@freeuk.com> writes: >>>>>> On 14/10/2019 11:33, Anton Shepelev wrote: >>>>>>> Bart: >>>>>> >>>>>> >>>>>> It is when you don't have the memory! Here is the C equivalent of a bug >>>>>> I found today: >>>>>> >>>>>> char *dataptr; >>>>>> int *p; >>>>>> >>>>>> p = (int*)dataptr; >>>>>> *p = x; >>>>>> dataptr += 4; >>>>> >>>>> Of course competent C programmer would have written >>>>> >>>>> dataptr += sizeof(int); >>>> >>>> no, assert(sizeof(int)==4); /* :) */ >>>> >>> >>> At least make it _Static_assert ! >> >> I don't know about that... > > _Static_assert(CHAR_BIT == 8, "Expected 8-bit bytes"); > _Static_assert((sizeof(int) == 4, "Expected int to be size 4"); > > You can use #if and #error as well in some cases, but C11 _Static_assert > is a bit more flexible. In my opinion, you should never use run-time > checks like assert() if you can use a static assertion. Why? assert served me well so far... > >> >>> >>> (I'm fine with non-portable code that makes assumptions - even >>> unnecessary ones - about the target. But the code should fail to >>> compile if the assumptions don't hold.) >> >> nice, but error message should be sufficient... >> > > Exactly - an error message when /compiling/, rather than waiting until > run-time. If error message is meaningfull... -- 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]
Page 9 of 25 — ← Prev page 1 … 7 8 [9] 10 11 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web