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 10 of 25 — ← Prev page 1 … 8 9 [10] 11 12 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 15:07 +0200 |
| Message-ID | <qohm70$q9n$1@dont-email.me> |
| In reply to | #147106 |
On 20/10/2019 13:25, Melzzzzz wrote: > On 2019-10-20, David Brown <david.brown@hesbynett.no> wrote: >> On 18/10/2019 21:01, Melzzzzz wrote: >>> On 2019-10-18, David Brown <david.brown@hesbynett.no> wrote: >>>> On 18/10/2019 19:01, Melzzzzz wrote: >>>>> On 2019-10-18, Scott Lurndal <scott@slp53.sl.home> wrote: >>>>>> Bart <bc@freeuk.com> writes: >>>>>>> On 14/10/2019 11:33, Anton Shepelev wrote: >>>>>>>> Bart: >>>>>>> >>>>>>> >>>>>>> It is when you don't have the memory! Here is the C equivalent of a bug >>>>>>> I found today: >>>>>>> >>>>>>> char *dataptr; >>>>>>> int *p; >>>>>>> >>>>>>> p = (int*)dataptr; >>>>>>> *p = x; >>>>>>> dataptr += 4; >>>>>> >>>>>> Of course competent C programmer would have written >>>>>> >>>>>> dataptr += sizeof(int); >>>>> >>>>> no, assert(sizeof(int)==4); /* :) */ >>>>> >>>> >>>> At least make it _Static_assert ! >>> >>> I don't know about that... >> >> _Static_assert(CHAR_BIT == 8, "Expected 8-bit bytes"); >> _Static_assert((sizeof(int) == 4, "Expected int to be size 4"); >> >> You can use #if and #error as well in some cases, but C11 _Static_assert >> is a bit more flexible. In my opinion, you should never use run-time >> checks like assert() if you can use a static assertion. > > Why? assert served me well so far... The sooner you see the problem, the sooner you can do something about it. > >> >>> >>>> >>>> (I'm fine with non-portable code that makes assumptions - even >>>> unnecessary ones - about the target. But the code should fail to >>>> compile if the assumptions don't hold.) >>> >>> nice, but error message should be sufficient... >>> >> >> Exactly - an error message when /compiling/, rather than waiting until >> run-time. > > If error message is meaningfull... > A meaningful compile-time error message beats a meaningful run-time error message every time. Even a /meaningless/ compile-time error is often better than a meaningful run-time error message. But my suggestion was for /meaningful/ compile-time error messages.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-10-18 16:58 +0000 |
| Message-ID | <YamqF.3347613$c8w1.332879@fx08.am4> |
| In reply to | #147021 |
On 2019-10-18, Bart <bc@freeuk.com> wrote: > On 14/10/2019 11:33, Anton Shepelev wrote: >> Bart: >> >>> 'int' in portable C is only guaranteed a 16-bit range. But >>> how many programs would still work if ported to such a >>> system? >> >> Many programs will continue to work because on those systems >> they will use a different set of typedefs (either custom >> ones or those proceded by C99). Some programs will continue >> to work, albeit at a lower capacity. For example, they >> won't be able to take, process, and output as large amounts >> of data. >> >>> What about an 'int' that is 64 bits? >> >> What about it? Too much is not too little. > > It is when you don't have the memory! Here is the C equivalent of a bug > I found today: > > char *dataptr; > int *p; > > p = (int*)dataptr; > *p = x; > dataptr += 4; > > This is written when you know that int is 32 bits, or 4 bytes. Write 4 > bytes to dataptr then step it along. > > The problem occurs when int becomes 64 bits. Then *p=x writes 8 bytes > not 4, and if dataptr/p is pointing to the last 4 bytes of a memory > allocation, then you get buffer overflow. > > These things happen. This is why one shouldn't program in C like in assembler... > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-14 08:06 -0700 |
| Message-ID | <86r23f74ep.fsf@linuxsc.com> |
| In reply to | #146924 |
Anton Shepelev <anton.txt@gmail.com> writes: > Of course, but we were talking specifically about types, > which comprise one aspect of portability. "Comprise" is not the right word here. A whole comprises its parts or constitutent elements. For example, a zoo comprises its animals. You might try "form" or "constitute" there: "We were talking specifically about types, which constitute only one aspect of portability."
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-14 19:55 +0300 |
| Message-ID | <20191014195553.c8cd89b5412809b7760f21b4@g{oogle}mail.com> |
| In reply to | #146950 |
Tim Rentsch to Anton Shepelev: >>Of course, but we were talking specifically about types, >>which comprise one aspect of portability. > >"Comprise" is not the right word here. A whole comprises >its parts or constitutent elements. For example, a zoo >comprises its animals. You might try "form" or >"constitute" there: "We were talking specifically about >types, which constitute only one aspect of portability." Of course. I taught Rick about it and sipped myself. Thank you for the correction. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-15 03:24 +0100 |
| Message-ID | <87a7a24ufl.fsf@bsb.me.uk> |
| In reply to | #146950 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Anton Shepelev <anton.txt@gmail.com> writes: > >> Of course, but we were talking specifically about types, >> which comprise one aspect of portability. > > "Comprise" is not the right word here. A whole comprises its > parts or constitutent elements. For example, a zoo comprises its > animals. You might try "form" or "constitute" there: Not this again! There's nothing wrong with Anton's usage. Collins English Dictionary (to name just one) descibes this use of "comprise" and even lists "form" and "constitute" as synonyms for it. > "We were > talking specifically about types, which constitute only one > aspect of portability." -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-15 12:39 +0300 |
| Message-ID | <20191015123910.ce2b4c03a564fae0a54df2f5@g{oogle}mail.com> |
| In reply to | #146981 |
Ben Bacarisse to Tim Rentsch: >>Anton Shepelev: >> >>>Of course, but we were talking specifically about types, >>>which comprise one aspect of portability. >> >>"Comprise" is not the right word here. A whole comprises >>its parts or constitutent elements. For example, a zoo >>comprises its animals. You might try "form" or >>"constitute" there: > >Not this again! There's nothing wrong with Anton's usage. Pray defend not my usage. I knew the right and literary meaning of the word and erred through haste and inattention. >Collins English Dictionary (to name just one) descibes this >use of "comprise" and even lists "form" and "constitute" as >synonyms for it. It just yields to the popular confusion. `comprise' and 'compose' (or 'consist of') are in way antonims and have complementary meanings: https://www.dictionary.com/e/comprise-vs-compose/ Again, as I told Rick, the C Standard uses that word correctly! -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-15 04:03 -0700 |
| Message-ID | <5d7ea403-4ecd-40b6-8ac8-eef6108fa0dc@googlegroups.com> |
| In reply to | #146986 |
On Tuesday, October 15, 2019 at 12:39:18 PM UTC+3, Anton Shepelev wrote: > Ben Bacarisse to Tim Rentsch: > > >>Anton Shepelev: > >> > >>>Of course, but we were talking specifically about types, > >>>which comprise one aspect of portability. > >> > >>"Comprise" is not the right word here. A whole comprises > >>its parts or constitutent elements. For example, a zoo > >>comprises its animals. You might try "form" or > >>"constitute" there: > > > >Not this again! There's nothing wrong with Anton's usage. > > Pray defend not my usage. I knew the right and literary > meaning of the word and erred through haste and inattention. > > >Collins English Dictionary (to name just one) descibes this > >use of "comprise" and even lists "form" and "constitute" as > >synonyms for it. > > It just yields to the popular confusion. `comprise' and > 'compose' (or 'consist of') are in way antonims and have > complementary meanings: > > https://www.dictionary.com/e/comprise-vs-compose/ > > Again, as I told Rick, the C Standard uses that word > correctly! > > -- > () ascii ribbon campaign - against html e-mail > /\ http://preview.tinyurl.com/qcy6mjc [archived] comprise, surprise and enterprise are matters of a fair price sorry
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-15 14:30 +0100 |
| Message-ID | <874l0a3zmd.fsf@bsb.me.uk> |
| In reply to | #146986 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Ben Bacarisse to Tim Rentsch:
>
>>>Anton Shepelev:
>>>
>>>>Of course, but we were talking specifically about types,
>>>>which comprise one aspect of portability.
>>>
>>>"Comprise" is not the right word here. A whole comprises
>>>its parts or constitutent elements. For example, a zoo
>>>comprises its animals. You might try "form" or
>>>"constitute" there:
>>
>>Not this again! There's nothing wrong with Anton's usage.
>
> Pray defend not my usage. I knew the right and literary
> meaning of the word and erred through haste and inattention.
I'm defending you particularly. I'm defending a correct use of the
language.
You can, of course, never use comprise in this way again. There will be
no harm, but I have a bee in my bonnet about this sort of correction
because I used to do it myself. How I loved correcting continuous to
continual and disinterested to uninterested. Now I hate it. Often (as
in that last case) the "correction" isn't always right. It all flows
from a 19th century obsession of some teachers and academics to define
what's "correct" in order that "properly-educated" people can be spotted
amongst the burgeoning middle class. We don't need it anymore.
>>Collins English Dictionary (to name just one) descibes this
>>use of "comprise" and even lists "form" and "constitute" as
>>synonyms for it.
>
> It just yields to the popular confusion. `comprise' and
> 'compose' (or 'consist of') are in way antonims and have
> complementary meanings:
But there was no confusion! "One aspect" can not be the whole! It is
very rare that there ever is any confusion in these matters, and if it
is possible that the meaning can be confused, you should avoid the word
because other people understand the two meanings.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-18 05:59 -0700 |
| Message-ID | <864l06i4zs.fsf@linuxsc.com> |
| In reply to | #146981 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Anton Shepelev <anton.txt@gmail.com> writes: >> >>> Of course, but we were talking specifically about types, >>> which comprise one aspect of portability. >> >> "Comprise" is not the right word here. A whole comprises its >> parts or constitutent elements. For example, a zoo comprises its >> animals. You might try "form" or "constitute" there: > > Not this again! There's nothing wrong with Anton's usage. Collins > English Dictionary (to name just one) descibes this use of "comprise" > and even lists "form" and "constitute" as synonyms for it. I concede your statement about dictionaries is true: many dictionaries give a definition for comprise that allows the above construction. My comment however was not about dictionaries but about usage and style. People who want to be careful in their writing (and I think Anton is one of those) should avoid using comprise in the sense it is used above. To be clear, my comment is not one of fact but of opinion. I would add though that it is not just my opinion, but one shared by enough serious writers that I think the advice is worth taking.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-19 00:31 +0100 |
| Message-ID | <87mudx1vhc.fsf@bsb.me.uk> |
| In reply to | #147023 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Anton Shepelev <anton.txt@gmail.com> writes: >>> >>>> Of course, but we were talking specifically about types, >>>> which comprise one aspect of portability. >>> >>> "Comprise" is not the right word here. A whole comprises its >>> parts or constitutent elements. For example, a zoo comprises its >>> animals. You might try "form" or "constitute" there: >> >> Not this again! There's nothing wrong with Anton's usage. Collins >> English Dictionary (to name just one) descibes this use of "comprise" >> and even lists "form" and "constitute" as synonyms for it. > > I concede your statement about dictionaries is true: many > dictionaries give a definition for comprise that allows the above > construction. My comment however was not about dictionaries but > about usage and style. People who want to be careful in their > writing (and I think Anton is one of those) should avoid using > comprise in the sense it is used above. > > To be clear, my comment is not one of fact but of opinion. I > would add though that it is not just my opinion, but one shared > by enough serious writers that I think the advice is worth > taking. I've changed my opinion on this. When it really matters, I would now advise against using comprise in any form unless you know the intended readership well. One usage comes across as stuffy and formal (which is only rarely a good thing) and there appear to be enough people who think the other usage is wrong that you can't be sure that one of them won't be reading your writing. One to avoid, I would say... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-23 04:46 -0700 |
| Message-ID | <86mudrheg6.fsf@linuxsc.com> |
| In reply to | #147057 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Anton Shepelev <anton.txt@gmail.com> writes: >>>> >>>>> Of course, but we were talking specifically about types, >>>>> which comprise one aspect of portability. >>>> >>>> "Comprise" is not the right word here. A whole comprises its >>>> parts or constitutent elements. For example, a zoo comprises its >>>> animals. You might try "form" or "constitute" there: >>> >>> Not this again! There's nothing wrong with Anton's usage. Collins >>> English Dictionary (to name just one) descibes this use of "comprise" >>> and even lists "form" and "constitute" as synonyms for it. >> >> I concede your statement about dictionaries is true: many >> dictionaries give a definition for comprise that allows the above >> construction. My comment however was not about dictionaries but >> about usage and style. People who want to be careful in their >> writing (and I think Anton is one of those) should avoid using >> comprise in the sense it is used above. >> >> To be clear, my comment is not one of fact but of opinion. I >> would add though that it is not just my opinion, but one shared >> by enough serious writers that I think the advice is worth >> taking. > > I've changed my opinion on this. When it really matters, I would now > advise against using comprise in any form unless you know the intended > readership well. > > One usage comes across as stuffy and formal (which is only rarely a good > thing) and there appear to be enough people who think the other usage is > wrong that you can't be sure that one of them won't be reading your > writing. One to avoid, I would say... I mostly agree with you. In most cases "comprise" is better confined to writing in formal English (which incidentally includes the ISO C standard as an example). Since we now mostly agree I will just leave it there.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-14 12:06 -0700 |
| Message-ID | <1140d288-3659-4562-bf8e-84d0d974f9f5@googlegroups.com> |
| In reply to | #146920 |
On Sunday, October 13, 2019 at 9:37:52 PM UTC+3, Anton Shepelev wrote: > already5chosen: > > > portability between different "models" is of rather low > > importance for majority of programmers. And rightly so, > > because for randomly chosen program a chance that it ever > > be ported *at all* is pretty close to zero. > > How so? Is it not portability that lets me use the same e- > mail client, newsreader, browser, document processor, image > processor, image editor, and C compiler on my Linux, > Windows, and MacOS machines? > > -- > () ascii ribbon campaign -- against html e-mail > /\ http://preview.tinyurl.com/qcy6mjc [archived] One does not contradict the other. There are tens of thousands of programs that were ported. May be, more than one hundred thousands although I have my doubts. And there are countless millions of programs that were never ported. The ratio is very close to zero. Personally, I am programming professionally for 27+ years (started late). I wrote a lot of programs during these years. Otherwise they wouldn't pay me :( I can recollect 1 (one) case of porting my "professional" C or C++ code. And it was not even a full program, but MEX (Matlab Extension) module. And porting happennd to pretty fresh code. For my hobby programs statistics could be different. Or not. YMMV.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-11 10:30 +0200 |
| Message-ID | <qnpek4$uvo$1@dont-email.me> |
| In reply to | #146845 |
On 10/10/2019 19:42, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/10/2019 23:32, Anton Shepelev wrote:
>>> David Brown:
>>>> 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.
>>>
>>> I think this behaviour would make the type system fragile
>>> because it would rely on an accidental similarity between
>>> the types.
>>
>> People already rely on this accidental similarity - the similarity is in
>> everything but the name. This is particularly the case since compilers
>> rarely complain about these things by default - you have to enable the
>> right warnings or flags. So my suggestion is that such code that looks
>> okay, has an obvious implementation, and often appears to work fine,
>> could then be re-classified as "correct".
>
> A contrived example:
>
> long *lptr = NULL;
> long long *llptr = lptr;
More realistically, assuming 64-bit "long" :
long *lptr = NULL;
int64_t *u64ptr = lptr;
long long *llptr = u64ptr;
Generally, people are unlikely to mix up "long" and "long long" (or
"int" and "long int"), even if they are the same size. But if you are
using fixed size types in code and connecting that with code that is
written with base types, then you /are/ going to come across this sort
of thing.
>
> This code violates a constraint, since long and long long
> are incompatible types and therefore long* and long long* are
> incompatible types with no implicit conversion.
>
> You seem to be suggesting that this code should be considered
> correct *if and only if* long and long long happen to have the
> same representation in the current implementation. (I can make
> them the same or different on my system by using or not using the
> "-m32" option to gcc.)
>
Just to be clear here - I think the most important thing is that there
are clear rules (which there are), that tools inform about violations of
the rules (which they often don't by default, and require extra flags,
for at least some violations), and that programmers follow the rules
(which too many fail to do). These are, IMHO, more important than the
details of the rules themselves.
There are plenty of things in C that are implementation-dependent, and
that work on some platforms and not others. To me, this change would
make things easier for some kinds of coding - and it would reduce the
risk of people writing code that appears to be correct, and will
/generally/ work, but can be subtly wrong.
> No thanks. It's bad enough that we already have that problem with,
> for example, unsigned long and size_t. And I fail to see what
> benefit you'd get from treating long and long long as compatible,
> other than tolerating bad code.
>
I'm guessing you don't make much use of fixed size types from <stdint.h>.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-11 02:26 -0700 |
| Message-ID | <lna7a7tyz3.fsf@kst-u.example.com> |
| In reply to | #146868 |
David Brown <david.brown@hesbynett.no> writes:
> On 10/10/2019 19:42, Keith Thompson wrote:
[...]
>> No thanks. It's bad enough that we already have that problem with,
>> for example, unsigned long and size_t. And I fail to see what
>> benefit you'd get from treating long and long long as compatible,
>> other than tolerating bad code.
>
> I'm guessing you don't make much use of fixed size types from <stdint.h>.
I'm not sure why you'd guess that. I try to use them consistently, and
without non-portable assumptions.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-11 12:41 +0200 |
| Message-ID | <qnpm8a$9r4$1@dont-email.me> |
| In reply to | #146870 |
On 11/10/2019 11:26, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 10/10/2019 19:42, Keith Thompson wrote: > [...] >>> No thanks. It's bad enough that we already have that problem with, >>> for example, unsigned long and size_t. And I fail to see what >>> benefit you'd get from treating long and long long as compatible, >>> other than tolerating bad code. >> >> I'm guessing you don't make much use of fixed size types from <stdint.h>. > > I'm not sure why you'd guess that. Ah well, I guessed wrongly - that's the nature of guessing! As I said, I see this more as a question of compatibility between <stdint.h> types and basic integer types rather than between different basic integer types alone, and an easy way to avoid any such issues is if your code simply doesn't use <stdint.h> types. > I try to use them consistently, and > without non-portable assumptions. > I do too. But people often have to combine code from different places - and then you get challenges. It's (relatively) easy to keep your own code consistent, or code developed within the one team. But if you make use of third-party code that generates an array of "long long int" and returns a pointer to long long, and another piece of code needs an array of int64_t via a pointer to int64_t, what do you do? You know your code will not be used on systems that have "long long int" that is not identical in size and representation to "int64_t", and have static assertions enforcing that. How do you pass the data pointers safely (and efficiently)?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-11 11:34 -0700 |
| Message-ID | <ln1rvjt9lu.fsf@kst-u.example.com> |
| In reply to | #146871 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But people often have to combine code from different places - and then
> you get challenges. It's (relatively) easy to keep your own code
> consistent, or code developed within the one team. But if you make use
> of third-party code that generates an array of "long long int" and
> returns a pointer to long long, and another piece of code needs an array
> of int64_t via a pointer to int64_t, what do you do? You know your code
> will not be used on systems that have "long long int" that is not
> identical in size and representation to "int64_t", and have static
> assertions enforcing that.
>
> How do you pass the data pointers safely (and efficiently)?
By casting the pointers, I suppose. The behavior is not absolutely
guaranteed, but it's unlikely to cause problems.
But I wouldn't assume (without very good reason) that my code will
*never* be used on systems where this would break -- thus the static
assertions (which I would have mentioned if you hadn't already).
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-12 12:06 +0200 |
| Message-ID | <qns8js$o4l$1@dont-email.me> |
| In reply to | #146877 |
On 11/10/2019 20:34, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> But people often have to combine code from different places - and then >> you get challenges. It's (relatively) easy to keep your own code >> consistent, or code developed within the one team. But if you make use >> of third-party code that generates an array of "long long int" and >> returns a pointer to long long, and another piece of code needs an array >> of int64_t via a pointer to int64_t, what do you do? You know your code >> will not be used on systems that have "long long int" that is not >> identical in size and representation to "int64_t", and have static >> assertions enforcing that. >> >> How do you pass the data pointers safely (and efficiently)? > > By casting the pointers, I suppose. The behavior is not absolutely > guaranteed, but it's unlikely to cause problems. > In that case, you are relying on the same semantics that I am suggesting could be guaranteed. You agree that it is likely (but not guaranteed) that code that mixes these pointers will work as expected. You agree that it is likely to be the only sensible way to code certain situations. You agree that even though the types are the same sizes and representations (if they were not, compatibility would be out of the question) there is no guarantee that the code will work - you need to confirm it for each specific case unless your compiler provides additional guarantees (like gcc's "-fno-strict-aliasing" flag, or "may_alias" attributes). My suggestion is that this /could/ be guaranteed in the standard. An alternative, with which I would be equally (or more) happy, would be that there be no compatibility between any of the different integer types (i.e., types like "int32_t", "size_t", "int", "long", etc., would be incompatible in all cases) - but that there be a way to convert pointer types safely. That is to say, you could explicitly tell the compiler "I have a pointer to type T. Make a pointer to type U with the same address, which I can access safely". Such a feature could have many benefits, especially if you didn't have to stick to types of the same size (you could make your own "malloc", for instance). What I don't like at the moment is that there is occasional need for converting pointers that are not compatible, and that the only sensible way to do it is not guaranteed to work. > But I wouldn't assume (without very good reason) that my code will > *never* be used on systems where this would break -- thus the static > assertions (which I would have mentioned if you hadn't already). >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-12 11:55 -0700 |
| Message-ID | <lnsgnxssi4.fsf@kst-u.example.com> |
| In reply to | #146885 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/10/2019 20:34, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> But people often have to combine code from different places - and then
>>> you get challenges. It's (relatively) easy to keep your own code
>>> consistent, or code developed within the one team. But if you make use
>>> of third-party code that generates an array of "long long int" and
>>> returns a pointer to long long, and another piece of code needs an array
>>> of int64_t via a pointer to int64_t, what do you do? You know your code
>>> will not be used on systems that have "long long int" that is not
>>> identical in size and representation to "int64_t", and have static
>>> assertions enforcing that.
>>>
>>> How do you pass the data pointers safely (and efficiently)?
>>
>> By casting the pointers, I suppose. The behavior is not absolutely
>> guaranteed, but it's unlikely to cause problems.
>
> In that case, you are relying on the same semantics that I am suggesting
> could be guaranteed.
Except that I would use a pointer cast, which is a large red flag that
this code can break if some assumptions (which I would document in
comments) are violated.
> You agree that it is likely (but not guaranteed)
> that code that mixes these pointers will work as expected.
Given that the corresponding types have the same representation, yes.
I would be very careful about making that assumption.
> You agree
> that it is likely to be the only sensible way to code certain
> situations.
Um, what? No, I didn't say that. All I did was mention the first
solution that sprang to mind. I didn't spend a lot of time exploring
alternatives.
> You agree that even though the types are the same sizes and
> representations (if they were not, compatibility would be out of the
> question) there is no guarantee that the code will work - you need to
> confirm it for each specific case unless your compiler provides
> additional guarantees (like gcc's "-fno-strict-aliasing" flag, or
> "may_alias" attributes).
>
> My suggestion is that this /could/ be guaranteed in the standard.
And the cost would be that code that *unnecessarily* assumes, for
example, that long and long long are compatible would compile without
errors under implementations where that assumption happens to be true,
and fail to compile when ported to a system where they aren't. It would
be a new way of planting time bombs in your code.
I understand that you think the benefits would make it worthwhile.
I just disagree.
The ideal solution would be to use the same times in the first place,
but the existence of two or more libraries makes that impractical in
some cases.
> An alternative, with which I would be equally (or more) happy, would be
> that there be no compatibility between any of the different integer
> types (i.e., types like "int32_t", "size_t", "int", "long", etc., would
> be incompatible in all cases) - but that there be a way to convert
> pointer types safely. That is to say, you could explicitly tell the
> compiler "I have a pointer to type T. Make a pointer to type U with the
> same address, which I can access safely". Such a feature could have
> many benefits, especially if you didn't have to stick to types of the
> same size (you could make your own "malloc", for instance).
You want this to work for pointers to types of different sizes? I don't
see how you could safely convert a uint16_t* to uint32_t*, for example.
> What I don't like at the moment is that there is occasional need for
> converting pointers that are not compatible, and that the only sensible
> way to do it is not guaranteed to work.
>
>> But I wouldn't assume (without very good reason) that my code will
>> *never* be used on systems where this would break -- thus the static
>> assertions (which I would have mentioned if you hadn't already).
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-13 13:23 +0200 |
| Message-ID | <qnv1fs$38r$1@dont-email.me> |
| In reply to | #146898 |
On 12/10/2019 20:55, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 11/10/2019 20:34, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> But people often have to combine code from different places - and then >>>> you get challenges. It's (relatively) easy to keep your own code >>>> consistent, or code developed within the one team. But if you make use >>>> of third-party code that generates an array of "long long int" and >>>> returns a pointer to long long, and another piece of code needs an array >>>> of int64_t via a pointer to int64_t, what do you do? You know your code >>>> will not be used on systems that have "long long int" that is not >>>> identical in size and representation to "int64_t", and have static >>>> assertions enforcing that. >>>> >>>> How do you pass the data pointers safely (and efficiently)? >>> >>> By casting the pointers, I suppose. The behavior is not absolutely >>> guaranteed, but it's unlikely to cause problems. >> >> In that case, you are relying on the same semantics that I am suggesting >> could be guaranteed. > > Except that I would use a pointer cast, which is a large red flag that > this code can break if some assumptions (which I would document in > comments) are violated. Ah, okay. I didn't really consider about implicit conversions. I agree it is better to have to have some kind of an explicit conversion here. Implementation dependent behaviour or code is often necessary or useful (depending on the kind of code being developed). But it can be a good thing to have red flags and static assertions where you use it - you want a compile-time error if the code is used on platforms where the assumptions don't hold, and you want the error messages and/or comments to make the situation clear. One of the risks of a cast is that it can hide errors (or warnings) for cases where the required assumptions don't hold. A cast is telling the compiler "I know I'm doing something odd here - but trust me". Not everyone is as good at putting in static assertions or other compile-time checks for safety - it would be better if the checks were somehow baked into the conversion. That would require some kind of new syntax, I think - the best that can be done with the current syntax would be to make the conversion valid as an automatic conversion if and only if the sizes matched. I guess I don't really mean I want the types to be compatible - I mean I want the result of casting from one pointer type to another to work as though the types were compatible. (And in case it was missed, I am only talking here about types where the size and representations are the same.) I am not quite sure of the best term to describe it, nor the best way to achieve it. > >> You agree that it is likely (but not guaranteed) >> that code that mixes these pointers will work as expected. > > Given that the corresponding types have the same representation, yes. > I would be very careful about making that assumption. > My main aim here is that there should be a standardised way to be sure about that assumption. >> You agree >> that it is likely to be the only sensible way to code certain >> situations. > > Um, what? No, I didn't say that. All I did was mention the first > solution that sprang to mind. I didn't spend a lot of time exploring > alternatives. Fair enough. > >> You agree that even though the types are the same sizes and >> representations (if they were not, compatibility would be out of the >> question) there is no guarantee that the code will work - you need to >> confirm it for each specific case unless your compiler provides >> additional guarantees (like gcc's "-fno-strict-aliasing" flag, or >> "may_alias" attributes). >> >> My suggestion is that this /could/ be guaranteed in the standard. > > And the cost would be that code that *unnecessarily* assumes, for > example, that long and long long are compatible would compile without > errors under implementations where that assumption happens to be true, > and fail to compile when ported to a system where they aren't. It would > be a new way of planting time bombs in your code. I would expect compilation errors if the required assumptions are not true (such as when compiling the code on a platform where "long" and "long long" are different sizes). > > I understand that you think the benefits would make it worthwhile. > I just disagree. I don't think my suggestion is as bad as it appeared to you, since I would want the code to fail to compile when it would not work as expected. > > The ideal solution would be to use the same times in the first place, > but the existence of two or more libraries makes that impractical in > some cases. Exactly, yes. > >> An alternative, with which I would be equally (or more) happy, would be >> that there be no compatibility between any of the different integer >> types (i.e., types like "int32_t", "size_t", "int", "long", etc., would >> be incompatible in all cases) - but that there be a way to convert >> pointer types safely. That is to say, you could explicitly tell the >> compiler "I have a pointer to type T. Make a pointer to type U with the >> same address, which I can access safely". Such a feature could have >> many benefits, especially if you didn't have to stick to types of the >> same size (you could make your own "malloc", for instance). > > You want this to work for pointers to types of different sizes? I don't > see how you could safely convert a uint16_t* to uint32_t*, for example. > This would be an extension to the original ideas, and it would require some kind of new syntax. In many embedded systems (and other programs where efficiency is key), you often want memory pools rather than rely on malloc/free. You want memory that exists as one type - perhaps a statically allocated array of uint8_t or uint32_t - and you want to be able to dole out lumps to other parts of the code that will use the memory as other types. As C is defined today, you can't do that safely. The safest you can get is to make your pool a union type that covers all the types you might want to use. But that quickly becomes ugly and difficult to maintain, and limits your flexibility. C++ has come a lot further in this area. >> What I don't like at the moment is that there is occasional need for >> converting pointers that are not compatible, and that the only sensible >> way to do it is not guaranteed to work. >> >>> But I wouldn't assume (without very good reason) that my code will >>> *never* be used on systems where this would break -- thus the static >>> assertions (which I would have mentioned if you hadn't already). >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-13 13:30 -0700 |
| Message-ID | <ln8spos812.fsf@kst-u.example.com> |
| In reply to | #146913 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I guess I don't really mean I want the types to be compatible - I mean
> I want the result of casting from one pointer type to another to work
> as though the types were compatible. (And in case it was missed, I am
> only talking here about types where the size and representations are
> the same.) I am not quite sure of the best term to describe it, nor
> the best way to achieve it.
It sounds like you want to loosen the effective type rules (6.5p6-7)
so that an object whose effective type is an integer type can be
accessed by an lvalue of another integer type that has the same
representation, alignment, and perhaps some other characteristics.
(I suppose the same would apply to floating-point types, for
example for implementations where double and long double have
the same representation.) The types would still be incompatible,
and pointer casts would still be needed.
Such a change would inhibit some optimizations. For example:
long x = 42;
long long ptr = ...;
/* a bunch of code that doesn't refer to x */
if (x == 42) {
/* ... */
}
Currently a compiler can assume that x has not been modified via ptr.
I'm not sure whether such a change would be worth that cost.
[...]
> My main aim here is that there should be a standardised way to be sure
> about that assumption.
I'm not sure what that would look like, but ok. One possibility
might be something like a C++-style cast, a conversion operator that
would convert the pointer types but would be a constraint volation
if the target types differ in representation. I don't think it's
likely such a feature would be added without a lot more thought
than I've put into it.
[...]
> I don't think my suggestion is as bad as it appeared to you, since I
> would want the code to fail to compile when it would not work as
> expected.
My objection is that, given your previous suggestion, assigning a long*
value to a long long* object would not be required to give a warning if
long and long long happen to have the same representation *on the
current system*. It would encourage non-portable code.
In C as it's currently defined, types can be distinct and incompatible
even if they happen to have the same representation. I see this as a
good thing. What's missing is a way to define new and distinct integer
types. (And adding a way to do that could break a lot of uses of
_Generic.)
[...]
--
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]
Page 10 of 25 — ← Prev page 1 … 8 9 [10] 11 12 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web