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 16 of 25 — ← Prev page 1 … 14 15 [16] 17 18 … 25 Next page →
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-14 23:59 +0300 |
| Message-ID | <20191014235935.452ef66f21b387e64481fb2f@gmail.com> |
| In reply to | #146962 |
Malcolm McLean: > 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. It also leads to better quality and generality. In sound engineering it is a standard practice to do processing on samples stored as floating-point numbers normalised to unity. SoundForge -- the world's leading sound-processing program -- uses 32-bit float as an internal represention of sample values. The same is possible, and often useful, with raster images. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-17 06:08 -0700 |
| Message-ID | <86pniv4j0c.fsf@linuxsc.com> |
| In reply to | #146962 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > 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. >> >> 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. > > [...] > > 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. [..examples from > computer graphics..] Don't be an idiot. Of course _some_ parts of programming must be closely concerned with representation. My point was about programmers who _routinely_ think in terms of representation, and rarely in terms of anything else.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-10 01:20 -0700 |
| Message-ID | <5b525fc7-aeb6-47ec-b425-526a60d31e92@googlegroups.com> |
| In reply to | #146815 |
On Wednesday, October 9, 2019 at 9:32:07 PM UTC+3, David Brown wrote: > On 09/10/2019 19:40, already5chosen@yahoo.com wrote: > > On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown > > wrote: > >> On 09/10/2019 15:22, Bart wrote: > >>> On 09/10/2019 11:33, David Brown wrote: > >>> > >>>> One important point about the types in C is that the minimum > >>>> sizes are well defined. "int" is at least 16 bits (even on > >>>> 8-bit systems), "long int" is at least 32 bits, and "long long > >>>> int" is at least 64 bits. But the maximum sizes are not > >>>> defined, and if you want maximum portability, there are > >>>> different representations allowed with ones' complement, > >>>> padding bits, etc. In practice, most people can assume two's > >>>> complement and no padding, with all sizes being powers of two. > >>> > >>> How wide is 'long'? Is it wider than 'int'? > >> > >> You know the answer to that - it doesn't matter. > >> > >>> > >>> Is 'int64_t*' compatible with 'long long int*'? > >> > >> You know the answer to that. (Not that it matters. Use the type > >> that suits your needs - and access data by its type.) > >> > > > > > > Actually, decision of Linux variants of gcc and clang to make thise > > type incompatible is really annoying and I can't think about any > > reasonable justification for such incompatibility. > > I would personally be happier if C were defined to make integer types > with identical sizes and representations compatible. But they are not. > I'm not sure why not - the only reason I can think of is to have > compilers give diagnostics on a conversion that might hinder portability. What is an exact wording of C standard with regard to it? > > Still, this is a decision of the C standards - not gcc or clang. (They > could have made in64_t compatible with "long long int" - but then it > would be incompatible with "long int" of the same size on 64-bit targets.) > If the sane thing is non-standard then I would very much prefer in64_t compatible with 'long long' and incompatible with 'long'. Sounds like lesser evil. > > > > Your advice does not work in practice when you deal with includes > > written by somebody else (sometimes all of them "system' somebody > > else) part of which expects int64_t and the other part expects 'long > > long'. Then you have no choice than ugly casts, that, as it's always > > case with cast, can later on in the code's life, hide real bugs. > > > > 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. As I wrote above, typically the issue arises in areas that are out of control of application programmer. The biggest offender is a compiler itself. Look at definition of various compiler built-ins (intrinsic functions). Many of them use 'long long' in the meaning "64-bit".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-10 20:15 -0400 |
| Message-ID | <qnohio$tou$1@dont-email.me> |
| In reply to | #146829 |
On 10/10/19 4:20 AM, already5chosen@yahoo.com wrote: > On Wednesday, October 9, 2019 at 9:32:07 PM UTC+3, David Brown wrote: >> On 09/10/2019 19:40, already5chosen@yahoo.com wrote: >>> On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown >>> wrote: >>>> On 09/10/2019 15:22, Bart wrote: ... >>>>> Is 'int64_t*' compatible with 'long long int*'? >>>> >>>> You know the answer to that. (Not that it matters. Use the type >>>> that suits your needs - and access data by its type.) >>>> >>> >>> >>> Actually, decision of Linux variants of gcc and clang to make thise >>> type incompatible is really annoying and I can't think about any >>> reasonable justification for such incompatibility. >> >> I would personally be happier if C were defined to make integer types >> with identical sizes and representations compatible. But they are not. >> I'm not sure why not - the only reason I can think of is to have >> compilers give diagnostics on a conversion that might hinder portability. > > > What is an exact wording of C standard with regard to it? "Two types have compatible type if their types are the same. Additional rules for determining whether two types are compatible are described in 6.7.2 for type specifiers, in 6.7.3 for type qualifiers, and in 6.7.6 for declarators." (6.2.7p1). "Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined," (6.7.2p4). This is the only one of the clauses referenced in 6.2.7p1 which allows an integer type to be compatible with another type that isn't the same type. "A typedef declaration does not introduce a new type, only a synonym for the type so specified." (6.7.8p3) "For each type described herein that the implementation provides, 261) <stdint.h> shall declare that typedef name ..." (7.20p4) Therefore, the only way that int64_t could be compatible with with "long long int" is if it is a typedef for "long long int". That's not required, and it's only permitted if long long int has exactly 64 bits, a 2's complement representation, and no padding bits. int64_t could be a typedef for long, or int, or short, or even signed char. If plain char is signed, it could also be a typedef or plain char. It could also be a typedef for __implementation_specific_extended_64bit_type. >> Still, this is a decision of the C standards - not gcc or clang. (They >> could have made in64_t compatible with "long long int" - but then it >> would be incompatible with "long int" of the same size on 64-bit targets.) >> > > If the sane thing is non-standard then I would very much prefer in64_t compatible with 'long long' and incompatible with 'long'. Sounds like lesser evil. How would you feel about a platform where long is a 64-bit type, and long long is a 128-bit type? Do you still think int64_t should be compatible with long long on such a platform? If so, what should that even mean - how would it be implemented?
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-11 04:00 -0700 |
| Message-ID | <f813b10d-187b-4393-adf2-e75779ff31b0@googlegroups.com> |
| In reply to | #146865 |
On Friday, October 11, 2019 at 3:15:31 AM UTC+3, James Kuyper wrote: > On 10/10/19 4:20 AM, already5chosen@yahoo.com wrote: > > On Wednesday, October 9, 2019 at 9:32:07 PM UTC+3, David Brown wrote: > >> On 09/10/2019 19:40, already5chosen@yahoo.com wrote: > >>> On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown > >>> wrote: > >>>> On 09/10/2019 15:22, Bart wrote: > ... > >>>>> Is 'int64_t*' compatible with 'long long int*'? > >>>> > >>>> You know the answer to that. (Not that it matters. Use the type > >>>> that suits your needs - and access data by its type.) > >>>> > >>> > >>> > >>> Actually, decision of Linux variants of gcc and clang to make thise > >>> type incompatible is really annoying and I can't think about any > >>> reasonable justification for such incompatibility. > >> > >> I would personally be happier if C were defined to make integer types > >> with identical sizes and representations compatible. But they are not. > >> I'm not sure why not - the only reason I can think of is to have > >> compilers give diagnostics on a conversion that might hinder portability. > > > > > > What is an exact wording of C standard with regard to it? > > "Two types have compatible type if their types are the same. Additional > rules for determining whether two types are compatible are described in > 6.7.2 for type specifiers, in 6.7.3 for type qualifiers, and in 6.7.6 > for declarators." (6.2.7p1). > > "Each enumerated type shall be compatible with char, a signed integer > type, or an unsigned integer type. The choice of type is > implementation-defined," (6.7.2p4). This is the only one of the clauses > referenced in 6.2.7p1 which allows an integer type to be compatible with > another type that isn't the same type. > > "A typedef declaration does not introduce a new type, only a > synonym for the type so specified." (6.7.8p3) > > "For each type described herein that the implementation provides, 261) > <stdint.h> shall declare that typedef name ..." (7.20p4) > > Therefore, the only way that int64_t could be compatible with with "long > long int" is if it is a typedef for "long long int". That's not > required, and it's only permitted if long long int has exactly 64 bits, > a 2's complement representation, and no padding bits. int64_t could be a > typedef for long, or int, or short, or even signed char. If plain char > is signed, it could also be a typedef or plain char. It could also be a > typedef for __implementation_specific_extended_64bit_type. > > >> Still, this is a decision of the C standards - not gcc or clang. (They > >> could have made in64_t compatible with "long long int" - but then it > >> would be incompatible with "long int" of the same size on 64-bit targets.) > >> > > > > If the sane thing is non-standard then I would very much prefer in64_t compatible with 'long long' and incompatible with 'long'. Sounds like lesser evil. > > How would you feel about a platform where long is a 64-bit type, and > long long is a 128-bit type? Do you still think int64_t should be > compatible with long long on such a platform? If so, what should that > even mean - how would it be implemented? The comment above was about platforms on which both 'long' and 'long long' are 64-bit. O.T. Standardized 128-bit integers would be excellent thing, long overdue. As to 'long long' in ideal world it would never exist. In ideal world platforms that has 32-bit 'long' would introduce int64_t either as primary type or if the Standard, in its eternal wisdom, does not allow it, as an alias to implementation-specific type, most likely named __int64.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-11 07:53 -0400 |
| Message-ID | <K2_nF.113868$TC2.7987@fx43.iad> |
| In reply to | #146872 |
On 10/11/19 7:00 AM, already5chosen@yahoo.com wrote: > O.T. > Standardized 128-bit integers would be excellent thing, long overdue. > As to 'long long' in ideal world it would never exist. In ideal world platforms that has 32-bit 'long' would introduce int64_t either as primary type or if the Standard, in its eternal wisdom, does not allow it, as an alias to implementation-specific type, most likely named __int64. > My memory is that long long was invented before intN_t (by industry, if not put in an earlier standard) and actually fits within the early design of C better, being a real type (as opposed to the stdint types that are generally typedef aliasing to other types). Back when that was being developed, I wondered if it wouldn't make sense to allow mostly arbitrary stacking of long and short modifiers to a type to build other types, with long x being as big or bigger than x, and short x being no bigger, but maybe smaller than x, and short long x being at least as big, if not bigger than long short x. That would give use the following partial listing of types in size from largers to smallest (with some allowed to be the same size) long long long int long long int short long long int long int short long int int long short int short int short short int long long char long char short long char char (maybe allow long chars to be bigger than shorts so long char could be 16 bit chars and long long chars be 32 bit chars, and short short int be an 8 bit type for small numbers, and encourage it instead of signed char when you want very small integers). There is no need for short char, as breaking that char is the smallest type would break too much. The other extenstion would be to define types (which might alias other types) like double int which would be a type of at least twice the size of int, so you could do something like: int i; int j; // set i and j double int m = (double int)i * (double int) j; and m would not be able to overflow in its calculation. (some types would not have a type defined for double x); The issue with int64_t as a built in type is that this particular name is in the user namespace unless stdint.h has been included, the __ version is always in the implementation namespace, so new fundamental types tend to get those sorts of names (as with _Bool). Back when C was starting, names like int16_t wouldn't have been as useful for the fundamental types, as too many machines didn't have 16 bit type, but instead might have an 18 bit type. Thus the 'unsized' types became more natural. int was the type you did most things in, as it was presumed 'natural' (and thus quickest) for the processor, and would tend to scale with the size of the machine so a bigger machine with bigger memory it might grow to allow bigger problems. Perhaps now, with the current machine environment, making int8_t/int16_t/int32_t/int64_t/int128_t be the base types, and perhaps have the unsized types refer back to them would make sense. IF that happened then if long and long long are both 64 bit types, they would both be aliases for int64_t and thus compatible.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-11 11:20 -0400 |
| Message-ID | <qnq6k4$dse$1@dont-email.me> |
| In reply to | #146872 |
On 10/11/19 7:00 AM, already5chosen@yahoo.com wrote: > On Friday, October 11, 2019 at 3:15:31 AM UTC+3, James Kuyper wrote: >> On 10/10/19 4:20 AM, already5chosen@yahoo.com wrote: ... >>> If the sane thing is non-standard then I would very much prefer in64_t compatible with 'long long' and incompatible with 'long'. Sounds like lesser evil. >> >> How would you feel about a platform where long is a 64-bit type, and >> long long is a 128-bit type? Do you still think int64_t should be >> compatible with long long on such a platform? If so, what should that >> even mean - how would it be implemented? > > The comment above was about platforms on which both 'long' and 'long long' are 64-bit. Sorry, I responded to "make int64_t compatible with long long int" without thinking of the context. I would have expected the idea you were expressing to be accompanied by the clause "if they have the same size, alignment, representation, and passing mechanisms". I think it would be an awful idea for the compatibility of two types to be implementation-specific. It's bad enough that this is already the case for enumerated types. A diagnostic message to warn you that your code is relying upon unportable assumptions is a valuable thing; there's no reason why the compiler cannot go ahead and accept the code anyway after issuing that diagnostic. A _Generic() expression can be used to test for compatibility, possibly inside a _Static_assert(). > O.T. > Standardized 128-bit integers would be excellent thing, long overdue. ? int128_t has already been standardized. It's optional, but that name is reserved for this use, an implementation cannot use it for anything else, and the corresponding macros must be #defined if and only if it is in fact supported. Making int128_t mandatory would put undue burden on implementations targeting platforms where there's no need for a 128-bit type. That's precisely the same reason I would have preferred it for 64-bit types to be optional, too. You should be able to count on any implementation that supports a 128-bit 2's complement type with no padding bits, to support int128_t as a typedef for that type. Unfortunately, I've been informed that this is not the case, but that is cause for complaint to the implementer, not to the committee.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-11 11:16 -0700 |
| Message-ID | <ln5zkvtaet.fsf@kst-u.example.com> |
| In reply to | #146875 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> You should be able to count on any implementation that supports a
> 128-bit 2's complement type with no padding bits, to support int128_t as
> a typedef for that type. Unfortunately, I've been informed that this is
> not the case, but that is cause for complaint to the implementer, not to
> the committee.
The problem with that is that intmax_t would then have to be at least
128 bits. There are ABIs that would break if the size of intmax_t
(currently 64 bits on most systems) were changed. Thus __int128 is
a gcc extension and is *not* classified as a standard or extended
integer type.
Which is a great pity IMHO.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-11 14:43 -0400 |
| Message-ID | <qnqih0$p2t$1@dont-email.me> |
| In reply to | #146876 |
On 10/11/19 2:16 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >> You should be able to count on any implementation that supports a >> 128-bit 2's complement type with no padding bits, to support int128_t as >> a typedef for that type. Unfortunately, I've been informed that this is >> not the case, but that is cause for complaint to the implementer, not to >> the committee. > > The problem with that is that intmax_t would then have to be at least > 128 bits. There are ABIs that would break if the size of intmax_t > (currently 64 bits on most systems) were changed. Thus __int128 is > a gcc extension and is *not* classified as a standard or extended > integer type. > > Which is a great pity IMHO. If there's a sufficiently good reason to justify having an interface that is limited to 64 bits on a system capable of handling 128 bit integers, that interface should be defined in terms of int*64_t, not intmax_t. Of course, that's a lot easier said than done.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-11 11:51 -0700 |
| Message-ID | <lnwodbru80.fsf@kst-u.example.com> |
| In reply to | #146878 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/11/19 2:16 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>> You should be able to count on any implementation that supports a
>>> 128-bit 2's complement type with no padding bits, to support int128_t as
>>> a typedef for that type. Unfortunately, I've been informed that this is
>>> not the case, but that is cause for complaint to the implementer, not to
>>> the committee.
>>
>> The problem with that is that intmax_t would then have to be at least
>> 128 bits. There are ABIs that would break if the size of intmax_t
>> (currently 64 bits on most systems) were changed. Thus __int128 is
>> a gcc extension and is *not* classified as a standard or extended
>> integer type.
>>
>> Which is a great pity IMHO.
>
> If there's a sufficiently good reason to justify having an interface
> that is limited to 64 bits on a system capable of handling 128 bit
> integers, that interface should be defined in terms of int*64_t, not
> intmax_t. Of course, that's a lot easier said than done.
There are standard library functions that refer to intmax_t and
uintmax_t. Examples are printf() and scanf() with a "%jd" or
"%ju" format, and a number of functions declared in <inttypes.h>
(see 7.8.2, "Functions for greatest-width integer types).
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2019-10-12 07:46 +0000 |
| Message-ID | <5da184a0.723640@news.xs4all.nl> |
| In reply to | #146876 |
Keith Thompson <kst-u@mib.org> wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] > > You should be able to count on any implementation that supports a > > 128-bit 2's complement type with no padding bits, to support int128_t as > > a typedef for that type. Unfortunately, I've been informed that this is > > not the case, but that is cause for complaint to the implementer, not to > > the committee. > > The problem with that is that intmax_t would then have to be at least > 128 bits. There are ABIs that would break if the size of intmax_t > (currently 64 bits on most systems) were changed. Then those ABIs are severely broken. Sorry to their designers, but that's just the long and short of it. They made an obviously wrong decision, and now it's their problem, not C's. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 09:49 -0400 |
| Message-ID | <7SkoF.22041$ZR2.20371@fx16.iad> |
| In reply to | #146884 |
On 10/12/19 3:46 AM, Richard Bos wrote: > Keith Thompson <kst-u@mib.org> wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> [...] >>> You should be able to count on any implementation that supports a >>> 128-bit 2's complement type with no padding bits, to support int128_t as >>> a typedef for that type. Unfortunately, I've been informed that this is >>> not the case, but that is cause for complaint to the implementer, not to >>> the committee. >> >> The problem with that is that intmax_t would then have to be at least >> 128 bits. There are ABIs that would break if the size of intmax_t >> (currently 64 bits on most systems) were changed. > > Then those ABIs are severely broken. > > Sorry to their designers, but that's just the long and short of it. They > made an obviously wrong decision, and now it's their problem, not C's. > > Richard > It is the natural consequence of using pre-compiled binaries. Some functions naturally want to use a type like intmsx_t in its interface, and if they do, then changing the definition of the type breaks binary compatibility. One way to fix this is to include an 'ABI Version' in object modules so that you can't link together incompatible binaries. The issue comes down to ultimately all programs ultimately need to call OS services, and thus OS provided routines, so you either need to wait for the OS to issue support for the new ABI, have a way to mark a module as being an ABI translation layer, or the ABI versioning needs to be fine grained, being able to indicate that this particular call doesn't have an ABI issue. Adding the ability for a system to have multiple ABIs adds complication to a system, and can be hard to add after the fact, so often isn't done.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-12 12:29 +0200 |
| Message-ID | <qns9uj$umt$1@dont-email.me> |
| In reply to | #146876 |
On 11/10/2019 20:16, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >> You should be able to count on any implementation that supports a >> 128-bit 2's complement type with no padding bits, to support int128_t as >> a typedef for that type. Unfortunately, I've been informed that this is >> not the case, but that is cause for complaint to the implementer, not to >> the committee. > > The problem with that is that intmax_t would then have to be at least > 128 bits. There are ABIs that would break if the size of intmax_t > (currently 64 bits on most systems) were changed. Thus __int128 is > a gcc extension and is *not* classified as a standard or extended > integer type. > I think (but I am not sure) that making an "int128_t" extended integer type also requires the implementation to support constants of that type, and to support PRId128 and similar macros with corresponding support in functions like printf. This would mean significant amount of work for features that would be of relatively little use. > Which is a great pity IMHO. > Perhaps it would be possible to introduce some limited form of extended integer type in a standardised way? Then you could allow, say, "_int128_t" to function as an integer type with regard to arithmetic without imposing additional requirements. This would correspond to gcc's "__int128", and could be standardised.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-12 12:20 +0100 |
| Message-ID | <8GioF.1122195$Zy3.778591@fx33.am4> |
| In reply to | #146887 |
On 12/10/2019 11:29, David Brown wrote: > On 11/10/2019 20:16, Keith Thompson wrote: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> [...] >>> You should be able to count on any implementation that supports a >>> 128-bit 2's complement type with no padding bits, to support int128_t as >>> a typedef for that type. Unfortunately, I've been informed that this is >>> not the case, but that is cause for complaint to the implementer, not to >>> the committee. >> >> The problem with that is that intmax_t would then have to be at least >> 128 bits. There are ABIs that would break if the size of intmax_t >> (currently 64 bits on most systems) were changed. Thus __int128 is >> a gcc extension and is *not* classified as a standard or extended >> integer type. >> > > I think (but I am not sure) that making an "int128_t" extended integer > type also requires the implementation to support constants of that type, > and to support PRId128 and similar macros with corresponding support in > functions like printf. This would mean significant amount of work for > features that would be of relatively little use. > >> Which is a great pity IMHO. >> > > Perhaps it would be possible to introduce some limited form of extended > integer type in a standardised way? Then you could allow, say, > "_int128_t" to function as an integer type with regard to arithmetic > without imposing additional requirements. This would correspond to > gcc's "__int128", and could be standardised. If you're going to change printf, which is a big deal (isn't the library a different lot of development from the compiler?) then you might as well provide the right formats. Eg. MSVC provides "%I64d" I think it is, directly in a format string, and this is easily extended to both "%I128d", and "I32d", to match stdint.h types. I don't know if there's an unsigned version, which would simply have been "%U64d" This would have been worth doing anyway.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-12 13:38 +0200 |
| Message-ID | <qnse06$jj7$1@dont-email.me> |
| In reply to | #146888 |
On 12/10/2019 13:20, Bart wrote: > On 12/10/2019 11:29, David Brown wrote: >> On 11/10/2019 20:16, Keith Thompson wrote: >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>> [...] >>>> You should be able to count on any implementation that supports a >>>> 128-bit 2's complement type with no padding bits, to support >>>> int128_t as >>>> a typedef for that type. Unfortunately, I've been informed that this is >>>> not the case, but that is cause for complaint to the implementer, >>>> not to >>>> the committee. >>> >>> The problem with that is that intmax_t would then have to be at least >>> 128 bits. There are ABIs that would break if the size of intmax_t >>> (currently 64 bits on most systems) were changed. Thus __int128 is >>> a gcc extension and is *not* classified as a standard or extended >>> integer type. >>> >> >> I think (but I am not sure) that making an "int128_t" extended integer >> type also requires the implementation to support constants of that >> type, and to support PRId128 and similar macros with corresponding >> support in functions like printf. This would mean significant >> amount of work for features that would be of relatively little use. >> >>> Which is a great pity IMHO. >>> >> >> Perhaps it would be possible to introduce some limited form of >> extended integer type in a standardised way? Then you could allow, >> say, "_int128_t" to function as an integer type with regard to >> arithmetic without imposing additional requirements. This would >> correspond to gcc's "__int128", and could be standardised. > > If you're going to change printf, which is a big deal (isn't the library > a different lot of development from the compiler?) then you might as > well provide the right formats. > > Eg. MSVC provides "%I64d" I think it is, directly in a format string, > and this is easily extended to both "%I128d", and "I32d", to match > stdint.h types. I don't know if there's an unsigned version, which would > simply have been "%U64d" > > This would have been worth doing anyway. Certainly it would be easier to remember than picking new single letters, and less ugly than PRIi64 and similar macros.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-12 12:17 -0700 |
| Message-ID | <lno8ylsrh5.fsf@kst-u.example.com> |
| In reply to | #146887 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/10/2019 20:16, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>> You should be able to count on any implementation that supports a
>>> 128-bit 2's complement type with no padding bits, to support int128_t as
>>> a typedef for that type. Unfortunately, I've been informed that this is
>>> not the case, but that is cause for complaint to the implementer, not to
>>> the committee.
>>
>> The problem with that is that intmax_t would then have to be at least
>> 128 bits. There are ABIs that would break if the size of intmax_t
>> (currently 64 bits on most systems) were changed. Thus __int128 is
>> a gcc extension and is *not* classified as a standard or extended
>> integer type.
>
> I think (but I am not sure) that making an "int128_t" extended integer
> type also requires the implementation to support constants of that
> type, and to support PRId128 and similar macros with corresponding
> support in functions like printf. This would mean significant
> amount of work for features that would be of relatively little use.
A conforming C implementation *that doesn't have to worry about
backward compatibility* could have 64-bit long long, make int128_t
a typedef for an extended integer type, and make intmax_t a typedef
for that same extended integer type. (The problem with such an
implementation is that it would break compatibility with existing
libraries that assume intmax_t is 64 bits.)
I don't see a requirement in the standard to support constants of
type int128_t. But an implementation could support such constants
as an extension. (gcc doesn't.)
>> Which is a great pity IMHO.
>
> Perhaps it would be possible to introduce some limited form of
> extended integer type in a standardised way? Then you could allow,
> say, "_int128_t" to function as an integer type with regard to
> arithmetic without imposing additional requirements. This would
> correspond to gcc's "__int128", and could be standardised.
It might be possible, but I'd probably oppose it. gcc's __int128 is
a bit of a hack, providing *partial* support for 128-bit integers.
I'd like to see full (optional) support for 128-bit integers as
integer types. That would require a solution to the intmax_t
problem, and I'm not at all sure what such a solution would look
like.
There are existing implementations that don't support 128-bit
integers in any way, and we need to continue supporting them
(unless we want to make 128-bit integers mandatory, as C99 made
64-bit integers mandatory). On my system (Ubuntu 18.04.3), I
already have at least three sets of libraries for different memory
models: gcc -m64, gcc -m32, gcc -mx32. Adding optional support for
128-bit intmax_t would require at least one more set of libraries,
with different implementations of printf and other functions.
Maybe that's the way to go, but it would be nice to avoid potentially
exponential growth of standard library implementations.
At this point, I suspect there just isn't enough demand for 128-bit
integers to justify a full solution.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 20:20 -0400 |
| Message-ID | <I5uoF.19621$oU2.8247@fx21.iad> |
| In reply to | #146899 |
On 10/12/19 3:17 PM, Keith Thompson wrote: > I'd like to see full (optional) support for 128-bit integers as > integer types. That would require a solution to the intmax_t > problem, and I'm not at all sure what such a solution would look > like. The Standard fully allows support for int128_t. A system could easily have char 8 bits short 16 bits int 32 bits long 64 bits long long 128 bits at which point you have fully Standard based notations for everything 128 bit. (Getting to 256 bits will be harder, since C only has 5 distinct base integer type families) The issue is totally backwards compatibility restricting what size some types should be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-12 20:39 -0700 |
| Message-ID | <lnk199s49u.fsf@kst-u.example.com> |
| In reply to | #146906 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 10/12/19 3:17 PM, Keith Thompson wrote:
>> I'd like to see full (optional) support for 128-bit integers as
>> integer types. That would require a solution to the intmax_t
>> problem, and I'm not at all sure what such a solution would look
>> like.
>
> The Standard fully allows support for int128_t.
As I acknowledged in the part of my article you snipped. (I could have
provided a bit more context.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-13 21:32 +0300 |
| Message-ID | <20191013213244.ca6491d73d864b4226641958@gmail.com> |
| In reply to | #146906 |
Richard Damon: > A system could easily have > > char 8 bits > short 16 bits > int 32 bits > long 64 bits > long long 128 bits > > at which point you have fully Standard based notations for > everything 128 bit. (Getting to 256 bits will be harder, > since C only has 5 distinct base integer type families) An implementation could skip the 16-bit size and make short 32 bits wide, couldn't it? > The issue is totally backwards compatibility restricting > what size some types should be. Do I understand correctly from the discussion that this backwards compatibility refers only to programs that take for granted more than the standard allows, and therefore are not correct portable C? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-14 07:38 -0400 |
| Message-ID | <G6ZoF.10298$9v2.2302@fx31.iad> |
| In reply to | #146919 |
On 10/13/19 2:32 PM, Anton Shepelev wrote: > Richard Damon: > >> A system could easily have >> >> char 8 bits >> short 16 bits >> int 32 bits >> long 64 bits >> long long 128 bits >> >> at which point you have fully Standard based notations for >> everything 128 bit. (Getting to 256 bits will be harder, >> since C only has 5 distinct base integer type families) > > An implementation could skip the 16-bit size and make short > 32 bits wide, couldn't it? > Yes, but then there isn't a 16 bit type. >> The issue is totally backwards compatibility restricting >> what size some types should be. > > Do I understand correctly from the discussion that this > backwards compatibility refers only to programs that take > for granted more than the standard allows, and therefore are > not correct portable C? > The issue is that there are many existing libraries (including those provided by the OS), and changing the definition of an existing type (like intmax_t) changes how those functions would be caused. To make that change, and thus create a new incompatible ABI, says that to run a program with that new ABI says that all the libraries that is uses (including the OS calls) need to be provided in that new ABI. The OS library in particular tends to be a bit slow in evolving, and the existing solution, __int128_t being availble, but NOT considered an extended integer type, so not considered by intmax_t, seems to work well enough for practical uses, that the implementations and library providers aren't rushing to make the change. The thing to remember is that supporting multiple ABIs adds complexity to a system.
[toc] | [prev] | [next] | [standalone]
Page 16 of 25 — ← Prev page 1 … 14 15 [16] 17 18 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web