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 11 of 25 — ← Prev page 1 … 9 10 [11] 12 13 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-14 16:13 +0200 |
| Message-ID | <qo1vqs$lai$1@dont-email.me> |
| In reply to | #146922 |
On 13/10/2019 22:30, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I guess I don't really mean I want the types to be compatible - I mean
>> I want the result of casting from one pointer type to another to work
>> as though the types were compatible. (And in case it was missed, I am
>> only talking here about types where the size and representations are
>> the same.) I am not quite sure of the best term to describe it, nor
>> the best way to achieve it.
>
> It sounds like you want to loosen the effective type rules (6.5p6-7)
> so that an object whose effective type is an integer type can be
> accessed by an lvalue of another integer type that has the same
> representation, alignment, and perhaps some other characteristics.
That might be one way to think about it. I have certainly thought at
times that these rules are not quite ideal. Sometimes it would be
useful to have "alias anything" types of sizes other than "char". In
other cases, it would seem sensible to have types of the size of "char"
that can't alias other data. In other words, it seems to me that the
existing situation is a compromise that errs in both directions.
Maybe what I would like is an "unrestrict" keyword. (I am aware that
this would need a lot of work to specify sensibly - I am just playing
with ideas here.)
> (I suppose the same would apply to floating-point types, for
> example for implementations where double and long double have
> the same representation.) The types would still be incompatible,
> and pointer casts would still be needed.
>
> Such a change would inhibit some optimizations. For example:
>
> long x = 42;
> long long ptr = ...;
> /* a bunch of code that doesn't refer to x */
> if (x == 42) {
> /* ... */
> }
>
> Currently a compiler can assume that x has not been modified via ptr.
>
> I'm not sure whether such a change would be worth that cost.
I am not at all convinced that type-based alias analysis is of
significant benefit. It's easy enough to make artificial examples to
show it working - but a lot less easy to show real life code where it
makes a difference (i.e., where "gcc -O2" and "gcc -O2
-fno-strict-aliasing" give measurably different performance results).
This is, of course, speculative - I have no references or statistics to
back up my gut feeling here. But I think that in most cases where
type-based alias analysis could be used, other alias analysis will do
the job. In examples like your one above, if the compiler can see that
the address of "x" is never taken (or never escapes), which is the norm
for local variables, then it already knows "ptr" can't access it.
Conversely, in many cases where the programmer knows there can be no
aliasing but the compiler can't be sure, type-based analysis won't help
because the types are the same or typedefs of each other, and typedefs
do not affect compatibility.
Thus I don't believe the cost (in terms of performance or optimisations)
would be high.
>
> [...]
>> My main aim here is that there should be a standardised way to be sure
>> about that assumption.
>
> I'm not sure what that would look like, but ok. One possibility
> might be something like a C++-style cast, a conversion operator that
> would convert the pointer types but would be a constraint volation
> if the target types differ in representation. I don't think it's
> likely such a feature would be added without a lot more thought
> than I've put into it.
>
Certainly I agree that a lot of thought would be needed - whether the
solution be a C++ style cast, an "unrestrict" qualifier, or something
like gcc's "may_alias" type attribute. (While that attribute exists, I
don't think its semantics are specified clearly enough in the gcc
documentation.)
> [...]
>
>> I don't think my suggestion is as bad as it appeared to you, since I
>> would want the code to fail to compile when it would not work as
>> expected.
>
> My objection is that, given your previous suggestion, assigning a long*
> value to a long long* object would not be required to give a warning if
> long and long long happen to have the same representation *on the
> current system*. It would encourage non-portable code.
>
The alternative is today's solution - apply a cast. And it is likely
that this will mean no warning, even if the types /don't/ match in size.
This is even worse for making non-portable code - it gives you code
that fails silently on other platforms.
In addition, as we both know, even with a cast and the same size of
types, the result is not guaranteed to work (unless you have extra
compiler guarantees, such as with gcc -fno-strict-aliasing).
Surely it is possible to get better than a situation where the solution
is not portable, not guaranteed to work even when the sizes match, and
not guaranteed to give a warning or error when the sizes don't match
(and there is no hope of the code working correctly).
(I accept that the use-cases for this whole thing will typically be
rare, and thus careful programmers will place liberal static assertions
and compile-time checks in the code. But not all programmers are that
careful.)
> In C as it's currently defined, types can be distinct and incompatible
> even if they happen to have the same representation. I see this as a
> good thing. What's missing is a way to define new and distinct integer
> types.
I'd like that too. I want both!
> (And adding a way to do that could break a lot of uses of
> _Generic.)
>
The biggest failing of _Generic, as I see it, is that it is not
extensible. That is to say, there is no way to take an existing
_Generic macro and add new types to it. You can't even make a new
_Generic macro with a clause for your new type, and call the old one for
"default".
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-11 02:00 +0300 |
| Message-ID | <20191011020057.542258a4e1b59d0833a56ff9@gmail.com> |
| In reply to | #146832 |
David Brown: > People already rely on this accidental similarity -- the > similarity is in everything but the name. This is > particularly the case since compilers rarely complain > about these things by default -- you have to enable the > right warnings or flags. So my suggestion is that such > code that looks okay, has an obvious implementation, and > often appears to work fine, could then be re-classified as > "correct". Why then do you object to the same reasoning when it comes from Bart? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-11 10:33 +0200 |
| Message-ID | <qnpeo0$uvo$2@dont-email.me> |
| In reply to | #146862 |
On 11/10/2019 01:00, Anton Shepelev wrote: > David Brown: > >> People already rely on this accidental similarity -- the >> similarity is in everything but the name. This is >> particularly the case since compilers rarely complain >> about these things by default -- you have to enable the >> right warnings or flags. So my suggestion is that such >> code that looks okay, has an obvious implementation, and >> often appears to work fine, could then be re-classified as >> "correct". > > Why then do you object to the same reasoning when it comes > from Bart? > Primarily because the types are /not/ compatible in C. There is a huge difference between thinking that it could be convenient to have this change in the way C is defined, and writing code that relies on this change in C code today.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-10 01:01 -0700 |
| Message-ID | <afd25eab-3bfd-4746-a732-16bc57ba66a6@googlegroups.com> |
| In reply to | #146815 |
On Wednesday, 9 October 2019 19:32:07 UTC+1, David Brown wrote: > > It is only pointers to these types that lead to compatibility issues, > not the types themselves. But yes, you need to deal with this somehow. > Often I think it is a good idea to consider the fixed size types and > the base types as parallel sets of types - pick one set that is > appropriate for the type of code, and use it. > C integers are a joke. I've forgotten how many types there are in standard C, but I think it was something like forty. When the underlying hardware will support only 8, 16, 32, 64 maybe 128 bit.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-10 11:19 +0100 |
| Message-ID | <87tv8ggaxh.fsf@bsb.me.uk> |
| In reply to | #146828 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 9 October 2019 19:32:07 UTC+1, David Brown wrote: >> >> It is only pointers to these types that lead to compatibility issues, >> not the types themselves. But yes, you need to deal with this somehow. >> Often I think it is a good idea to consider the fixed size types and >> the base types as parallel sets of types - pick one set that is >> appropriate for the type of code, and use it. >> > C integers are a joke. I've forgotten how many types there are in > standard C, but I think it was something like forty. When the > underlying hardware will support only 8, 16, 32, 64 maybe 128 bit. That appears to be a deeply disingenuous remark. The number of integer types in C has almost nothing to do with the number of bit widths any one (or even all) hardware supports. You appear to be setting up a false comparison for purely rhetorical purposes. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 12:18 +0100 |
| Message-ID | <ysEnF.1045432$WI2.659809@fx34.am4> |
| In reply to | #146833 |
On 10/10/2019 11:19, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 9 October 2019 19:32:07 UTC+1, David Brown wrote:
>>>
>>> It is only pointers to these types that lead to compatibility issues,
>>> not the types themselves. But yes, you need to deal with this somehow.
>>> Often I think it is a good idea to consider the fixed size types and
>>> the base types as parallel sets of types - pick one set that is
>>> appropriate for the type of code, and use it.
>>>
>> C integers are a joke. I've forgotten how many types there are in
>> standard C, but I think it was something like forty. When the
>> underlying hardware will support only 8, 16, 32, 64 maybe 128 bit.
>
> That appears to be a deeply disingenuous remark. The number of integer
> types in C has almost nothing to do with the number of bit widths any
> one (or even all) hardware supports. You appear to be setting up a
> false comparison for purely rhetorical purposes.
Typically, for C on desktop and other consumer machines, C supports the
FOUR widths 8, 16, 32 and 64 bits, via the FIVE types char, short, int,
long, long long, none of which actually pin down their widths.
And ALSO via int8_t, int16_t, int32_t and int64_t.
Those original five are generally incompatible with each (as pointer
targets but also direct when using %d etc), even if they refer to the
same size type.
These four int8_t types etc may or may not compatible with any of those
four.
Looking at signed or unsigned types, then the 8-bit type 'char' has
THREE incompatible forms as pointer targets: char, unsigned char, and
signed char. Plus int8_t and uint8_t (now I'm starting to get lost)
If you know look at 128 bits, then you might have to use __int128_t,
with the two leading underscores.
You might say I'm trying to make it sound as complicated as possible -
that's because it is!
Hardware itself may support these types, although support for
intermediate sizes (eg. u16+u16) may be patchy:
i8 i16 i32 i64
u8 u16 u32 u64
f32 f64
p32 p64 (pointers, usually as i16* etc in a language)
It's still quite a family. A language may in addition have a special
'char' or other types defined on top of one of those hardware types, but
it seems to be mainly C (and C++ which has inherited it) that has ended
up with such an awful mess of a type system.
(Have I mentioned size_t yet? Or intleast32_t [sic] or intfast8_t or
intptr_t or wchar_t ...)
Others, like the Java, D, Go, Rust, C#, Scala and Kotlin I mentioned in
the my last post, seem to have managed to keep on top of the
proliferation of types.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-10 16:15 +0100 |
| Message-ID | <87mue8fx7b.fsf@bsb.me.uk> |
| In reply to | #146835 |
Bart <bc@freeuk.com> writes: > On 10/10/2019 11:19, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> On Wednesday, 9 October 2019 19:32:07 UTC+1, David Brown wrote: >>>> >>>> It is only pointers to these types that lead to compatibility issues, >>>> not the types themselves. But yes, you need to deal with this somehow. >>>> Often I think it is a good idea to consider the fixed size types and >>>> the base types as parallel sets of types - pick one set that is >>>> appropriate for the type of code, and use it. >>>> >>> C integers are a joke. I've forgotten how many types there are in >>> standard C, but I think it was something like forty. When the >>> underlying hardware will support only 8, 16, 32, 64 maybe 128 bit. >> >> That appears to be a deeply disingenuous remark. The number of integer >> types in C has almost nothing to do with the number of bit widths any >> one (or even all) hardware supports. You appear to be setting up a >> false comparison for purely rhetorical purposes. > > Typically, for C on desktop and other consumer machines, C supports > the FOUR widths 8, 16, 32 and 64 bits, via the FIVE types char, short, > int, long, long long, none of which actually pin down their widths. SIX types -- you've forgotten signed char. You are also putting aside (I'm sure you haven't forgotten) the unsigned integer types, which include another character type and _Bool which is not like any of the others. > And ALSO via int8_t, int16_t, int32_t and int64_t. And int_leastN_t, int_fastN_t for the various N along with the unsigned versions, though I see these get a mention later on. Don't forget size_t, wint_t, wchar_t, char16_t, char32_t, intptr_t, uintptr_t, intmax_t, uintmax_t and ptrdiff_t. You (and you are not alone in this) like to have it both ways. You like to complain that C does not have known-width integer types /and/ you like to complain that is has all those helpful known-width types as well. > Those original five are generally incompatible with each (as pointer > targets but also direct when using %d etc), even if they refer to the > same size type. Generally? They /are/ incompatible with each other, and that's got nothing to do with pointer types (though maybe that's the only time you notice). > These four int8_t types etc may or may not compatible with any of those four. > > Looking at signed or unsigned types, then the 8-bit type 'char' has > THREE incompatible forms as pointer targets: char, unsigned char, and > signed char. Plus int8_t and uint8_t (now I'm starting to get lost) You got lost at pointers. Forget pointers. If you actually want to know what makes two types compatible, you know how to find out. > If you know look at 128 bits, then you might have to use __int128_t, > with the two leading underscores. C permits all kinds of extensions. That's another quite separate advantage that it has. > You might say I'm trying to make it sound as complicated as possible - > that's because it is! No, you seem to have over-simplified the number of integer types, though you have certainly tried to confuse the notion of type compatibility. > (Have I mentioned size_t yet? Or intleast32_t [sic] or intfast8_t or > intptr_t or wchar_t ...) And the others... > Others, like the Java, D, Go, Rust, C#, Scala and Kotlin I mentioned > in the my last post, seem to have managed to keep on top of the > proliferation of types. Yes, they do (though Go has a lot more than you would probably like it to have). There are good reason why these languages have been able to avoid some of this complexity. However, as far as I can tell you choose to target C rather than, say, Scala. There's a reason for that. But in the end I don't know what the point of your post really was. It served only to confuse people learning C by (a) not explaining why C has these types, and (b) suggesting that compatibility is somehow linked to pointer types. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-10 15:32 +0000 |
| Message-ID | <qaInF.40136$KB2.35802@fx02.iad> |
| In reply to | #146840 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >Bart <bc@freeuk.com> writes: > >> Others, like the Java, D, Go, Rust, C#, Scala and Kotlin I mentioned >> in the my last post, seem to have managed to keep on top of the >> proliferation of types. > >Yes, they do (though Go has a lot more than you would probably like it >to have). There are good reason why these languages have been able to >avoid some of this complexity. > >However, as far as I can tell you choose to target C rather than, say, >Scala. There's a reason for that. Indeed, C has the inherent flexibility to make it convenient as an intermediate language. > >But in the end I don't know what the point of your post really was. It >served only to confuse people learning C by (a) not explaining why C has >these types, and (b) suggesting that compatibility is somehow linked to >pointer types. I fully expect that his point is to troll, with a thin veneer of legitimacy. > >-- >Ben. I was going through a box of old Sigops Operating Systems Review journals last night (cleaning out the attic) and ran across a synopsis of the second European SIGOPS Workshop "Making Distributed Systems Work" and found that I recognized the name of the presenter for a project called "ADMIRAL" and a "Sequenced Exchange Protocol" used for RPC in 1987. Sound familiar? (30 Kbytes/sec on 10M Ethernet doesn't seem much these days...) We started a distributed OS project the year after that, culminating in the Unisys OPUS circa 1995.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-10 21:03 +0100 |
| Message-ID | <87h84gfjw6.fsf@bsb.me.uk> |
| In reply to | #146841 |
scott@slp53.sl.home (Scott Lurndal) writes: > I was going through a box of old Sigops Operating Systems Review journals > last night (cleaning out the attic) and ran across a synopsis of the second > European SIGOPS Workshop "Making Distributed Systems Work" and found that > I recognized the name of the presenter for a project called "ADMIRAL" > and a "Sequenced Exchange Protocol" used for RPC in 1987. > > Sound familiar? (30 Kbytes/sec on 10M Ethernet doesn't seem much > these days...) That was indeed me. I was very pleased with the low latency we could achieve. The RPC implementation was originally mine and used UDP, but the SEP was mainly the work of Mark Riddoch and Jon Crowcroft. SEP had some nice ideas but it never really went anywhere. > We started a distributed OS project the year after that, culminating in > the Unisys OPUS circa 1995. I know (or rather knew) of it, but never in much detail. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-10 20:36 +0000 |
| Message-ID | <YCMnF.40091$1A2.19307@fx07.iad> |
| In reply to | #146850 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> We started a distributed OS project the year after that, culminating in >> the Unisys OPUS circa 1995. > >I know (or rather knew) of it, but never in much detail. Those were the days. SP2, TMC, Kendall Square Research, NCR (Teradata), Stratus, Tandem, et alia. The OPUS OS (SVr4/MK) was a message passing rewrite of SVR4/ESMP that ran on top of the Chorus microkernel[*]. The hardware had up to 64 Intel P6 processor nodes (each with CPU, 10mbit ethernet and a SCSI controller). We used the Intel Paragon wormhole routing backplane to link them into a mesh. The OS provided a single system image across all nodes to the operator and user. Shared memory between processes was supported using page-based coherency techniques (i.e. write protecting the page and conveying updates to the remote node on faults). Front panel of the machine had a wifty display showing message traffic between nodes, along with SCSI and network activity graphically (using discrete LEDs, not a graphics display). [*] Also used in the European Amadeus project with ICL, Fujitsu, USL, Unisys et alia. Primary ran OPS (Oracle Parallel Server) and Redbrick (data warehousing).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 17:16 +0100 |
| Message-ID | <1QInF.797536$aq7.506537@fx09.am4> |
| In reply to | #146840 |
On 10/10/2019 16:15, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> On 10/10/2019 11:19, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> C integers are a joke. I've forgotten how many types there are in
> SIX types -- you've forgotten signed char. You are also putting aside
> (I'm sure you haven't forgotten) the unsigned integer types,
I dealt with signed versions separately.
> You (and you are not alone in this) like to have it both ways. You like
> to complain that C does not have known-width integer types /and/ you
> like to complain that is has all those helpful known-width types as well.
They came too late;
the implementation is poor (often on top of the native types, raising
questions of compatibility);
they are not supported by matching formats (eg. "%lld"), or by constant
suffixes (eg. LL);
they are often not used, or they are mixed with the non-specific types,
giving problems when, for example, /you/ use the stdint.h types, but the
library you want to use doesn't;
(example: the C standard library still uses char, int, size_t (which is
defined in terms of unsigned long/long lint);
their names are ugly, leading people to define their own i32 or int32 or
top, or they do that anyway because until recently support for stdint.h
was still patchy.
>> Those original five are generally incompatible with each (as pointer
>> targets but also direct when using %d etc), even if they refer to the
>> same size type.
>
> Generally? They /are/ incompatible with each other
Yes, even when int and long are the same size. (BTW in my compiler,
which is for Windows, long is a synonym for int, so they /are/ compatible.)
> You got lost at pointers. Forget pointers.
No, pointers is where it becomes important. Because you can assign a
long to an int, but not a long* to an int*.
> C permits all kinds of extensions. That's another quite separate
> advantage that it has.
But the user sees these types, among others:
int 32 bits
long long 64 bits
__int128_t 128 bits
Or int32_t, int64_t and __int128_t; there is a lack of consistency. (Why
didn't stdint.h reserve 'int128_t'?)
> to have). There are good reason why these languages have been able to
> avoid some of this complexity.
So you're admitting there is complexity?
> However, as far as I can tell you choose to target C rather than, say,
> Scala. There's a reason for that.
Normally I don't target C at all (it has been pdp10, z80, 8086, 80386,
x64 and soon it might be aarch64).
I'm familiar with C since I needed to start using C APIs in the 90s, and
still need to use them. I've tried Go, Rust etc but they are rather
heavyweight and unwieldy (as well as unyielding).
I'm choosing C now to work on Linux (which comes with a C compiler)
; to benefit from an optimiser on either OS; and to be able to use the
fast tcc. I don't know how well Scala would help with that.
> But in the end I don't know what the point of your post really was.
I was supporting Malcolm's remark.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-11 03:25 +0100 |
| Message-ID | <875zkwf27e.fsf@bsb.me.uk> |
| In reply to | #146842 |
Bart <bc@freeuk.com> writes: > On 10/10/2019 16:15, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: ... >>> Those original five are generally incompatible with each (as pointer >>> targets but also direct when using %d etc), even if they refer to the >>> same size type. >> >> Generally? They /are/ incompatible with each other > > Yes, even when int and long are the same size. Yes. > (BTW in my compiler, which is for Windows, long is a synonym for int, > so they /are/ compatible.) Your compiler is for a language not entirely unlike C. You can do what you like in that language. >> You got lost at pointers. Forget pointers. > > No, pointers is where it becomes important. Because you can assign a > long to an int, but not a long* to an int*. It becomes important when you want to know what types are compatible. You suggested that there were various sorts of compatibility. There is no "incompatible as pointer targets" just compatible or not. (And the remark about "direct when using %d etc" is just completely wide of the mark.) >> ... There are good reason why these languages have been able to >> avoid some of this complexity. > > So you're admitting there is complexity? No, I am stating that there is. (One is a fact that can be inferred from my words, the other is your spin on that fact.) >> But in the end I don't know what the point of your post really was. > > I was supporting Malcolm's remark. After "C integers are a joke" he made three further remarks which are correct (or not reasonably deniable): "I've forgotten how many types there are in standard C," "I think it was something like forty" "the underlying hardware will support only 8, 16, 32, 64 maybe 128 bit" so presumably you are supporting the first. I don't think you offered any support for the view that C's integers are a joke. C is wildly successful, in large part /because/ of the things you complain about here. That makes the design very serious indeed and not at all "a joke". If you meant that you were supporting his overall argument (that it's ridiculous for C to have so many integer types when the hardware doesn't) you offered no support for that either. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2019-10-10 22:36 -0700 |
| Message-ID | <2f22e8a3-fe63-4002-94d7-fbb4b4369b3e@googlegroups.com> |
| In reply to | #146866 |
On Thursday, October 10, 2019 at 7:25:35 PM UTC-7, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > > > On 10/10/2019 16:15, Ben Bacarisse wrote: > >> Bart <bc@freeuk.com> writes: > ... > >>> Those original five are generally incompatible with each (as pointer > >>> targets but also direct when using %d etc), even if they refer to the > >>> same size type. > >> > >> Generally? They /are/ incompatible with each other > > > > Yes, even when int and long are the same size. > > Yes. > > > (BTW in my compiler, which is for Windows, long is a synonym for int, > > so they /are/ compatible.) > > Your compiler is for a language not entirely unlike C. You can do what > you like in that language. > > >> You got lost at pointers. Forget pointers. > > > > No, pointers is where it becomes important. Because you can assign a > > long to an int, but not a long* to an int*. > > It becomes important when you want to know what types are compatible. > You suggested that there were various sorts of compatibility. There is > no "incompatible as pointer targets" just compatible or not. (And the > remark about "direct when using %d etc" is just completely wide of the > mark.) > > >> ... There are good reason why these languages have been able to > >> avoid some of this complexity. > > > > So you're admitting there is complexity? > > No, I am stating that there is. (One is a fact that can be inferred > from my words, the other is your spin on that fact.) > > >> But in the end I don't know what the point of your post really was. > > > > I was supporting Malcolm's remark. > > After "C integers are a joke" he made three further remarks which are > correct (or not reasonably deniable): > > "I've forgotten how many types there are in standard C," > "I think it was something like forty" > "the underlying hardware will support only 8, 16, 32, 64 maybe 128 bit" > > so presumably you are supporting the first. > > I don't think you offered any support for the view that C's integers are > a joke. C is wildly successful, in large part /because/ of the things > you complain about here. That makes the design very serious indeed and > not at all "a joke". > > If you meant that you were supporting his overall argument (that it's > ridiculous for C to have so many integer types when the hardware > doesn't) you offered no support for that either. > > -- > Ben. I've been working with an abstract data space of an infinite number of bits mapped in the obvious way onto the non-negative integers. Then each datum is defined by two non-negative integers - a starting bit in the bit space and a length in bits. A type, in this abstract, has a length attribute (and more attributes to give it meaning - like signed = 0/1). That is signed is a boolean - 0 if not specified and 1 if specified. A binary operation has attribute type = a function returning a type using the two operation argument types as arguments. And then the type of the outcome datum is that type and its length the type.length. I believe that this is a true generalization of the situation in C. That is, it can be restricted down to C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-11 12:10 +0100 |
| Message-ID | <FqZnF.2707959$dw4.1762701@fx12.am4> |
| In reply to | #146866 |
On 11/10/2019 03:25, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> I was supporting Malcolm's remark.
>
> After "C integers are a joke" he made three further remarks which are
> correct (or not reasonably deniable):
>
> "I've forgotten how many types there are in standard C,"
> "I think it was something like forty"
> "the underlying hardware will support only 8, 16, 32, 64 maybe 128 bit"
>
> so presumably you are supporting the first.
>
> I don't think you offered any support for the view that C's integers are
> a joke.
40 integer types (I counted exactly 40 plus those below), for the 8
common hardware types, with varying degrees of compatibility. Each with
special macros for their MAX and INT values; with special provision
(maybe) for printf format codes; and with special provision (maybe) for
writing literals for those types.
Plus, in the standard library, usage of types like clock_t, time_t,
char16_t, char32_t, errno_t, rsize_t, ssize_t, constraint_handler_t,
max_align_t etc etc. (I've no idea how many of these there are; it seems
that using just a plain int is abhorrent.)
Plus the Atomic_* integer types. Plus there is whatever type an enum is.
So, you could regard that collection as a 'joke'. (Try using Generic;
sometimes 'uint64_t' will clash with 'unsigned long long int', sometimes
it won't.)
How would a language deal with such an array of types, if it is to
support explicit hardware types? I'm not going to look at all those
other languages in detail. But with mine it uses these types:
10 hardware types (i8 to u128)
2 char types (like their u- equivalents with extra properties), but
are anyway /always/ unsigned.
4 types that each map to one of i32/u32/i64/u64 depending on
target machine size (might reduce these to 2)
Some aliases (int->i64, word->u64, byte->u8)
Allows either i32-style or int32-style naming preference
Enums always have int type
MIN/MAX values, and printing of these types, are taken of by the
language (x.minvalue, u64.maxvalue, print y).
How does that look? Would this lot be considered a joke?
If you saw one of my function signatures, there would be doubt as to
what its parameter types are. (A 'doc-string' feature I used to have
would anyway output function signatures - plus the doc-string - in
normalised form.)
> If you meant that you were supporting his overall argument (that it's
> ridiculous for C to have so many integer types when the hardware
> doesn't) you offered no support for that either.
It's just common sense. Some extra types may need to be defined on top,
with special properties, but the set of types in C /is/ ridiculous.
Especially when there is no proper support for MIN/MAX and printf; it
needs extensive enumerations of dedicated macros.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-12 00:26 +0100 |
| Message-ID | <87a7a66eyk.fsf@bsb.me.uk> |
| In reply to | #146873 |
Bart <bc@freeuk.com> writes: > On 11/10/2019 03:25, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> I was supporting Malcolm's remark. >> >> After "C integers are a joke" he made three further remarks which are >> correct (or not reasonably deniable): >> >> "I've forgotten how many types there are in standard C," >> "I think it was something like forty" >> "the underlying hardware will support only 8, 16, 32, 64 maybe 128 bit" >> >> so presumably you are supporting the first. > >> >> I don't think you offered any support for the view that C's integers are >> a joke. > > 40 integer types (I counted exactly 40 plus those below), for the 8 > common hardware types, with varying degrees of compatibility. No, no, no. Numbers alone don't make an argument. When people say that something is a joke they mean it is not to be taken seriously -- that it's frivolous or silly. You would need to show that the emergence of all these types are not the result of a very serious, and successful, endeavour indeed -- to keep C as one of the most widely used programming languages ever. >> If you meant that you were supporting his overall argument (that it's >> ridiculous for C to have so many integer types when the hardware >> doesn't) you offered no support for that either. > > It's just common sense. Ah. Am I allowed to say that of my point of view? If so, consider it said. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-12 00:44 +0100 |
| Message-ID | <tt8oF.2726927$dw4.1608272@fx12.am4> |
| In reply to | #146882 |
On 12/10/2019 00:26, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> >> 40 integer types (I counted exactly 40 plus those below), for the 8 >> common hardware types, with varying degrees of compatibility. > > No, no, no. Numbers alone don't make an argument. How many types does it need then for /you/ to consider such a language a joke? If there were 10 times as many, the language designers can't be serious, right? (Apparently there aren't enough types in C for some; I lost count but there must be at least 150 here: https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types) When people say that > something is a joke they mean it is not to be taken seriously -- that > it's frivolous or silly. You would need to show that the emergence of > all these types are not the result of a very serious, and successful, > endeavour indeed -- to keep C as one of the most widely used programming > languages ever. It has certainly got itself ensconced. Then you look deep into the innards of C system headers and it makes you want to cry. This ghastly mess underpins much of the world's computer systems; seriously? It is actually somewhat worrying. >>> If you meant that you were supporting his overall argument (that it's >>> ridiculous for C to have so many integer types when the hardware >>> doesn't) you offered no support for that either. >> >> It's just common sense. > > Ah. Am I allowed to say that of my point of view? If so, consider it said. So what technical proof is necessary to consider that a language's treatment of types is over the top, or messy or unwieldy? If it's not possible with logic, then you have to use judgement. Judgement not swayed by the fact that a language is widely used. (That fact may affect how much you can about it.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-12 12:18 +0200 |
| Message-ID | <qns9a4$rmq$1@dont-email.me> |
| In reply to | #146883 |
On 12/10/2019 01:44, Bart wrote: > On 12/10/2019 00:26, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> >>> 40 integer types (I counted exactly 40 plus those below), for the 8 >>> common hardware types, with varying degrees of compatibility. >> >> No, no, no. Numbers alone don't make an argument. > > How many types does it need then for /you/ to consider such a language a > joke? If there were 10 times as many, the language designers can't be > serious, right? Wrong. > > (Apparently there aren't enough types in C for some; I lost count but > there must be at least 150 here: > https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types) > I wonder if you understand what a "type" is in programming. I think perhaps you are only considering simple, concrete assembly-level data sizes - you seem to think that "type" means "number of bits in an indivisible unit of data". > > When people say that >> something is a joke they mean it is not to be taken seriously -- that >> it's frivolous or silly. You would need to show that the emergence of >> all these types are not the result of a very serious, and successful, >> endeavour indeed -- to keep C as one of the most widely used programming >> languages ever. > > It has certainly got itself ensconced. Then you look deep into the > innards of C system headers and it makes you want to cry. This ghastly > mess underpins much of the world's computer systems; seriously? It is > actually somewhat worrying. > It's a good job there are people who understand C looking after it all. > > >>>> If you meant that you were supporting his overall argument (that it's >>>> ridiculous for C to have so many integer types when the hardware >>>> doesn't) you offered no support for that either. >>> >>> It's just common sense. >> >> Ah. Am I allowed to say that of my point of view? If so, consider it >> said. > "Common sense is nothing more than a set of prejudices learned up to the age of eighteen." > So what technical proof is necessary to consider that a language's > treatment of types is over the top, or messy or unwieldy? If it's not > possible with logic, then you have to use judgement. > > Judgement not swayed by the fact that a language is widely used. (That > fact may affect how much you can about it.) > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-12 12:42 +0100 |
| Message-ID | <6%ioF.849405$893.123190@fx02.am4> |
| In reply to | #146886 |
On 12/10/2019 11:18, David Brown wrote: > On 12/10/2019 01:44, Bart wrote: >> How many types does it need then for /you/ to consider such a language >> a joke? If there were 10 times as many, the language designers can't >> be serious, right? > > Wrong. Would you design a new language with same collection of vaguely defined types just like C? I guess not. C's zoo of types is one thing that hasn't much been copied by anything else. > I wonder if you understand what a "type" is in programming. I think > perhaps you are only considering simple, concrete assembly-level data > sizes - you seem to think that "type" means "number of bits in an > indivisible unit of data". Did you look at that link? 30 of those types are just endless synonyms for the i8 i16 i32 i64 u8 u16 u32 u64 types, with no special meaning. Dozens more are named pointer types to those 30, or to char or other types. > It's a good job there are people who understand C looking after it all. Or, from looking at system headers, people who have no idea about them except how to apply patch on top of patch to keep that precarious bunch of code ticking over. A bit like those people in Cuba keeping those 1950s cars working. > "Common sense is nothing more than a set of prejudices learned up to the > age of eighteen." I didn't use a computer or do any programming until I was 19, so I can't have had any preconceived opinions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-12 15:00 +0200 |
| Message-ID | <qnsipf$h1a$1@dont-email.me> |
| In reply to | #146890 |
On 12/10/2019 13:42, Bart wrote: > On 12/10/2019 11:18, David Brown wrote: >> On 12/10/2019 01:44, Bart wrote: > >>> How many types does it need then for /you/ to consider such a >>> language a joke? If there were 10 times as many, the language >>> designers can't be serious, right? >> >> Wrong. > > Would you design a new language with same collection of vaguely defined > types just like C? > > I guess not. C's zoo of types is one thing that hasn't much been copied > by anything else. Many newer programming languages have more ways to make new types than C, and stronger typing. Certainly if I were designing a new language, I'd have a way to make new integer types that were not implicitly convertible back or forth with other integer types. I'd expect to go through a lot more types defined in my code than I do in C programming (and in C, my programs can easily have 50-100 typedefs). What makes C typing a little unusual is that it is designed to support such a range of possible target systems - that leads to it having a large number of basic types with different characteristics, letting people pick the types they want to suit their needs. Languages that have more fixed requirements (such as requiring a 32-bit target with 64-bit support) can let them simplify things. There are use-cases for languages with different typing systems. Some people prefer stronger type systems (I do). Others like weaker type systems or typeless languages - clearly your preferences are more in that direction. C is a language that is sort of in the middle in regards to typing. > >> I wonder if you understand what a "type" is in programming. I think >> perhaps you are only considering simple, concrete assembly-level data >> sizes - you seem to think that "type" means "number of bits in an >> indivisible unit of data". > > Did you look at that link? 30 of those types are just endless synonyms > for the i8 i16 i32 i64 u8 u16 u32 u64 types, with no special meaning. They /do/ have special meanings - there are reasons for having synonyms. > > Dozens more are named pointer types to those 30, or to char or other types. Again, those are useful. A "widget handle" might be implemented as an integer but if you call it a "widget_handle_t", then code becomes clearer to read and easier to write correctly. It also becomes more portable to a system that wants to implement widget handles as pointers to a struct, or something else entirely. > >> It's a good job there are people who understand C looking after it all. > > Or, from looking at system headers, people who have no idea about them > except how to apply patch on top of patch to keep that precarious bunch > of code ticking over. > > A bit like those people in Cuba keeping those 1950s cars working. > >> "Common sense is nothing more than a set of prejudices learned up to >> the age of eighteen." > > I didn't use a computer or do any programming until I was 19, so I can't > have had any preconceived opinions. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-12 15:29 +0100 |
| Message-ID | <VqloF.2765410$dw4.2477092@fx12.am4> |
| In reply to | #146892 |
On 12/10/2019 14:00, David Brown wrote:
> On 12/10/2019 13:42, Bart wrote:
>> I guess not. C's zoo of types is one thing that hasn't much been
>> copied by anything else.
>
> Many newer programming languages have more ways to make new types than
> C, and stronger typing.
It's not even about new types, but the same type. The generic int32 type
can be represented in most desktop Cs as:
int, long (sometimes) long long (possible?) int32_t
C implementations may contain their own internal versions (eg. __int32)
MS additionally defines INT, INT32, LONG, LONG32 for that type.
SDL uses Sint32; Opengl has GLint; GTK has gint32; STB uses stb__int32
Seed7 uses INT32TYPE and int32Type.
SQLite doesn't have signed int32, but uses UINT32_TYPE and u32
What is it about C that makes every program want to define its own
version of the basic types? (And I do the same in C!)
C has poor support for such type aliases so their uses should be kept to
a minimum.
Given integer type aliases T and U, what type will T*U be? What is the
MIN and MAX values of T or U? What format code should be used for T or
U? What size of literal will they accommodate? Will it need an L or LL
suffix? Are T* and U* compatible? Will I lose info storing a U type into
a T type?
Certainly if I were designing a new language,
> I'd have a way to make new integer types that were not implicitly
> convertible back or forth with other integer types. I'd expect to go
> through a lot more types defined in my code than I do in C programming
> (and in C, my programs can easily have 50-100 typedefs).
One 45Kloc project of mine uses exactly two numeric user types (plus two
dozen to do with defining versions of the MS Windows types so that I can
declare WinAPI functions).
This is partly because the language provides a solid and reliable set of
basic types, whose names are not too objectionable and are consistent.
> What makes C typing a little unusual is that it is designed to support
> such a range of possible target systems - that leads to it having a
> large number of basic types with different characteristics, letting
> people pick the types they want to suit their needs. Languages that
> have more fixed requirements (such as requiring a 32-bit target with
> 64-bit support) can let them simplify things.
Power-of-two types can be easily accommodated. Then you just have to
choose whether 'int', and default calculations, use 8, 16, 32 or 64
bits, and whether it's worth supporting 64 or possibly 32-bit ops.
> There are use-cases for languages with different typing systems. Some
> people prefer stronger type systems (I do). Others like weaker type
> systems or typeless languages - clearly your preferences are more in
> that direction. C is a language that is sort of in the middle in
> regards to typing.
I see any strongly enforced scheme or user numeric types heading in the
direction of Ada, which makes my kind of casual programming difficult.
Since we are talking about low-level languages, we can use low-level types.
>> Dozens more are named pointer types to those 30, or to char or other
>> types.
>
> Again, those are useful.
Sorry, no. Your job, when trying to call any of the plethora of WinAPI
functions from your own language, and therefore have to painstakingly
recreate every function in that language, is whether any pointer type is
one of these:
i8* i16* i32* i64*
u8* u16* u32* u64*
void*
Most of the time a void* will do. The actual thing that is passed will
be a 32-bit address, or 64-bit address, depending on machine.
All those Long-pointer-to-string types are a waste of time.
[toc] | [prev] | [next] | [standalone]
Page 11 of 25 — ← Prev page 1 … 9 10 [11] 12 13 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web