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 6 of 25 — ← Prev page 1 … 4 5 [6] 7 8 … 25 Next page →
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-10 15:58 -0700 |
| Message-ID | <cdd64a85-669f-464b-a583-1682f7259ffe@googlegroups.com> |
| In reply to | #146845 |
On Thursday, October 10, 2019 at 8:42:21 PM UTC+3, 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;
>
> 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.)
>
I don't know about David. My answer is 'Yes'.
> 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.
>
So, you fail to see. It happens.
Hint: 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. Even less so for porting to different model.
But convenience of writing program for the current toady's target is of rather high importance to all of us.
Besides, when something is ported to different model and fails during compilation it's not that big a deal. So you fix it. Not 1/100th as bad as silently producing wrong result.
> --
> 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:37 +0300 |
| Message-ID | <20191013213743.84c68aaf89bc1cd6b995db5b@gmail.com> |
| In reply to | #146861 |
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]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-13 19:56 +0100 |
| Message-ID | <WrKoF.2800373$dw4.2654846@fx12.am4> |
| In reply to | #146920 |
On 13/10/2019 19:37, 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? Most such programs on, say, Linux, won't run on Windows, even if you were to attempt to build from source. There's a lot more to portability that just details of types. (Like, dependence on libraries and utility that differ across OSes.) The process of building, say, CPython, between Linux and Windows is radically different, and extremely elaborate (as I found out after several hours attempting to build it for Windows). It is not something that comes automatically just by virtue of being written in C, except for the simplest kinds of programs which just do file I/O. And in that case, many other languages will give you the same portability. More complicated programs, you will need to explicitly provide special cross-platform support.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-14 00:56 +0300 |
| Message-ID | <20191014005637.56bd13f20bceb6f3c4233b09@gmail.com> |
| In reply to | #146921 |
Bart: > > 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? > > Most such programs on, say, Linux, won't run on Windows, > even if you were to attempt to build from source. I have enumerated those that I actually use on more than one platform: Sylheed, tin, Lynx, groff, Netpbm, Gimp, gcc. Bear in mind also that my argument was for already5chosen, to show the importance of portability of the basic software for running on an average PC. > There's a lot more to portability that just details of > types. (Like, dependence on libraries and utility that > differ across OSes.) Of course, but we were talking specifically about types, which comprise one aspect of portability. Why change the subject? > The process of building, say, CPython, between Linux and > Windows is radically different, and extremely elaborate > (as I found out after several hours attempting to build it > for Windows). Being unaware of the details, I cannot say whether it is the fault of CPython developers or the C programming language. Why would CPython dependent so stronly on platform-specific features and why would it have been easier to write, say, in FreePascal, as PasPython? > It is not something that comes automatically just by > virtue of being written in C, except for the simplest > kinds of programs which just do file I/O. But conformance to the C standard certainly helps, and you are wrong in dismissing all programs with file I/O as main/only interface as simple ones. GNU Troff and Netpbm are neither simple nor small. > And in that case, many other languages will give you the > same portability. Which ones, excluding scripts, interpreted languages, and those working in a managed environment? > More complicated programs, you will need to explicitly > provide special cross-platform support. Naturally. My e-mail client is an instance of such a portable application. Its GUI uses GTK. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-14 11:04 +0100 |
| Message-ID | <oKXoF.1030016$Nw3.947253@fx40.am4> |
| In reply to | #146924 |
On 13/10/2019 22:56, Anton Shepelev wrote: >> There's a lot more to portability that just details of >> types. (Like, dependence on libraries and utility that >> differ across OSes.) > > Of course, but we were talking specifically about types, > which comprise one aspect of portability. Why change the > subject? OK, let's stay with that. 'int' in portable C is only guaranteed a 16-bit range. But how many programs would still work if ported to such a system? (I tried changing my compiler to a 16-bit int in order to test that, but it was too big a job as it still has to work within a 64-bit environment.) What about an 'int' that is 64 bits? There is also 'long' that might be 32 or 64 bits - or more. And 'long long' that could conceivably be 128 bits. Or, any of these could in theory be any random width provided it is at least 16/32/64 and that int <= long <= long long. I suspect it would break many programs.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-14 13:33 +0300 |
| Message-ID | <20191014133326.cc63c82d5be1aad83f49d6ff@g{oogle}mail.com> |
| In reply to | #146931 |
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. >There is also 'long' that might be 32 or 64 bits -- or >more. > >And 'long long' that could conceivably be 128 bits. > >Or, any of these could in theory be any random width >provided it is at least 16/32/64 and that >int <= long <= long long. I suspect it would break many >programs. It would break many programs written carelessly or specificlly for 32-bit machines/compilers. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-18 10:57 +0100 |
| Message-ID | <e0gqF.1212939$_l5.234178@fx32.am4> |
| In reply to | #146933 |
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.
> It would break many programs written carelessly or
> specifically for 32-bit machines/compilers.
Not necessarily carelessly, but with certain assumptions, or some
understandable short-sightedness. After all, 'int' may have been 32 bits
on all platforms of interest for the last two decades, and shows no sign
of being changed.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-10-18 05:56 -0700 |
| Message-ID | <e6a5a83c-2145-4af0-a719-66bae5091e26@googlegroups.com> |
| In reply to | #147021 |
On Friday, 18 October 2019 10:57:40 UTC+1, Bart wrote: > ... Here is the C equivalent of a bug > I found today: > > char *dataptr; > int *p; > > p = (int*)dataptr; > *p = x; > dataptr += 4; dataptr += sizeof(int); // fixed and future-proof Which is how it should have been coded in the first place. I'm not sure what your point is.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-18 06:10 -0700 |
| Message-ID | <a3af2da2-2b38-4744-bf62-6c2f19896f6f@googlegroups.com> |
| In reply to | #147022 |
On Friday, 18 October 2019 13:56:43 UTC+1, mark....@gmail.com wrote: > On Friday, 18 October 2019 10:57:40 UTC+1, Bart wrote: > > ... Here is the C equivalent of a bug > > I found today: > > > > char *dataptr; > > int *p; > > > > p = (int*)dataptr; > > *p = x; > > dataptr += 4; > > dataptr += sizeof(int); // fixed and future-proof > > Which is how it should have been coded in the first place. > > I'm not sure what your point is. > Not necessarily, no. This comes down to Tim Rentsch's point about data and representation. Here, since we are messing about aliasing a char pointer to a integer buffer, it's pretty clear that for some reason we need 32 bit representation of integers in the computer memory. On a little endian machine, writing "*p = x;" will work, even if x is greater than 4 bytes, until we get to the end of the buffer, when we trash a 4 byte piece of memory. On a big endian machine, it will break when we try to read the value again. Creating a buffer of 32 bit big endian integers, creating a buffer of 32 bit little endian integers, and creating a buffer of 32 bit integers with native alignment are all reasonable things to do, especially if you have to interface with binary file formats or non-C calling conventions. However it's a low level action, it should be rare, normally we want an "array of integers", with maybe some sanity limit saying that they can't go anything like as high as 31 bits.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-18 15:24 +0200 |
| Message-ID | <qoceed$h17$1@dont-email.me> |
| In reply to | #147024 |
On 18/10/2019 15:10, Malcolm McLean wrote: > On Friday, 18 October 2019 13:56:43 UTC+1, mark....@gmail.com wrote: >> On Friday, 18 October 2019 10:57:40 UTC+1, Bart wrote: >>> ... Here is the C equivalent of a bug >>> I found today: >>> >>> char *dataptr; >>> int *p; >>> >>> p = (int*)dataptr; >>> *p = x; >>> dataptr += 4; >> >> dataptr += sizeof(int); // fixed and future-proof >> >> Which is how it should have been coded in the first place. >> >> I'm not sure what your point is. >> > Not necessarily, no. This comes down to Tim Rentsch's point about data > and representation. Here, since we are messing about aliasing a char > pointer to a integer buffer, it's pretty clear that for some reason we > need 32 bit representation of integers in the computer memory. No, it is not. If that were clear, there would be comments, or other code (unions, memcpy, etc.), or the code would use "int32_t". The immediate reaction to the code above is that the person writing it has made the assumption that "int" is always 32-bit without any checking, comment, or good reason. It may be that they felt it was a reasonable assumption - perhaps the code is in some Windows-specific code, where it is entirely reasonable to suppose that "int" will never be anything but 32-bit. > On a little endian machine, writing "*p = x;" will work, even if x > is greater than 4 bytes, until we get to the end of the buffer, when > we trash a 4 byte piece of memory. On a big endian machine, it will break > when we try to read the value again. Not true - on many systems, if x is not properly aligned, you'll get a failure. And the success or failure of the code here is independent of the endianness (and independent of the size and type of x, as long as it can be safely converted to an int). > > Creating a buffer of 32 bit big endian integers, creating a buffer of > 32 bit little endian integers, and creating a buffer of 32 bit integers > with native alignment are all reasonable things to do, especially > if you have to interface with binary file formats or non-C calling > conventions. And that is why C supports such coding - using int32_t (or uint32_t). You can also use arrays of character type (I'd prefer unsigned char or uint8_t) and read from them according to the endianness of the format you are matching - you can make the code quite portable without much effort. > However it's a low level action, it should be rare, normally > we want an "array of integers", with maybe some sanity limit saying that > they can't go anything like as high as 31 bits. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-18 09:41 -0400 |
| Message-ID | <IijqF.29023$hU2.14714@fx20.iad> |
| In reply to | #147024 |
On 10/18/19 9:10 AM, Malcolm McLean wrote: > On Friday, 18 October 2019 13:56:43 UTC+1, mark....@gmail.com wrote: >> On Friday, 18 October 2019 10:57:40 UTC+1, Bart wrote: >>> ... Here is the C equivalent of a bug >>> I found today: >>> >>> char *dataptr; >>> int *p; >>> >>> p = (int*)dataptr; >>> *p = x; >>> dataptr += 4; >> >> dataptr += sizeof(int); // fixed and future-proof >> >> Which is how it should have been coded in the first place. >> >> I'm not sure what your point is. >> > Not necessarily, no. This comes down to Tim Rentsch's point about data > and representation. Here, since we are messing about aliasing a char > pointer to a integer buffer, it's pretty clear that for some reason we > need 32 bit representation of integers in the computer memory. > On a little endian machine, writing "*p = x;" will work, even if x > is greater than 4 bytes, until we get to the end of the buffer, when > we trash a 4 byte piece of memory. On a big endian machine, it will break > when we try to read the value again. > > Creating a buffer of 32 bit big endian integers, creating a buffer of > 32 bit little endian integers, and creating a buffer of 32 bit integers > with native alignment are all reasonable things to do, especially > if you have to interface with binary file formats or non-C calling > conventions. However it's a low level action, it should be rare, normally > we want an "array of integers", with maybe some sanity limit saying that > they can't go anything like as high as 31 bits. > > If we want native 32 bit integers, then we should use int32_t, not int. The above code may need something to make sure the pointer/buffer is properly aligned to do so. If we want endian specific integer representation, then it is generally best to break the value down to individual bytes and deal with that. It can make sense at times to isolate that code into a function, and perhaps conditionally (ehen you KNOW what the endianness of the machine is) optimize based on that knowledge. The danger comes when presumptions about the machine characteristics are made, especially if there is no test for it, and even more if there is no documentation about it. The above code gives off a natural 'smell' due to the 'magic number' 4.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-18 07:20 -0700 |
| Message-ID | <b91de99c-1907-4011-aadf-b327e7526d5d@googlegroups.com> |
| In reply to | #147027 |
On Friday, 18 October 2019 14:42:09 UTC+1, Richard Damon wrote: > > If we want native 32 bit integers, then we should use int32_t, not int. > The above code may need something to make sure the pointer/buffer is > properly aligned to do so. > If int32_t is any use at all, then surely we will need it where we want a native 32 bit integer. However you've likely got the next sentence the wrong way round. Instead of fixing the buffer so that the integer is always 4 byte aligned, we maybe have to fix the write so that it works for all alignments. E.g. the buffer consists of an asciiz string followed by an integer. If the data is "Jim", 3 it will be properly aligned, but not if it is "Fred", 42. But unaligned integers could be what we want, that would explain why we are using a char * buffer rather than a C struct.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-18 15:29 +0100 |
| Message-ID | <s%jqF.1007838$TY7.100088@fx29.am4> |
| In reply to | #147031 |
On 18/10/2019 15:20, Malcolm McLean wrote: > On Friday, 18 October 2019 14:42:09 UTC+1, Richard Damon wrote: >> >> If we want native 32 bit integers, then we should use int32_t, not int. >> The above code may need something to make sure the pointer/buffer is >> properly aligned to do so. >> > If int32_t is any use at all, then surely we will need it where we > want a native 32 bit integer. However you've likely got the next sentence > the wrong way round. Instead of fixing the buffer so that the integer > is always 4 byte aligned, we maybe have to fix the write so that it works > for all alignments. E.g. the buffer consists of an asciiz string followed > by an integer. If the data is "Jim", 3 it will be properly aligned, but > not if it is "Fred", 42. But unaligned integers could be what we want, > that would explain why we are using a char * buffer rather than a C > struct. > Yeah, this is constructing an image of a binary file in memory, and it looks like ints will be unaligned (since it uses things like record sizes of 18 bytes). So technically the assignment should be done via memcpy. But if unaligned writes work, then why not? The first time it needs to work on a machine that traps those (which won't be x86) you will quickly find out and can fix it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-19 06:04 -0700 |
| Message-ID | <86r238hoo1.fsf@linuxsc.com> |
| In reply to | #147024 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 18 October 2019 13:56:43 UTC+1, mark....@gmail.com wrote: > >> On Friday, 18 October 2019 10:57:40 UTC+1, Bart wrote: >> >>> ... Here is the C equivalent of a bug >>> I found today: >>> >>> char *dataptr; >>> int *p; >>> >>> p = (int*)dataptr; >>> *p = x; >>> dataptr += 4; >> >> dataptr += sizeof(int); // fixed and future-proof >> >> Which is how it should have been coded in the first place. >> >> I'm not sure what your point is. > > Not necessarily, no. This comes down to Tim Rentsch's point about > data and representation. No, it doesn't. Please don't speak for me. You didn't understand the point I was making before, and obviously you still don't.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-18 13:36 +0000 |
| Message-ID | <jdjqF.23414$JD1.5167@fx11.iad> |
| In reply to | #147021 |
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);
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-18 15:17 +0100 |
| Message-ID | <tQjqF.2956617$xm3.2752908@fx15.am4> |
| In reply to | #147026 |
On 18/10/2019 14:36, Scott Lurndal 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);
>
The issue isn't with dataptr, which is correctly incremented by 4, to
point to the next field (in this case pointing to 1 past the end of the
buffer, as that *p assignment is the last thing written).
It's with writing 8 bytes via *p instead of 4. The correct code would
have been:
int32_t *p;
p = (int32_t*)dataptr;
*p = x;
(Or perhaps something like *(int32_t*)dataptr = x.)
This was overlooked since a 32-bit int is so widespread it can be assumed.
(This was something that happened for real in my language, which got
missed when I converted all 'int' types from 32 to 64 bits this year.
And an example of what could happen also in C, when people talk about
portable code but which breaks when switching to a differently sized set
of basic types.)
------------------------------------------------------------
(This code constructs an COFF object file in memory, by working out the
overall size, allocating memory, then filling in the different sections.
This fragment writes a 4-byte offset at the start of the string table,
but there were no strings so it's just that offset.
The bug caused it to write 4 bytes beyond the end of the exactly
allocated buffer by 4 bytes, causing an intermittent crash.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-18 16:44 +0100 |
| Message-ID | <87h8462h3z.fsf@bsb.me.uk> |
| In reply to | #147029 |
Bart <bc@freeuk.com> writes: > On 18/10/2019 14:36, Scott Lurndal 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); >> > > The issue isn't with dataptr, whiiginalch is correctly incremented by 4, to point to the next field (in this case pointing to 1 past the end of the buffer, as that *p assignment is the last thing written). > > It's with writing 8 bytes via *p instead of 4. The correct code would have been: > > int32_t *p; > > p = (int32_t*)dataptr; > *p = x; > > (Or perhaps something like *(int32_t*)dataptr = x.) > > This was overlooked since a 32-bit int is so widespread it can be > assumed. It can assumed only at the expense of errors. You led me astray as to what the problem was by saying that it occurs when int is 64 bits. No, the problem was already there, /even when the code was working/. If I were teaching C, this is a point I'd hammer home every day. The code assigns an int when that is not what is intended. You should try, as best you can, to write what is meant, not what works on this system on this machine with this compiler release. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-18 08:49 -0700 |
| Message-ID | <6be8dd59-a0cc-4e77-a600-3b2d7a4a5531@googlegroups.com> |
| In reply to | #147034 |
On Friday, 18 October 2019 16:44:41 UTC+1, Ben Bacarisse wrote: > > It can assumed only at the expense of errors. You led me astray as to > what the problem was by saying that it occurs when int is 64 bits. No, > the problem was already there, /even when the code was working/. If I > were teaching C, this is a point I'd hammer home every day. > > The code assigns an int when that is not what is intended. You should > try, as best you can, to write what is meant, not what works on this > system on this machine with this compiler release. > No, it's meant to assign a 32 bit integer. It may have to be little-endian, and it is not necessarily aligned. It's constructing a bit buffer, not a C structure in memory.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-18 17:56 +0200 |
| Message-ID | <qocnar$4t3$1@dont-email.me> |
| In reply to | #147035 |
On 18/10/2019 17:49, Malcolm McLean wrote: > On Friday, 18 October 2019 16:44:41 UTC+1, Ben Bacarisse wrote: >> >> It can assumed only at the expense of errors. You led me astray as to >> what the problem was by saying that it occurs when int is 64 bits. No, >> the problem was already there, /even when the code was working/. If I >> were teaching C, this is a point I'd hammer home every day. >> >> The code assigns an int when that is not what is intended. You should >> try, as best you can, to write what is meant, not what works on this >> system on this machine with this compiler release. >> > No, it's meant to assign a 32 bit integer. It may have to be little-endian, > and it is not necessarily aligned. It's constructing a bit buffer, not > a C structure in memory. > We don't know that. Please stop making stuff up, and guessing what bad code was supposed to do. The original code does not show what it means. It is unclear whether it meant "work with int, whatever size" and the error was in adding 4 to the pointer, or if it meant "work with int32_t", and the error was in using the wrong type for "p". And - again - endianness is not an issue. (If the code was intended to be endian specific, it was /certainly/ wrong because there is no indication of this.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-18 09:03 -0700 |
| Message-ID | <4c9ca200-9b18-4dbb-b71b-8c57a8995ae4@googlegroups.com> |
| In reply to | #147036 |
On Friday, 18 October 2019 16:56:21 UTC+1, David Brown wrote: > On 18/10/2019 17:49, Malcolm McLean wrote: > > On Friday, 18 October 2019 16:44:41 UTC+1, Ben Bacarisse wrote: > >> > >> It can assumed only at the expense of errors. You led me astray as to > >> what the problem was by saying that it occurs when int is 64 bits. No, > >> the problem was already there, /even when the code was working/. If I > >> were teaching C, this is a point I'd hammer home every day. > >> > >> The code assigns an int when that is not what is intended. You should > >> try, as best you can, to write what is meant, not what works on this > >> system on this machine with this compiler release. > >> > > No, it's meant to assign a 32 bit integer. It may have to be little-endian, > > and it is not necessarily aligned. It's constructing a bit buffer, not > > a C structure in memory. > > > > We don't know that. Please stop making stuff up, and guessing what bad > code was supposed to do. > Bart told us in a later post. The integer is part of a COFF file image held in memory. It represents the count of strings before the string table.
[toc] | [prev] | [next] | [standalone]
Page 6 of 25 — ← Prev page 1 … 4 5 [6] 7 8 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web