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 4 of 25 — ← Prev page 1 2 3 [4] 5 6 … 25 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-10 11:05 -0700 |
| Message-ID | <lntv8gtr12.fsf@kst-u.example.com> |
| In reply to | #146831 |
already5chosen@yahoo.com writes:
[...]
> I think, your understanding is wrong.
> C standards and pre-standard books define 'int' as the most efficient
> signed integer type on a given machine. At some point it was changed
> to the most efficient signed integer type with at least 15 bits of
> magnitude.
Incorrect. The phrase "most efficient" is not used.
The 1975 C manual says "Integers (int) are represented in 16-bit 2's
complement notation"; it was based (mostly) on a single implementation.
K&R1 (1978) says int is "an integer, typically reflecting the natural
size of integers on the host machine". It includes a table showing the
sizes of types on 4 different implementations, with int being 16, 36, or
32 bits.
The current standard says
A "plain" int object has the natural size suggested by the
architecture of the execution environment (large enough to
contain any value in the range INT_MIN to INT_MAX as defined
in the header <limits.h>).
and requires elsewhere that INT_MIN <= -32767 and INT_MAX >= +32767.
But the phrase "natural size" is vague enough to be unenforceable.
Clearly the natural size on a 64-bit system would be 64 bits (especially
for CPUs that don't have 32-bit operations), but most C compilers for
such systems have 32-bit int.
> So, on IA-32 platform 256-bit int would be clearly non-standard.
It would be conforming apart from the "natural size" clause. In
practice IA-32 implementations do use 32-bit int (or *maybe* 16-bit
int), but they would do so even without the "natural size" clause.
[...]
--
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 | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2019-10-10 14:33 -0400 |
| Message-ID | <qnnthp$b4v$1@dont-email.me> |
| In reply to | #146846 |
Keith Thompson wrote: > already5chosen@yahoo.com writes: > [...] >> I think, your understanding is wrong. >> C standards and pre-standard books define 'int' as the most efficient >> signed integer type on a given machine. At some point it was changed >> to the most efficient signed integer type with at least 15 bits of >> magnitude. > > Incorrect. The phrase "most efficient" is not used. > > The 1975 C manual says "Integers (int) are represented in 16-bit 2's > complement notation"; it was based (mostly) on a single implementation. > > K&R1 (1978) says int is "an integer, typically reflecting the natural > size of integers on the host machine". It includes a table showing the > sizes of types on 4 different implementations, with int being 16, 36, or > 32 bits. > > The current standard says > A "plain" int object has the natural size suggested by the > architecture of the execution environment (large enough to > contain any value in the range INT_MIN to INT_MAX as defined > in the header <limits.h>). > and requires elsewhere that INT_MIN <= -32767 and INT_MAX >= +32767. > > But the phrase "natural size" is vague enough to be unenforceable. > Clearly the natural size on a 64-bit system would be 64 bits (especially > for CPUs that don't have 32-bit operations), but most C compilers for > such systems have 32-bit int. > >> So, on IA-32 platform 256-bit int would be clearly non-standard. > > It would be conforming apart from the "natural size" clause. In > practice IA-32 implementations do use 32-bit int (or *maybe* 16-bit > int), but they would do so even without the "natural size" clause. In my programming experience, I've found it useful not to think of arithmetic objects (like shorts, ints and longs) in terms of their memory size, but instead in terms of the ranges of values that they can hold. It is not often (afaicr, never) that I've found myself thinking "I've got 16 bits of space, what values can I store in it?". More often (always, afaicr) I've said "I have a need to store a value between <<something>> and <<something else>>; what sort of object can store that?" I see no need to preoccupy myself with arguments about the "bit width" of various C arithmetic objects; I find such discussions counterproductive to the task of writing programs. -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-10 12:20 -0700 |
| Message-ID | <lnpnj4tnko.fsf@kst-u.example.com> |
| In reply to | #146847 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> In my programming experience, I've found it useful not to think of
> arithmetic objects (like shorts, ints and longs) in terms of their memory
> size, but instead in terms of the ranges of values that they can hold.
>
> It is not often (afaicr, never) that I've found myself thinking "I've got 16
> bits of space, what values can I store in it?". More often (always, afaicr)
> I've said "I have a need to store a value between <<something>> and
> <<something else>>; what sort of object can store that?"
>
> I see no need to preoccupy myself with arguments about the "bit width" of
> various C arithmetic objects; I find such discussions counterproductive to
> the task of writing programs.
Agreed -- and in fact that's how the standard specifies the
requirements. The sizes in bits (for example, int is at least 16
bits) can be inferred from the range requirements and the requirement
for pure binary notation.
An exception is when an external interface imposes a specific
size requirement. (Even then, the size requirement is usually
based on a need to hold some range of values.) Another is when
an unsigned integer is used to hold flag values (you can store at
least 16 flags in an unsigned flag, 32 in a uint32_t, etc.).
On the other hand, it's easier to say "at least 64 bits" than
"at least 0 to 18446744073709551615".
--
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 | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2019-10-10 16:00 -0400 |
| Message-ID | <qno2kn$ahk$1@dont-email.me> |
| In reply to | #146848 |
Keith Thompson wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > [...] >> In my programming experience, I've found it useful not to think of >> arithmetic objects (like shorts, ints and longs) in terms of their memory >> size, but instead in terms of the ranges of values that they can hold. >> >> It is not often (afaicr, never) that I've found myself thinking "I've got >> 16 bits of space, what values can I store in it?". More often (always, >> afaicr) I've said "I have a need to store a value between <<something>> >> and <<something else>>; what sort of object can store that?" >> >> I see no need to preoccupy myself with arguments about the "bit width" of >> various C arithmetic objects; I find such discussions counterproductive >> to the task of writing programs. > > Agreed -- and in fact that's how the standard specifies the > requirements. The sizes in bits (for example, int is at least 16 > bits) can be inferred from the range requirements and the requirement > for pure binary notation. > > An exception is when an external interface imposes a specific > size requirement. (Even then, the size requirement is usually > based on a need to hold some range of values.) This is where the skill of programming starts. It is easier to write code to fit values into specific size requirements, when the language natively supports those requirements. It's less easy (but, still not impossible, as some here would have you believe) to write code to fit values into size requirements that aren't directly supported by the language. But, /that/ is the task, the skill, of programming. For illustration sake, imagine an external interface that requires integers to be stored as BCD, with a sign nybble. Yes, we could complain that "C doesn't support BCD, so shame on C" or we could just code the appropriate function to store BCD values, using the wide variety of facilities that C /does/ offer. That's the skill of a programmer. > Another is when > an unsigned integer is used to hold flag values (you can store at > least 16 flags in an unsigned flag, 32 in a uint32_t, etc.). I see this as "I need to a certain number of bit flags, what sort of object can I use" rather than "I choose this <<object>>; damn - it can't handle the <<number>> of bit flags that I want - the C language is deficient because it should support <<number>>-bit <<objects>> and it doesn't." > On the other hand, it's easier to say "at least 64 bits" than > "at least 0 to 18446744073709551615". Sure, when using "at least 64 bits" as a measure of a value's magnitude of range. -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-10 23:43 +0300 |
| Message-ID | <20191010234315.5afc201d375c6c1a369b7776@gmail.com> |
| In reply to | #146848 |
Keith Thompson: > On the other hand, it's easier to say "at least 64 bits" > than "at least 0 to 18446744073709551615". Say (2^64-1), unless talking to a Setun programmer. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-10 14:12 -0700 |
| Message-ID | <lnlftsticm.fsf@kst-u.example.com> |
| In reply to | #146852 |
Anton Shepelev <anton.txt@gmail.com> writes:
> Keith Thompson:
>> On the other hand, it's easier to say "at least 64 bits"
>> than "at least 0 to 18446744073709551615".
>
> Say (2^64-1), unless talking to a Setun programmer.
Good point. (Except that 2^64-1 is 61.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-11 01:04 +0300 |
| Message-ID | <20191011010429.2a41050ddeac92443a8a54f5@gmail.com> |
| In reply to | #146853 |
Keith Thompson: > (Except that 2^64-1 is 61.) How do you mean? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-10 22:17 +0000 |
| Message-ID | <P5OnF.117685$LG2.107411@fx48.iad> |
| In reply to | #146857 |
Anton Shepelev <anton.txt@gmail.com> writes: >Keith Thompson: > >> (Except that 2^64-1 is 61.) > >How do you mean? The caret/hat symbol, in C expressions, denotes an exclusive or operation. $ printf '%d\n' $(( 2 ^ 64 - 1 )) 61
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-10 15:24 -0700 |
| Message-ID | <lnh84gtf1l.fsf@kst-u.example.com> |
| In reply to | #146858 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Anton Shepelev <anton.txt@gmail.com> writes:
>>Keith Thompson:
>>
>>> (Except that 2^64-1 is 61.)
>>
>>How do you mean?
>
> The caret/hat symbol, in C expressions, denotes an exclusive or operation.
>
> $ printf '%d\n' $(( 2 ^ 64 - 1 ))
> 61
And it has lower precedence than addition, so 2^64-1 means 2^(64-1).
Which is why I try to use "**" to denote exponentiation when discussing C.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 12:57 +0100 |
| Message-ID | <D0FnF.701053$665.191395@fx28.am4> |
| In reply to | #146826 |
On 10/10/2019 01:03, Anton Shepelev wrote:
>> "The C language supports 8/16/32/64-bit data types but the
>> default 'int' size is 32 bits, and calculations are done
>> at at least 32 bits."
>
> I was comparing the languages, not their implementations.
> The primary types of your language are hardware-bound. The
> primary types of the C language are not,
Mine is a systems programming language for low-level work.
So is C, so not providing hardware specific types may have been a
mistake. Partly rectified in C99, but the implementation, and keeping
two different schemes to represent types (which people pick and choose
from), have made things messy.
C is the probably the world's most famous language to coding 'close to
the metal', yet it took nearly 30 years until you could even specify an
int of a specific width with any confidence!
> some "Extended-range C compiler" where `int' is 256 bits and
> `long int' 512! That is the power of abstract types.
The language Zig I believe allows such ints of arbitrary /fixed/ widths,
which don't even need to be powers-of-two (so int173), but that seems
to me the wrong approach.
>
>> Range types: I don't like elaborate type systems, and
>> things like this, done properly, always end up with type
>> systems like Ada's.
>
> I meant not range types but a facility that can pick a
> native type sufficient for storing a certain value.
I think I may have tried that idea once, but it didn't stick.
And I don't think it works:
A: int(0..6000)
(I had to use a range otherwise it's not clear if the range was 1..6000
or 0..6000 or -6000..+6000).
Suppose A had the value 6000, and you add 1 to it. Should the value wrap
around to 0, or should be it be 6001, or should be trap?
This might be the expectation, even if your intention was to simply
choose the smallest of i8 i16 i32 i64 to accommodate its values.
So i16 here, if the 'int' means signed, and it will wrap, or overflow,
at values over 16383. But a suitable type can also be u16, if declared
like this:
A: (0..6000)
But then, if A is unsigned, and it's used with a signed value, then this
can affect the results of calculations.
See how the simplest idea turns into a can of worms!
>> What happens is that if I used the equivalent of
>> 'sizeof(void*)', that gets hard-coded in the C as either
>> "4" or "8". Once that happens, C source containing "4"
>> must use a C compiler with 32-bit pointers, not 64, and
>> similar for "8".
>
> Understood -- you have to know the sizes of abstract C types
> if you want to use them. But can you generate code with
> sizeof(), postponing its expansion till the stage where the
> generated C is compiled?
I mentioned this was at an early stage. But I will try an experiment
later, to not reduce sizeof() (ie .bytes in the language) to a constant
value when it is a C target.
This will introduce an extra restriction (can't use .bytes in something
that /needs/ to be a compile-time expression (MY compile-time not
C's!)), but it could work if my programs don't use that ability.
>> Written in C or original language?
>
> My example is obviously a C program.
Writing any actual C code, and having that as a dependency, would be a
last resort. It might be done if I absolutely had to use a particular
library, but would be packed into a DLL/.so file and then used as an
ordinary binary library from my language.
I wouldn't want to do that just for translating any ordinary program.
Note that I probably make the biggest use of binary libraries with a C
API from my dynamic language, where there is no writing of C involved at
all.
So from interpreted code, I can directly call into libraries such as
WinAPI, SDL, and I've done one test with GTK.
(Only callback functions are tricky: you can't call into byte-code from
compiled code of a different language!)
So doing it from a compiled language ought to be easier...
>> My C is code is fairly conservative and uses few features.
>
> Yet very liberal in that it relies on compiler-specific
> relaxations of C among those few features.
If it works with gcc (no -pedantic) and tcc.c then that will be enough.
As you say C will not change much.
And in the future, I will either have found an alternative approach, or
dropped it anyway.
I have after all managed without generating C code at all for several
decades.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-11 00:53 +0300 |
| Message-ID | <20191011005333.eaad614c3736b2f559a2db66@gmail.com> |
| In reply to | #146836 |
Bart: > Mine is a systems programming language for low-level work. Why not a general-purpose language? > So is C, so not providing hardware specific types may have > been a mistake. Partly rectified in C99, but the > implementation, and keeping two different schemes to > represent types (which people pick and choose from), have > made things messy. That may be, but C is technically high-level and its abstract types are a part of its portability, as is the incompatibility of types whose size and representation accidentally coincide. > C is the probably the world's most famous language to > coding 'close to the metal', yet it took nearly 30 years > until you could even specify an int of a specific width > with any confidence! If it were so, how did people write programs that depended upon specific type sizes/ranges from the very inception of C? I am sure programmers obtained types of explicit width/range via conditional compilation or other means. It cannot have been enragingly difficult. > The language Zig I believe allows such ints of arbitrary > /fixed/ widths, which don't even need to be powers-of-two > (so int173), but that seems to me the wrong approach. Well, it may give considerable space-efficiency in certain situations... > > I meant not range types but a facility that can pick a > > native type sufficient for storing a certain value. > > I think I may have tried that idea once, but it didn't > stick. > > And I don't think it works: > > A: int(0..6000) > > (I had to use a range otherwise it's not clear if the > range was 1..6000 or 0..6000 or -6000..+6000). > > Suppose A had the value 6000, and you add 1 to it. Should > the value wrap around to 0, or should be it be 6001, or > should be trap? It is the second time that I have failed to express my idea. Perhaps it is so stupid that you cannot believe I mean what I mean: that the macro int(V) shall expand into the type specifier for the smallest signed integer type that can hold the value V. Nothing else is guarranteed or checked. It is probably useless whereever the type widths are powers of two, but I was abstracting even from that. > Writing any actual C code, and having that as a > dependency, would be a last resort. In what sense is that a dependency? Where does your tool store the `if' keyword of the C language? Do you consider that a fragment of actual C code, manually written and comprising a dependency? Likewise, you can store any necessary C wrappers inside your tool's executable and put them at the top of your generated C source, perhaps omitting the stuff that was not needed for the transpiling of the specific program. > I wouldn't want to do that just for translating any > ordinary program. Don't you need a universal approach that can work with any program, ordinary and otherwise? > Note that I probably make the biggest use of binary > libraries with a C API from my dynamic language, where > there is no writing of C involved at all. But I was thinking about the transpiler to C. > (Only callback functions are tricky: you can't call into > byte-code from compiled code of a different language!) So > doing it from a compiled language ought to be easier... I wonder how .NET does it: https://stackoverflow.com/questions/7970128/passing-a-c-sharp-callback-function-through-interop-pinvoke > If it works with gcc (no -pedantic) and tcc.c then that > will be enough. As you say C will not change much. I did not say that about tcc, gcc, or the demise of these compilers and the birth of new ones. This is not a group for the discussion of specific compilers and their idiosyncratic C dialects coming into effect in default of any command-line options telling the compiler what language it should expect. > I have after all managed without generating C code at all > for several decades. If you are not enthusiastic about perfecting your transpiler to C, you can't expect other people to feel enthusiastic about it either! You come to a newsgroup devoted to C and tell everybody how you dislike C and want to drop it from your tools. What is, then, the subject matter for conversation? The generation of correct and portable C code is, on the other hand, a welcome topic, and several people here are more willing to help you than your attitude seems to justify. Your attitude is the only problem, for you ceratainly have the skill and knowledge required for the task. I really wish you employed them for a good purpose, and the implentation of a programming language in the form of a transpiler to C is certainly a good one and has a future. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-11 00:50 +0100 |
| Message-ID | <OsPnF.836744$t92.656258@fx25.am4> |
| In reply to | #146855 |
On 10/10/2019 22:53, Anton Shepelev wrote: >> C is the probably the world's most famous language to >> coding 'close to the metal', yet it took nearly 30 years >> until you could even specify an int of a specific width >> with any confidence! > > If it were so, how did people write programs that depended > upon specific type sizes/ranges from the very inception of > C? I am sure programmers obtained types of explicit > width/range via conditional compilation or other means. It > cannot have been enragingly difficult. I guess you haven't looked at header files much. There is some really ugly code out there, with conditional code, code that depends on compilers, on compiler versions, on OSes, or whether particular types or macros are defined... It's horrid. > It is the second time that I have failed to express my idea. Have you tried to implement your idea or thought about how it might do so? Your suggestion: j: int(6000), was incomplete, as you cannot deduce the range of possible values from that, especially given that it appears to be signed. >> (Only callback functions are tricky: you can't call into >> byte-code from compiled code of a different language!) So >> doing it from a compiled language ought to be easier... > > I wonder how .NET does it: > > https://stackoverflow.com/questions/7970128/passing-a-c-sharp-callback-function-through-interop-pinvoke You mean, the massively huge .NET system, using the massively complex CIL/CLI, created and maintained by one of the world's largest and richest corporations? > If you are not enthusiastic about perfecting your transpiler > to C, you can't expect other people to feel enthusiastic > about it either! I /was/ enthusiastic about it a week ago! The translator was working beautifully, and would have continued doing so long enough to find more permanent solutions (or until I lost interest). But everybody here is giving me grief. They are all perfectionists (so am I, but with aesthetics, and C is ugly). A year ago, people were complaining about 1 line in a 37,000 line program of mine that generated a warning. Now they are complaining about warnings that don't exist unless you use -pedantic. I'm pretty sure they will next complain about code I haven't yet written! Funny how very few of these people ever post substantial code of their own. > The generation of correct and portable C code is, on the > other hand, a welcome topic, and several people here are > more willing to help you than your attitude seems to > justify. Not enough are willing to admit that there is a problem with C or the compilers or tools or whatever, because they are too familiar with them to realise there is anything wrong or they could be better. As an outsider, I can be much more critical. And in fact I am in a position to try out new languages, new ideas, new tools, and to streamline the processes needed to build applications. I specialise in making these small, fast, self-contained and effortless. In 2014 I posted here that I wanted to make the process of building a substantial application, as easy as compiling Hello, World. That was achieved long ago, for programs of 20-40Kloc. The people criticising me for my lack of knowledge of C or make etc, are not in this business. They have no interest in replacing things like 'make'. Your attitude is the only problem, for you > ceratainly have the skill and knowledge required for the > task. I really wish you employed them for a good purpose, > and the implentation of a programming language in the form > of a transpiler to C is certainly a good one and has a > future. I consider having to generate C a failing. There ought to be simple, universal language suitable for use as a compiler target, or for describing library APIs, without any of the baggage, quirks and inconsistencies of C, but there isn't.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2019-10-12 03:42 +0800 |
| Message-ID | <tW4oF.2711157$dw4.182389@fx12.am4> |
| In reply to | #146863 |
On 11/10/2019 7:50 am, Bart wrote: > On 10/10/2019 22:53, Anton Shepelev wrote: > >>> (Only callback functions are tricky: you can't call into >>> byte-code from compiled code of a different language!) So >>> doing it from a compiled language ought to be easier... >> >> I wonder how .NET does it: >> >> >> https://stackoverflow.com/questions/7970128/passing-a-c-sharp-callback-function-through-interop-pinvoke >> > > You mean, the massively huge .NET system, using the massively complex > CIL/CLI, created and maintained by one of the world's largest and > richest corporations? I have done this twice, once for Zsh (yes, the Unix shell) and once for XEmacs (different internals than GNU Emacs). It. Is. Easy. You just need to write a boilerplate code once, and than you can use it again and again. -- Johann | email: invalid -> com | www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | twitter: @myrkraverk
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-11 22:16 +0100 |
| Message-ID | <ri6oF.1018754$Nw3.667248@fx40.am4> |
| In reply to | #146880 |
On 11/10/2019 20:42, Johann 'Myrkraverk' Oskarsson wrote: > On 11/10/2019 7:50 am, Bart wrote: >> On 10/10/2019 22:53, Anton Shepelev wrote: >> >>>> (Only callback functions are tricky: you can't call into >>>> byte-code from compiled code of a different language!) So >>>> doing it from a compiled language ought to be easier... >>> >>> I wonder how .NET does it: >>> >>> https://stackoverflow.com/questions/7970128/passing-a-c-sharp-callback-function-through-interop-pinvoke >>> >> >> You mean, the massively huge .NET system, using the massively complex >> CIL/CLI, created and maintained by one of the world's largest and >> richest corporations? > > I have done this twice, once for Zsh (yes, the Unix shell) and once for > XEmacs (different internals than GNU Emacs). > > It. Is. Easy. > > You just need to write a boilerplate code once, and than you can use it > again and again. I said it was tricky. In my case also, it was my own byte-code language I was working with, and the interpreter was in my own systems language, one which had a very different call convention from any libraries that would be calling the callback address. The byte-code language also had directly deal with functions in the external library and would need to initiate the exchange (set up the callback in the library). For being able to do Windows GUI stuff, there was special helper code in the interpreter, but I don't have a general solution.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2019-10-14 16:08 +0000 |
| Message-ID | <5da49c78.2833078@news.xs4all.nl> |
| In reply to | #146863 |
Bart <bc@freeuk.com> wrote: > On 10/10/2019 22:53, Anton Shepelev wrote: > > >> C is the probably the world's most famous language to > >> coding 'close to the metal', yet it took nearly 30 years > >> until you could even specify an int of a specific width > >> with any confidence! > > > > If it were so, how did people write programs that depended > > upon specific type sizes/ranges from the very inception of > > C? I am sure programmers obtained types of explicit > > width/range via conditional compilation or other means. It > > cannot have been enragingly difficult. > > I guess you haven't looked at header files much. There is some really > ugly code out there, with conditional code, code that depends on > compilers, on compiler versions, on OSes, or whether particular types or > macros are defined... It's horrid. That's because you shouldn't be trying to read system header files, especially not of libraries that pretend to cater for many different varieties of *ahem* Linux. Yes, they need to employ some ugly hacks; that's why they're _system_ header files and not your own. A systems header for a single system doesn't need to pull such tricks, and code written by a user-programmer shouldn't even try to - exactly _because_ good (!) user code can use C's diverse type system and still run efficiently wherever it is compiled. > As an outsider, I can be much more critical. As an outsider, you consistently and insistently fail to understand what C is _for_. C is not your favourite dialect of BASIC. Get over it already. Richard
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-14 19:20 +0100 |
| Message-ID | <O%2pF.3217788$c8w1.2592731@fx08.am4> |
| In reply to | #146958 |
On 14/10/2019 17:08, Richard Bos wrote: > Bart <bc@freeuk.com> wrote: >> I guess you haven't looked at header files much. There is some really >> ugly code out there, with conditional code, code that depends on >> compilers, on compiler versions, on OSes, or whether particular types or >> macros are defined... It's horrid. > > That's because you shouldn't be trying to read system header files, Why not? I might need to use the declared functions, defines, structs etc from a foreign language, like asm; I need that amount of detail. I might need to create my own system headers for my own C compiler, and I need to find out in more detail how they communicate with the C library on my platform. Most people will not need to get that deeply involved, but I do, and I can see how ugly, badly patched and unreadable it all is, as well as sprawling. (Try and find struct stat inside sys/stat.h; it's not there!) > especially not of libraries that pretend to cater for many different > varieties of *ahem* Linux. Yes, they need to employ some ugly hacks; > that's why they're _system_ header files and not your own. >> As an outsider, I can be much more critical. > > As an outsider, you consistently and insistently fail to understand what > C is _for_. I know perfectly well what it's for. I've nearly always done the sort of low-level coding for which most people use C. Here is the only sizeable program I've written in straight C (a bignum library) without using any automated conversion aids: https://github.com/sal55/qx/blob/master/bignum.c This is the sort of thing C is good for, yes? But it was ported (not developed from scratch) from my normal language: https://github.com/sal55/qx/blob/master/bignum.m So I think I'm entitled to make comparisons.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-10-15 07:40 +1300 |
| Message-ID | <h0jtpbFldqU17@mid.individual.net> |
| In reply to | #146965 |
On 15/10/2019 07:20, Bart wrote: > On 14/10/2019 17:08, Richard Bos wrote: >> Bart <bc@freeuk.com> wrote: > >>> I guess you haven't looked at header files much. There is some really >>> ugly code out there, with conditional code, code that depends on >>> compilers, on compiler versions, on OSes, or whether particular types or >>> macros are defined... It's horrid. >> >> That's because you shouldn't be trying to read system header files, > > Why not? > > I might need to use the declared functions, defines, structs etc from a > foreign language, like asm; I need that amount of detail. > > I might need to create my own system headers for my own C compiler, and > I need to find out in more detail how they communicate with the C > library on my platform. Read the man pages, that's what they are for. > Most people will not need to get that deeply involved, but I do, and I > can see how ugly, badly patched and unreadable it all is, as well as > sprawling. (Try and find struct stat inside sys/stat.h; it's not there!) It's described in the man page. Even if it wasn't, any IDE worth using will find it wint one click of the mouse or a one key shortcut. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-14 20:24 +0100 |
| Message-ID | <aY3pF.878160$893.783690@fx02.am4> |
| In reply to | #146967 |
On 14/10/2019 19:40, Ian Collins wrote:
> On 15/10/2019 07:20, Bart wrote:
> Read the man pages, that's what they are for.
>
>> Most people will not need to get that deeply involved, but I do, and I
>> can see how ugly, badly patched and unreadable it all is, as well as
>> sprawling. (Try and find struct stat inside sys/stat.h; it's not there!)
>
> It's described in the man page. Even if it wasn't, any IDE worth using
> will find it wint one click of the mouse or a one key shortcut.
>
Where is the definitive information, in the headers, or the man pages?
And if in the latter, why bother with system headers: let compilers
simply invoke 'man xxx' behind the scenes and extract the relevant data.
Although if I do 'man struct stat', it gives me:
struct stat {
dev_t st_dev; /* ID of device containing file
ino_t st_ino; /* Inode number */
mode_t st_mode; /* File type and mode */
nlink_t st_nlink; /* Number of hard links */
uid_t st_uid; /* User ID of owner */
gid_t st_gid; /* Group ID of owner */
dev_t st_rdev; /* Device ID (if special file)
off_t st_size; /* Total size, in bytes */
blksize_t st_blksize; /* Block size for filesystem
blkcnt_t st_blocks; /* Number of 512B blocks
struct timespec st_atim; /* Time of last access */
struct timespec st_mtim; /* Time of last modification */
struct timespec st_ctim; /* Time of last status change
Now I only need to find out what hell dev_t, ino_t, mode_t, nlink_t,
uid_t, gid_t, off_t, blksize_t and (phew!) blkcnt_t are when they're at
home!
The question, if it's so simple (putting aside someone going absolutely
crazy with 'typedef's), why is/are the version/s inside the actual
headers so complex? And so hard to find? Why are there so many anyway.
Why don't those reasons apply equally to man pages?
Perhaps the people who write man pages should be writing system headers...
Here is my version for 64-bit Windows:
struct _stat {
unsigned int st_dev;
unsigned short st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
unsigned long st_rdev;
unsigned int st_size;
unsigned long long int st_atime;
unsigned long long int st_mtime;
unsigned long long int st_ctime;
};
#define stat _stat
I'd use u32 etc (based on uint32_t), but there are issues with making
stdint.h visible to programs that don't want it visible. So you have to
know here that 'long' is 32 bits, others are 16/32/64.
There's also a slight problem: if I write a program that prints
sizeof(struct stat) on 64-bit Windows, it shows 48.
Run the same program on 64-bit Linux, it shows 144. Oops. Even
disregarding those very different time fields, one shows 16, the other
24, and that 24 includes 2 bytes' padding between st_gid and st_rdev,
essential info if trying to recreate this struct layout from outside the
language.
Now perhaps you'll understand why your suggestion doesn't really work.
The man page is fine as a superficial description for someone coding in
C, who merely has to write '#include <sys/stat.h>' and has to worry
about nothing else.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-10-15 08:33 +1300 |
| Message-ID | <h0k0siFldqU18@mid.individual.net> |
| In reply to | #146970 |
On 15/10/2019 08:24, Bart wrote:
> On 14/10/2019 19:40, Ian Collins wrote:
>> On 15/10/2019 07:20, Bart wrote:
>
>> Read the man pages, that's what they are for.
>>
>>> Most people will not need to get that deeply involved, but I do, and I
>>> can see how ugly, badly patched and unreadable it all is, as well as
>>> sprawling. (Try and find struct stat inside sys/stat.h; it's not there!)
>>
>> It's described in the man page. Even if it wasn't, any IDE worth using
>> will find it wint one click of the mouse or a one key shortcut.
>>
>
> Where is the definitive information, in the headers, or the man pages?
Well that's just too silly a question to answer...
> And if in the latter, why bother with system headers: let compilers
> simply invoke 'man xxx' behind the scenes and extract the relevant data.
>
> Although if I do 'man struct stat', it gives me:
>
> struct stat {
> dev_t st_dev; /* ID of device containing file
> ino_t st_ino; /* Inode number */
> mode_t st_mode; /* File type and mode */
> nlink_t st_nlink; /* Number of hard links */
> uid_t st_uid; /* User ID of owner */
> gid_t st_gid; /* Group ID of owner */
> dev_t st_rdev; /* Device ID (if special file)
> off_t st_size; /* Total size, in bytes */
> blksize_t st_blksize; /* Block size for filesystem
> blkcnt_t st_blocks; /* Number of 512B blocks
>
> struct timespec st_atim; /* Time of last access */
> struct timespec st_mtim; /* Time of last modification */
> struct timespec st_ctim; /* Time of last status change
>
> Now I only need to find out what hell dev_t, ino_t, mode_t, nlink_t,
> uid_t, gid_t, off_t, blksize_t and (phew!) blkcnt_t are when they're at
> home!
gcc -E /usr/include/sys/stat.h | grep typedef
If you care about the fields in the structure, you should know what they
are!
> The question, if it's so simple (putting aside someone going absolutely
> crazy with 'typedef's), why is/are the version/s inside the actual
> headers so complex? And so hard to find? Why are there so many anyway.
How many platforms doe glibc get use on? How many platforms does your
version get used on?
> Now perhaps you'll understand why your suggestion doesn't really work.
>
> The man page is fine as a superficial description for someone coding in
> C, who merely has to write '#include <sys/stat.h>' and has to worry
> about nothing else.
The man page isn't a superficial, it's a thorough one!
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-14 20:52 +0100 |
| Message-ID | <Il4pF.1677282$HWr.469284@fx36.am4> |
| In reply to | #146972 |
On 14/10/2019 20:33, Ian Collins wrote: > On 15/10/2019 08:24, Bart wrote: >> Now I only need to find out what hell dev_t, ino_t, mode_t, nlink_t, >> uid_t, gid_t, off_t, blksize_t and (phew!) blkcnt_t are when they're at >> home! > > gcc -E /usr/include/sys/stat.h | grep typedef You have to compile it to unscramble it, OK (maybe there's an option to just display the sizes and offsets of each field suitable for assembly, and hence in a form adaptable to anything else). Doing that on Linux tells me that on Linux, there's YET ANOTHER layer of typedefs involved. And not all the relevant ones are present in that file. Further, what that doesn't show is that some typedefs are guarded - only defined if not already defined, so their actual definitions may be quite different. Apart from which, I work on Windows. > If you care about the fields in the structure, you should know what they > are! Why can't I find out just by looking at the struct definition? > How many platforms doe glibc get use on? How many platforms does your > version get used on? How about each platform only gets the customised version it needs? >> Now perhaps you'll understand why your suggestion doesn't really work. >> >> The man page is fine as a superficial description for someone coding in >> C, who merely has to write '#include <sys/stat.h>' and has to worry >> about nothing else. > > The man page isn't a superficial, it's a thorough one! Yet it doesn't contain the essential information I listed. Could you, just from that, create a table of field names, sizes and offsets, followed by a total struct size? And since this can vary by platform, how to get an accurate table for yours?
[toc] | [prev] | [next] | [standalone]
Page 4 of 25 — ← Prev page 1 2 3 [4] 5 6 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web