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 15 of 25 — ← Prev page 1 … 13 14 [15] 16 17 … 25 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-13 23:10 +0100 |
| Message-ID | <mhNoF.1056983$_w5.24793@fx31.am4> |
| In reply to | #146923 |
On 13/10/2019 22:18, Malcolm McLean wrote: > On Sunday, 13 October 2019 00:12:44 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> This is an argument that there /is/ a flaw. I think it is both >> well-known and almost universally accepted. Which "proposers" do you >> think are unaware of this flaw? >> > Someone agreed to create a language with forty general-purpose integer > types, as standard. I don't know who supported and who resisted this, > but clearly there were enough supporters to get their way. I guess they didn't start with that intent, but that's how it ended up. This is a good summary: https://en.wikipedia.org/wiki/C_data_types This lists 11 basic integer types, with 26 unique possible denotations (or 92 if permutations are counted). The widths/ranges of the types can coincide or overlap. The box with the fixed-with types represents 28 more types. With ptrdiff_t and size_t, that makes just over 40. Many of these latter can, I think, coincide as actual types with others in the fixed-width group. And many can coincide with the 11 basic types. In my generated code, I use just 8 types, i8 to u64, and it works fine. (Before I wrote this post, I had used 9, included a separate 'byte' type, but decided I didn't need that. Maybe more people should do that sort of reduction.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-14 23:52 -0400 |
| Message-ID | <3obpF.121293$LC2.25145@fx45.iad> |
| In reply to | #146925 |
On 10/13/19 6:10 PM, Bart wrote: > On 13/10/2019 22:18, Malcolm McLean wrote: >> On Sunday, 13 October 2019 00:12:44 UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>> This is an argument that there /is/ a flaw. I think it is both >>> well-known and almost universally accepted. Which "proposers" do you >>> think are unaware of this flaw? >>> >> Someone agreed to create a language with forty general-purpose integer >> types, as standard. I don't know who supported and who resisted this, >> but clearly there were enough supporters to get their way. > > I guess they didn't start with that intent, but that's how it ended up. > > This is a good summary: > > https://en.wikipedia.org/wiki/C_data_types > > This lists 11 basic integer types, with 26 unique possible denotations > (or 92 if permutations are counted). The widths/ranges of the types can > coincide or overlap. > > The box with the fixed-with types represents 28 more types. With > ptrdiff_t and size_t, that makes just over 40. > > Many of these latter can, I think, coincide as actual types with others > in the fixed-width group. And many can coincide with the 11 basic types. > > > In my generated code, I use just 8 types, i8 to u64, and it works fine. > > (Before I wrote this post, I had used 9, included a separate 'byte' > type, but decided I didn't need that. Maybe more people should do that > sort of reduction.) May be if you would learn to count properly. C has 11 standard integer types. PERIOD. Many have multiple spellings because the keyword int is optional if there is a modifier, and signed is optional for all types except char, as it is assumed. These alternate spellings do not create new types. There are then a number of alias, like ptrdiff_t and size_t that will alias one of those basic types to represent ideas that might map to different types on different machines. For instance, on some machines, unsigned int is big enough to hold the size of any object, while on others it isn't so size_t needs to be made unsigned long. I guess since your language doesn't have a type like this, you either need to change you programs if you move them to machines with different addressing characteristics or you must waste a lot of space on small machines (when memory can be precious). The fixed width sizes also will be aliases for the standard integer types (it is a bit difficult to make them not aliases, as their names are not reserved for the implementation if stdint.h is not included) If a machine needs more that 5 fundamental integer sizes, then the Standard allows the implementation to create 'extended integer types' to provide more types. These will tend to have a name like __int128 (something in the namespace reserved for the implementation with the __) and perhaps given a more normal name via a header like stdint.h The difference between 8 and 11 isn't that big, and the biggest part of the difference is you don't have types that scale with your machine, so a portable program needs to either bog down the 16 bit machine doing lots of unneeded arithmetic, or hobble the 64 bit machine with having to deal with small sized numbers that it might not handle well.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-15 11:48 -0400 |
| Message-ID | <qo4pnh$ad6$1@dont-email.me> |
| In reply to | #146983 |
On 10/14/19 11:52 PM, Richard Damon wrote:
> On 10/13/19 6:10 PM, Bart wrote:
...
>> I guess they didn't start with that intent, but that's how it ended up.
>>
>> This is a good summary:
>>
>> https://en.wikipedia.org/wiki/C_data_types
>>
>> This lists 11 basic integer types, with 26 unique possible denotations
>> (or 92 if permutations are counted). The widths/ranges of the types can
>> coincide or overlap.
>>
>> The box with the fixed-with types represents 28 more types. With
>> ptrdiff_t and size_t, that makes just over 40.
>>
>> Many of these latter can, I think, coincide as actual types with others
>> in the fixed-width group. And many can coincide with the 11 basic types.
...> May be if you would learn to count properly.
>
> C has 11 standard integer types. PERIOD. Many have multiple spellings
> because the keyword int is optional if there is a modifier, and signed
> is optional for all types except char, as it is assumed. These alternate
> spellings do not create new types.
>
> There are then a number of alias, like ptrdiff_t and size_t that will
> alias one of those basic types to represent ideas that might map to
ptrdiff_t and size_t are both allowed to be typedefs for extended
integer types.
The standard headers define many more types than just those two that
could, in principle, each be a typedef for a distinct extended integer type:
error_t
fenv_t
fexcept_t
sig_atomic_t
max_align_t
wchar_t
fpos_t
cnd_t
thrd_t
tss_t
mtx_t
clock_t
time_t
mbstate_t
wint_t
wctrans_t
wctype_t
> The fixed width sizes also will be aliases for the standard integer
> types (it is a bit difficult to make them not aliases, as their names
> are not reserved for the implementation if stdint.h is not included)
The fixed-size types are also allowed to be typedefs for extended
integer types. Not only is there no prohibition on doing so, but
footnote 261 exists solely for the purpose of pointing out that possibility.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-15 18:14 +0100 |
| Message-ID | <C7npF.849967$665.317301@fx28.am4> |
| In reply to | #146983 |
On 15/10/2019 04:52, Richard Damon wrote:
> On 10/13/19 6:10 PM, Bart wrote:
>> https://en.wikipedia.org/wiki/C_data_types
>>
>> This lists 11 basic integer types, with 26 unique possible denotations
>> (or 92 if permutations are counted). The widths/ranges of the types can
>> coincide or overlap.
> May be if you would learn to count properly.
>
> C has 11 standard integer types. PERIOD.
Didn't I say that above?
Many have multiple spellings
> because the keyword int is optional if there is a modifier, and signed
> is optional for all types except char, as it is assumed. These alternate
> spellings do not create new types.
Yet, the article is longer that it could be because of the extra
complications, the extra types, all the types that may or may not be
compatible, the open-ended ranges, the headaches of figuring out the
correct format code, whether to use ULL or some other suffix, /needing/
to use stdint/inttypes.h just to use int32 type...
Imagine trying to explain all that to a beginner.
> There are then a number of alias, like ptrdiff_t and size_t that will
> alias one of those basic types to represent ideas that might map to
> different types on different machines. For instance, on some machines,
> unsigned int is big enough to hold the size of any object, while on
> others it isn't so size_t needs to be made unsigned long.
>
> I guess since your language doesn't have a type like this,
I have those; I use them mainly for interfacing to external APIs and
external structs otherwise they are not really used in programs.
you either
> need to change you programs if you move them to machines with different
> addressing characteristics or you must waste a lot of space on small
> machines (when memory can be precious).
>
> The fixed width sizes also will be aliases for the standard integer
> types (it is a bit difficult to make them not aliases, as their names
> are not reserved for the implementation if stdint.h is not included)
They are sometimes defined on top of internal types (eg. __INT32) not
exposed to user programs.
> The difference between 8 and 11 isn't that big, and the biggest part of
> the difference is you don't have types that scale with your machine, so
> a portable program needs to either bog down the 16 bit machine doing
> lots of unneeded arithmetic, or hobble the 64 bit machine with having to
> deal with small sized numbers that it might not handle well.
I now only target 64-bit machines, since most hardware now, outside of
David Brown's microcontrollers, is 64-bit. Some OSes are still 32-bit,
and 64-bit ints will run a bit slower, but that's more incentive to
hurry up and do proper 64-bit OSes.
No point in targeting something that will rapidly become obsolete.
The types I support at present are these:
Basic Integer Types:
int8 = i8 Signed
int16 = i16
int32 = i32
int = int64 = i64
int128 = i128
byte = word8 = u8 Unsigned
word16 = u16
word32 = u32
word = word64 = u64
word128 = u128
char = c8
c16 or c32 (reserved for Unicode)
c64
Machine types, depend on target word/ptr sizes:
intm = int32 or int64
wordm = word32 or word64
intp = int32 or int64
wordp = word32 or word64
(c64 is a consequence of widening operands to 64 bits, but is an
internal type not used in code. char types are distinct and behave a
little differently:
print 'A'
displays A, not 64)
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-15 20:31 +0300 |
| Message-ID | <20191015203147.c43ecd4463b193def5322005@g{oogle}mail.com> |
| In reply to | #146996 |
Bart: >Yet, the article is longer that it could be because of the >extra complications, the extra types, all the types that >may or may not be compatible, -> It is easy. Consider them incompatible in formally correct C, and do not assume compatibilty unless you want your program tied to a platform/compiler combiantion where they happen to be compatible. >-> the open-ended ranges, the headaches of figuring out the >correct format code, whether to use ULL or some other >suffix, /needing/ to use stdint/inttypes.h just to use >int32 type... Including a header with a defintion of type, function, or macro is the standard way of code reuse. It is not at all difficult I don't want the new derivative fixed-widht types to be always in scope if I am writing a program in classic C. >Imagine trying to explain all that to a beginner. That is possible. Start from C's native types and why they are desinged as they are, then switch to fixed-width type. >I now only target 64-bit machines, since most hardware now, >outside of David Brown's microcontrollers, is 64-bit. Some >OSes are still 32-bit, and 64-bit ints will run a bit >slower, but that's more incentive to hurry up and do proper >64-bit OSes. > >No point in targeting something that will rapidly become >obsolete. C is excellent is that I can compile and run C programs on any machine, but I wanted to use your compiler I should be forced to buy a new computer and a new OS, whereas my current one in working and feeling well? My current machine is based on a old AMD APU and runs under 32-bit Windows XP. I am not wont to change computers as some people a changing their smartphone to keep in trend. -- () 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-15 20:11 +0100 |
| Message-ID | <_RopF.1541063$TW.1154625@fx03.am4> |
| In reply to | #146997 |
On 15/10/2019 18:31, Anton Shepelev wrote:
>
>> Imagine trying to explain all that to a beginner.
>
> That is possible. Start from C's native types and why they
> are desinged as they are, then switch to fixed-width type.
Possible, but if it was your job, I bet you wished the language was
/much/ simpler!
You're looking here at decades of baggage, and patching of the type
system. There's no reason to inflict that on anyone now.
>> No point in targeting something that will rapidly become
>> obsolete.
>
> C is excellent is that I can compile and run C programs on
> any machine, but I wanted to use your compiler I should be
> forced to buy a new computer and a new OS, whereas my
> current one in working and feeling well?
Tell me where I can buy a 64-bit desktop or laptop machine. The last
time I managed it was a decade ago.
> My current machine
> is based on a old AMD APU and runs under 32-bit Windows XP.
As it happens, my 64-bit-centric compiler can generate code to run on
32-bit Windows and Linux, by generating 32-bit C (C with some 32-bit
assumptions). That's thanks to the work I did last month (when I
discovered that my new 64-bit RPi4 mostly still runs 32-bit OSes).
But you can try it for yourself; download my (non-C) compiler:
https://github.com/sal55/qx/blob/master/mc32.c
(The 'mc32' designation means it generates Windows/C32 code, and here
was applied to itself so that it is itself Windows/C32 code - yeah this
bit gets confusing...)
Compile it (on XP-32 you won't need -m32, but will need gcc):
gcc mc32.c -omc.exe
Now type in a basic test, "prog.m":
proc start=
println "Hello, World"
println int.maxvalue
end
Compile (this will generate intermediate C in prog.c, and invoke gcc):
mc prog
And run it:
prog
------------------------------------------------
If that works, you can try in on a bigger program; download these two files:
https://github.com/sal55/qx/blob/master/pidigits.m
https://github.com/sal55/qx/blob/master/mbignum.m
Build that project:
mc pidigits
And run:
pidigits 1000
(Calculate pi to N digits.) If that works, then congratulations, you're
running my 64-bit language on your 32-bit XP, even though its compiler
doesn't natively support 32 bits.
(If there's a problem invoking gcc automatically (it gave some problems
running CreateProcess on 32-bit Windows in C; I switched to system()),
or it doesn't like -m32, try it in two steps:
mc -c prog
gcc prog.c -oprog.exe
Note my gcc doesn't work with -m32, I had to test with tcc (mc prog -tcc).)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-15 20:34 +0100 |
| Message-ID | <ubppF.2938587$xm3.407877@fx15.am4> |
| In reply to | #146999 |
On 15/10/2019 20:11, Bart wrote: > > Tell me where I can buy a 64-bit desktop or laptop machine. The last > time I managed it was a decade ago. I mean, 32-bit machines, other than second-hand.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-15 22:05 +0200 |
| Message-ID | <qo58r0$avl$1@dont-email.me> |
| In reply to | #147000 |
On 15/10/2019 21:34, Bart wrote: > On 15/10/2019 20:11, Bart wrote: > >> >> Tell me where I can buy a 64-bit desktop or laptop machine. The last >> time I managed it was a decade ago. > > I mean, 32-bit machines, other than second-hand. The last 32-bit x86 PC I bought was about 2 weeks ago. It was an Intel Compute Stick - so a rather small computer, but powerful enough for its job of displaying a information screen webpage on a large monitor. It came with 32-bit Windows 10.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-15 13:27 -0700 |
| Message-ID | <683baeca-3bcd-4e8a-9a9c-e0c0cf4db041@googlegroups.com> |
| In reply to | #147002 |
On Tuesday, October 15, 2019 at 11:06:00 PM UTC+3, David Brown wrote: > On 15/10/2019 21:34, Bart wrote: > > On 15/10/2019 20:11, Bart wrote: > > > >> > >> Tell me where I can buy a 64-bit desktop or laptop machine. The last > >> time I managed it was a decade ago. > > > > I mean, 32-bit machines, other than second-hand. > > The last 32-bit x86 PC I bought was about 2 weeks ago. It was an Intel > Compute Stick - so a rather small computer, but powerful enough for its > job of displaying a information screen webpage on a large monitor. It > came with 32-bit Windows 10. That's quite similar to RPI-4 that Bart already has - 64-bit CPU, but 32-bit OS. https://ark.intel.com/content/www/us/en/ark/products/91564/intel-atom-x5-z8330-processor-2m-cache-up-to-1-92-ghz.html The closest to general-purpose computing device with 32-bit CPU that is still sold new in significant quantities that I found was that one: https://www.gsmarena.com/lg_k4_(2017)-8489.php Not exactly a laptop.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-16 10:11 +0100 |
| Message-ID | <W8BpF.308800$3C5.255613@fx01.am4> |
| In reply to | #147002 |
On 15/10/2019 21:05, David Brown wrote: > On 15/10/2019 21:34, Bart wrote: >> On 15/10/2019 20:11, Bart wrote: >> >>> >>> Tell me where I can buy a 64-bit desktop or laptop machine. The last >>> time I managed it was a decade ago. >> >> I mean, 32-bit machines, other than second-hand. > > The last 32-bit x86 PC I bought was about 2 weeks ago. It was an Intel > Compute Stick - so a rather small computer, but powerful enough for its > job of displaying a information screen webpage on a large monitor. It > came with 32-bit Windows 10. > So, as I explained it is still possible to target such a machine from a language which uses default 64-bit types. If it runs a bit slower (because of doing unnecessary 64-bit calculations when 32-bit will do), then you can choose to use an explicit 32-bit type, either directly or via an alias (so that you can select the actual type in one place). But it will run.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-16 12:42 +0200 |
| Message-ID | <qo6s63$tpe$1@dont-email.me> |
| In reply to | #147004 |
On 16/10/2019 11:11, Bart wrote: > On 15/10/2019 21:05, David Brown wrote: >> On 15/10/2019 21:34, Bart wrote: >>> On 15/10/2019 20:11, Bart wrote: >>> >>>> >>>> Tell me where I can buy a 64-bit desktop or laptop machine. The last >>>> time I managed it was a decade ago. >>> >>> I mean, 32-bit machines, other than second-hand. >> >> The last 32-bit x86 PC I bought was about 2 weeks ago. It was an >> Intel Compute Stick - so a rather small computer, but powerful enough >> for its job of displaying a information screen webpage on a large >> monitor. It came with 32-bit Windows 10. >> > > So, as I explained it is still possible to target such a machine from a > language which uses default 64-bit types. Of course. > > If it runs a bit slower (because of doing unnecessary 64-bit > calculations when 32-bit will do), then you can choose to use an > explicit 32-bit type, either directly or via an alias (so that you can > select the actual type in one place). > > But it will run. > Yes, indeed. (As long as you don't make assumptions like atomic sizes if you are making a multi-threaded program.)
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-16 04:02 -0700 |
| Message-ID | <7ec048f7-6446-49a6-b736-aabeb5f4552b@googlegroups.com> |
| In reply to | #146997 |
On Tuesday, October 15, 2019 at 8:31:58 PM UTC+3, Anton Shepelev wrote: > My current machine > is based on a old AMD APU and runs under 32-bit Windows XP. > I am not wont to change computers as some people a changing > their smartphone to keep in trend. > > -- > () ascii ribbon campaign - against html e-mail > /\ http://preview.tinyurl.com/qcy6mjc [archived] WinXP is becoming increasingly problematic even for home/individual use. All major web browsers dropped support. And minor browsers are minor for reason - plenty of stuff does not work and bug reports are either ignored or reacted on veeery slowly. Lots of other apps dropped support too. E.g. Skype. And, of course, in corporate environment WinXP is no-go due to lack of support for SMB protocols, except for totally insecure SMBv1.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-17 05:51 -0700 |
| Message-ID | <86tv874jsq.fsf@linuxsc.com> |
| In reply to | #146983 |
Richard Damon <Richard@Damon-Family.org> writes: > C has 11 standard integer types. PERIOD. An argument could be made that C has 12 standard integer types, since 'signed int' is not perfectly identical to 'int'. (The difference arises in declaring bitfield members.) Besides that miniscule exception though you assertions are spot on.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-18 10:18 -0400 |
| Message-ID | <gRjqF.126692$iJ2.51339@fx47.iad> |
| In reply to | #147016 |
On 10/17/19 8:51 AM, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> C has 11 standard integer types. PERIOD. > > An argument could be made that C has 12 standard integer types, > since 'signed int' is not perfectly identical to 'int'. (The > difference arises in declaring bitfield members.) Besides that > miniscule exception though you assertions are spot on. > Except that for a bit field, the declaration of the type of a field as int doesn't create a type that is distinct from signed int and unsigned int like char does, but is implementation defined if int is to be considered as signed int or unsigned int. In other words, no bit field member has a type of 'int', but only signed int or unsigned int, and a field declared as just int will be treated as one or the other as defined and documented by the implementation. If I am reading the standard right, I think that decision only applies to the literal string int (or after macro replacement), and not for a typedef.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-18 12:05 -0700 |
| Message-ID | <lny2xheuwe.fsf@kst-u.example.com> |
| In reply to | #147030 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 10/17/19 8:51 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> C has 11 standard integer types. PERIOD.
>>
>> An argument could be made that C has 12 standard integer types,
>> since 'signed int' is not perfectly identical to 'int'. (The
>> difference arises in declaring bitfield members.) Besides that
>> miniscule exception though you assertions are spot on.
>
> Except that for a bit field, the declaration of the type of a field as
> int doesn't create a type that is distinct from signed int and unsigned
> int like char does, but is implementation defined if int is to be
> considered as signed int or unsigned int. In other words, no bit field
> member has a type of 'int', but only signed int or unsigned int, and a
> field declared as just int will be treated as one or the other as
> defined and documented by the implementation.
Yes.
N1570 6.7.2p5:
Each of the comma-separated multisets designates the same type,
except that for bit-fields, it is implementation-defined whether
the specifier int designates the same type as signed int or
the same type as unsigned int.
(The "multisets" include "int", "signed int", and "signed", for
example. The term "multiset" is used rather than "set" because
"long long" is distinct from "long".)
> If I am reading the standard right, I think that decision only applies
> to the literal string int (or after macro replacement), and not for a
> typedef.
That's not the intent, though I agree that it's implied by the normative
wording. N1570 footnote 125 on 6.7.2.1p10 says:
125) As specified in 6.7.2 above, if the actual type specifier
used is int or a typedef-name defined as int, then it is
implementation-defined whether the bit-field is signed
or unsigned.
But by referring to "the specifier int" (a syntactic construct)
rather than the type int, 6.7.2p5 fails to make that clear.
(The name of a typedef defined as int is not "the specifier int".)
But even in unambiguous cases, like
struct {
unsigned int bf:2;
};
it's not clear what the type of bf is. 6.7.2.1p10 says:
A bit-field is interpreted as having a signed or unsigned integer
type consisting of the specified number of bits.
But what is that type?
Since "unsigned int" is not a type consisting of 2 bits, I would argue
that bf is not of type unsigned int. We can use _Generic to explore
what type a compiler uses for a given bit-field. gcc gives bf the type
"unsigned char:2" (a type that can't be named in a generic selection),
while clang treats is as type "unsigned int" (which I'm not entirely
sure is conforming).
#include <stdio.h>
int main(void) {
struct {
unsigned int bf:2;
} obj = { .bf = -1 };
_Generic(
obj.bf,
char: printf("obj.bf = %d (char)\n", obj.bf),
unsigned char: printf("obj.bf = %d (unsigned char)\n", obj.bf),
signed char: printf("obj.bf = %d (signed char)\n", obj.bf),
int: printf("obj.bf = %d (int)\n", obj.bf),
unsigned int: printf("obj.bf = %u (unsigned int)\n", obj.bf)
);
}
gcc gives an error:
error: '_Generic' selector of type 'unsigned char:2' is not compatible
with any association
(And if the width is 8, it's of type unsigned char, not "unsigned char:8").
clang gives:
obj.bf = 3 (unsigned int)
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-23 05:42 -0700 |
| Message-ID | <86a79rhbv2.fsf@linuxsc.com> |
| In reply to | #147045 |
Keith Thompson <kst-u@mib.org> writes:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 10/17/19 8:51 AM, Tim Rentsch wrote:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> C has 11 standard integer types. PERIOD.
>>>
>>> An argument could be made that C has 12 standard integer types,
>>> since 'signed int' is not perfectly identical to 'int'. (The
>>> difference arises in declaring bitfield members.) Besides that
>>> miniscule exception though you assertions are spot on.
>>
>> Except that for a bit field, the declaration of the type of a field as
>> int doesn't create a type that is distinct from signed int and unsigned
>> int like char does, but is implementation defined if int is to be
>> considered as signed int or unsigned int. In other words, no bit field
>> member has a type of 'int', but only signed int or unsigned int, and a
>> field declared as just int will be treated as one or the other as
>> defined and documented by the implementation.
>
> Yes.
>
> N1570 6.7.2p5:
> Each of the comma-separated multisets designates the same type,
> except that for bit-fields, it is implementation-defined whether
> the specifier int designates the same type as signed int or
> the same type as unsigned int.
>
> (The "multisets" include "int", "signed int", and "signed", for
> example. The term "multiset" is used rather than "set" because
> "long long" is distinct from "long".)
>
>> If I am reading the standard right, I think that decision only applies
>> to the literal string int (or after macro replacement), and not for a
>> typedef.
>
> That's not the intent, though I agree that it's implied by the normative
> wording. N1570 footnote 125 on 6.7.2.1p10 says:
>
> 125) As specified in 6.7.2 above, if the actual type specifier
> used is int or a typedef-name defined as int, then it is
> implementation-defined whether the bit-field is signed
> or unsigned.
>
> But by referring to "the specifier int" (a syntactic construct)
> rather than the type int, 6.7.2p5 fails to make that clear.
> (The name of a typedef defined as int is not "the specifier int".)
This statement, and whether there is normative wording supporting
footnote 125, depends on how 'typedef' is defined. The semantics
of 'typedef' is given in 6.7.8 p3. I have no firm conclusions on
how the relevant passages there should be parsed (except to say
they are sorely in need of clarifying). Note however the example
in 6.7.8 p6:
EXAMPLE 3 The following obscure constructions
typedef signed int t;
typedef int plain;
struct tag {
unsigned t:4;
const t:5;
plain r:5;
};
declare a typedef name t with type signed int, a typedef name
plain with type int, and a structure with three bit-field
members, one named t that contains values in the range [0, 15],
an unnamed const-qualified bit-field which (if it could be
accessed) would contain values in either the range [-15, +15]
or [-16, +15], and one named r that contains values in one of
the ranges [0, 31], [-15, +15], or [-16, +15]. (The choice of
range is implementation-defined.) [...]
This example clearly shows that the authors consider typedef's
normative semantics to distinguish between 'signed int' and
'int'.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-23 05:02 -0700 |
| Message-ID | <86eez3hdoy.fsf@linuxsc.com> |
| In reply to | #147030 |
Richard Damon <Richard@Damon-Family.org> writes: > On 10/17/19 8:51 AM, Tim Rentsch wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> C has 11 standard integer types. PERIOD. >> >> An argument could be made that C has 12 standard integer types, >> since 'signed int' is not perfectly identical to 'int'. (The >> difference arises in declaring bitfield members.) Besides that >> miniscule exception though you assertions are spot on. > > Except that for a bit field, the declaration of the type of a field as > int doesn't create a type that is distinct from signed int and unsigned > int like char does, but is implementation defined if int is to be > considered as signed int or unsigned int. In other words, no bit field > member has a type of 'int', but only signed int or unsigned int, and a > field declared as just int will be treated as one or the other as > defined and documented by the implementation. The key point is that 'int' needs to be tracked separately in the type system. > If I am reading the standard right, I think that decision only applies > to the literal string int (or after macro replacement), and not for a > typedef. It is because 'int' needs to be tracked through typedefs that prompted me to make the comment. Probably I should have said that, but the followup by Keith Thompson has now clarified it.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2019-10-14 15:32 +0000 |
| Message-ID | <5da49398.560921@news.xs4all.nl> |
| In reply to | #146923 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > On Sunday, 13 October 2019 00:12:44 UTC+1, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > > This is an argument that there /is/ a flaw. I think it is both > > well-known and almost universally accepted. Which "proposers" do you > > think are unaware of this flaw? > > > Someone agreed to create a language with forty general-purpose integer > types, Stop intentionally misreading the Standard. There are _not_ forty general-purpose integer types. There are a handful of general-purpose integer types (sure, more than in Dartmouth BASIC, which had a grand total of none, but not more than a competent programmer can deal with), and several handfuls of _special_-purpose integer types. Or do you want to insist that uint_least32_t and intptr_t are the correct type for a loop counter? Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-14 08:57 -0700 |
| Message-ID | <86a7a3721w.fsf@linuxsc.com> |
| In reply to | #146840 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 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. [..etc..]
My comment here is not exactly a response but this seems
like a reasonable place in the thread to make it, and so
here we are.
Reading through the various postings, it struck me that there is
a difference in viewpoints which could be explained by some
observations made by Dijkstra and James Morris.
The Dijkstra observation is about the two views of programming.
In the old view, the purpose of our programs is to instruct our
machines. In the new view, the purpose of machines is to execute
our programs. This change of viewpoint is a profound shift.
The Morris observation is captured by the title of his seminal
paper, "Types are not sets" (here is a link for people who have
not seen the paper:
http://www.cs.fsu.edu/~langley/COP4020/2016-Summer/p120-morris.pdf
).
The difference in viewpoints we are seeing here can be understood
by the observations of Dijkstra and Morris. The people who think
C has too many types are those who have not yet made the shifts
described by Dijkstra and Morris. They think of "type" as being
synonymous with representation, and at least in this area their
thinking is mostly at the level of assembly language. Speaking
for myself, there are times in programming when I do deliberately
take the perspective of what's going on at the assembly language
level, but mostly I don't, because it gets in the way of seeing
what is going on at a higher level. Since the most important
parts of program understanding involve seeing what is going on at
higher levels of abstraction, the vast majority of the time I
avoid thinking at the assembly language level, because doing so
hurts more than it helps.
These observations may help us understand the comments of people
who think C's type model is somehow bad or wrong.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-14 10:13 -0700 |
| Message-ID | <596f5e01-aa2a-4f30-adfa-9d17a206ea63@googlegroups.com> |
| In reply to | #146957 |
On Monday, 14 October 2019 16:57:25 UTC+1, Tim Rentsch wrote: > > The Dijkstra observation is about the two views of programming. > In the old view, the purpose of our programs is to instruct our > machines. In the new view, the purpose of machines is to execute > our programs. This change of viewpoint is a profound shift. > We're not there. Programs almost always break when moved from platform to platform, particularly the advanced programs which perform the functions for which the machine was purchased. There are many reasons for that, including commercial benefits to platform vendors from incompatibilities between systems, even legal principles which prevent different vendors from releasing compatible systems. > > The Morris observation is captured by the title of his seminal > paper, "Types are not sets" (here is a link for people who have > not seen the paper: > > http://www.cs.fsu.edu/~langley/COP4020/2016-Summer/p120-morris.pdf > > ). > > The difference in viewpoints we are seeing here can be understood > by the observations of Dijkstra and Morris. The people who think > C has too many types are those who have not yet made the shifts > described by Dijkstra and Morris. They think of "type" as being > synonymous with representation, and at least in this area their > thinking is mostly at the level of assembly language. Speaking > for myself, there are times in programming when I do deliberately > take the perspective of what's going on at the assembly language > level, but mostly I don't, because it gets in the way of seeing > what is going on at a higher level. Since the most important > parts of program understanding involve seeing what is going on at > higher levels of abstraction, the vast majority of the time I > avoid thinking at the assembly language level, because doing so > hurts more than it helps. > > These observations may help us understand the comments of people > who think C's type model is somehow bad or wrong. > In the high level concept you just have "integer", or maybe even "scalar". The type information then refers to what the value is used for. Is it naturally integral, non-negative? Is it part of a complex number? Does it represent an amount of money? Is it naturally range limited (and that range probably won't be a power of a power of two)? Is the range definite or is it a sanity test? However at the lower level, you can't ignore the fact that the computer memory and registers are made of bits, accessed in chunks which are usually multiples of octets. Also, most integers are small and readily fit into 8, 16, or 32 bits. So images, for example, consist of a raster of 3 x 8 bits, not because display systems can really represent values on the range 0-255, but because that is a useful compromise between the abilities of human perception and the fact that most processors like to access information in 8 bit bytes. Trying to ignore the representation in a pixel by pixel image processing algorithm will likely lead to unacceptably slow performance. The same is true of audio files.
[toc] | [prev] | [next] | [standalone]
Page 15 of 25 — ← Prev page 1 … 13 14 [15] 16 17 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web