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 7 of 25 — ← Prev page 1 … 5 6 [7] 8 9 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-18 19:14 +0200 |
| Message-ID | <qocrt2$187$1@dont-email.me> |
| In reply to | #147037 |
On 18/10/2019 18:03, Malcolm McLean wrote: > 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. > Later on, he gave some more information - that it was bad code for handling COFF files. But you can't tell from the code posted.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-18 23:45 +0100 |
| Message-ID | <874l053c6m.fsf@bsb.me.uk> |
| In reply to | #147035 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > 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. You appear to be agreeing with me. The code assign an int but that is not what the code should do. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-18 23:06 +0100 |
| Message-ID | <nHqqF.325546$3C5.149204@fx01.am4> |
| In reply to | #147034 |
On 18/10/2019 16:44, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> 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. The buffer overflow 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. Here's an example of a COFF description: http://www.ti.com/lit/an/spraao8/spraao8.pdf Notice the type of most fields is one of Char, Short, and Long, used for fields of 1, 2 and 4 bytes, which are begging to be represented in a C struct as char, short and long. And most of the time it will work, unless the code is compiled on Linux64 where long is 8 bytes. The point is it is very easy to use just a standard, non-fixed-width type.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-18 23:45 +0100 |
| Message-ID | <871rv93c67.fsf@bsb.me.uk> |
| In reply to | #147049 |
Bart <bc@freeuk.com> writes: > On 18/10/2019 16:44, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> 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. > > The buffer overflow occurs when int is 64 bits. The code was wrong from the start. Some wrong code works. Good code clearly expresses the intended semantics. The purpose of the code, apparently, is not to copy a C int but to copy four bytes. Do you really disagree with any of this? >> 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. > > Here's an example of a COFF description: > > http://www.ti.com/lit/an/spraao8/spraao8.pdf > > Notice the type of most fields is one of Char, Short, and Long, used > for fields of 1, 2 and 4 bytes, which are begging to be represented in > a C struct as char, short and long. And using a struct would introduce another error which would very likely go unnoticed for a long time too. > And most of the time it will work, unless the code is compiled on > Linux64 where long is 8 bytes. But, just to be clear, such code would be wrong, all the time, on all systems. > The point is it is very easy to use just a standard, non-fixed-width> type. Yes, I accept this point; it is indeed very easy to do that. Do you accept my point? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-19 00:49 +0100 |
| Message-ID | <_bsqF.1533286$qU.1470017@fx20.am4> |
| In reply to | #147051 |
On 18/10/2019 23:45, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 18/10/2019 16:44, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> 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.
>>
>> The buffer overflow occurs when int is 64 bits.
>
> The code was wrong from the start. Some wrong code works. Good code
> clearly expresses the intended semantics. The purpose of the code,
> apparently, is not to copy a C int but to copy four bytes. Do you
> really disagree with any of this?
Not quite. The four bytes are intended to store a single 32-bit value
(the size of a table). I think endian issues could come into it, because
the file format I believe is little-endian, but the machine could be
big-endian. So a simple memcpy might not be correct either.
But one assumption made (see below) was that the machine is
little-endian, and that unaligned accesses are fine.
>> And most of the time it will work, unless the code is compiled on
>> Linux64 where long is 8 bytes.
>
> But, just to be clear, such code would be wrong, all the time, on all
> systems.
>
>> The point is it is very easy to use just a standard, non-fixed-width> type.
>
> Yes, I accept this point; it is indeed very easy to do that. Do you
> accept my point?
I see your point but I don't agree. The original code plus the set of
assumptions it made would make it correct, provided those assumptions hold.
Changing the size of int (from 32 to 64 bits in another language, not C
which is staying at 32 for most platforms), something that had not been
anticipated, would break them.
Lots of things had to be changed: ints which had to stay at 32 bits had
to be changed to int32. int64 values, which specifically had to be that
size, stayed at int64 (not changed to int even though it was now 64 bits
anyway), to emphasise that.
Other things such as expecting 32-bit behaviour (for overflow or
wrapping) had to be taken care of.
'int' is still very commonly used in C, and it is still mostly 32 bits.
If you take 'unsigned int a, b', and do:
a += b;
then if this overflows, it will wrap, which is apparently not at an
error in C.
Now compile the code where int is 64 bits; the behaviour will be
different. Was/is the code in error by not stipulating a fixed integer
size to ensure overflow behaviour is consistent?
It sounds to be me as though all non-fixed width types would need to be
avoided if the same behaviour needs to be guaranteed for all allowed
ranges of char/short/int/long/long long.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-19 01:19 +0100 |
| Message-ID | <877e511t94.fsf@bsb.me.uk> |
| In reply to | #147058 |
Bart <bc@freeuk.com> writes: > On 18/10/2019 23:45, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 18/10/2019 16:44, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>>> 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. >>> >>> The buffer overflow occurs when int is 64 bits. >> >> The code was wrong from the start. Some wrong code works. Good code >> clearly expresses the intended semantics. The purpose of the code, >> apparently, is not to copy a C int but to copy four bytes. Do you >> really disagree with any of this? > > Not quite. The four bytes are intended to store a single 32-bit value > (the size of a table). I think endian issues could come into it, > because the file format I believe is little-endian, but the machine > could be big-endian. So a simple memcpy might not be correct either. Yes, I'm aware of that. I'm glad you agree that the code did not correctly express the required semantics. It was wrong from the get-go. It may be wrong in other ways (as you say, the encoding might be wrong) but I can't address that without knowing much more about the context. >>> And most of the time it will work, unless the code is compiled on >>> Linux64 where long is 8 bytes. >> >> But, just to be clear, such code would be wrong, all the time, on all >> systems. (Note: the context for "such code" has been lost: you added more problems by suggesting a C struct could be used.) >>> The point is it is very easy to use just a standard, non-fixed-width> type. >> >> Yes, I accept this point; it is indeed very easy to do that. Do you >> accept my point? > > I see your point but I don't agree. The original code plus the set of > assumptions it made would make it correct, provided those assumptions > hold. We are simply talking at cross purposes. For you "correct" means "works". For me, working code can be incorrect. I hope you don't dispute the fact that this bug would not have occurred had the code been Ben-correct rather than Bart-correct. (Of course there may be a cost, but that's another matter.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-19 11:16 +0100 |
| Message-ID | <5oBqF.2981630$xm3.1078785@fx15.am4> |
| In reply to | #147060 |
On 19/10/2019 01:19, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
> (Note: the context for "such code" has been lost: you added more
> problems by suggesting a C struct could be used.)
For this job, structs are used too. Example (generated version but the
original also uses fixed-width types):
struct coffrelocrec {
i32 virtualaddr;
i32 stindex;
i16 reloctype;
};
(Notice this last has a size of 10 bytes when summing the individual
fields, but in C has an overall size of 12 bytes.)
The field widths are all correct. What's missing here is that instances
of such structs have to be assembled into memory in a packed manner
which means each struct is not at the recommended alignment.
That doesn't matter as memcpy is used to copy an assembled struct into
the data image, and the whole image is then sent to a file as one block.
However, the memcpy must copy 10 bytes, not 12 bytes.
In C, sizeof(coffrelocrec) would be 12; you'd need to use pack(1) to fix
that, or not use sizeof for this.
In the original, 'pack(1)' is in permanent effect so that sizeof (.bytes
there) is safe to use (and in generated output, it uses constant 10
anyway, as well as pack(1) being set for the whole file).
Sometimes you have to work around the technically correct requirements
of the language in a way that would be frowned upon in a normal context.
> We are simply talking at cross purposes. For you "correct" means
> "works". For me, working code can be incorrect. I hope you don't
> dispute the fact that this bug would not have occurred had the code been
> Ben-correct rather than Bart-correct. (Of course there may be a cost,
> but that's another matter.)
Ben-correct might mean code working on any conceivable target with any
combination of C-legal data types, and any hardware byte-order. But that
might have its own costs (such as in more complex, less readable code).
In an application like this you may have to by-pass language
requirements anyway.
Bart-correct means this application that generates x64 code in a Win64
file format to run on Win64, will work on Win64. As a bonus, it will
likely work in most other places, even if the output file isn't useful
there.
Would I would really like to see is other applications put to the same
test (ie. compile on a C with a 64-bit int), and see how many still
work. Mine might have fared well by comparison!
(My own attempts to create a 64-bit-int C compiler ran into trouble
because the binary C library it uses, still uses 32-bit ints, requiring
a new set of standard headers for a start, as 'int' is used everywhere.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-19 03:56 -0700 |
| Message-ID | <ed086fb5-19a6-4364-8b10-f56c7dee2a93@googlegroups.com> |
| In reply to | #147067 |
On Saturday, 19 October 2019 11:16:42 UTC+1, Bart wrote:
> On 19/10/2019 01:19, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
>
> >
> > (Note: the context for "such code" has been lost: you added more
> > problems by suggesting a C struct could be used.)
>
> For this job, structs are used too. Example (generated version but the
> original also uses fixed-width types):
>
> struct coffrelocrec {
> i32 virtualaddr;
> i32 stindex;
> i16 reloctype;
> };
>
> (Notice this last has a size of 10 bytes when summing the individual
> fields, but in C has an overall size of 12 bytes.)
>
Yes, this half works.
In practice people do use C structs for laying out bit patterns
in memory. But you need to be careful. In this case "virtualaddr"
sounds like it is a pointer that has to be treated as an integer,
reloctype will be a C enum, so if you replace with the enum type
you will get an int, which will likely be 32 bits.
Then C compilers insert padding.
In B64, the language I have never got round to defining, arguments
will be passed via bit buffers. The idea is that you say what the
bits are and what they mean, explicitly, avoiding the layer of
abstraction which most languages provide, which can so easily
cause interoperability problems.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-19 13:29 +0100 |
| Message-ID | <871rv82a1h.fsf@bsb.me.uk> |
| In reply to | #147067 |
Bart <bc@freeuk.com> writes: > On 19/10/2019 01:19, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >> >> (Note: the context for "such code" has been lost: you added more >> problems by suggesting a C struct could be used.) > > For this job, structs are used too. Yes, you said. That's another potential error. It depends on the specification for the program. Sometimes the specification is "working by 5pm today on this system -- everything else can wait". >> We are simply talking at cross purposes. For you "correct" means >> "works". For me, working code can be incorrect. I hope you don't >> dispute the fact that this bug would not have occurred had the code been >> Ben-correct rather than Bart-correct. (Of course there may be a cost, >> but that's another matter.) > > Ben-correct might mean code working on any conceivable target with any > combination of C-legal data types, and any hardware byte-order. If that is what the specification says, then yes. My guess is that despite your desire to argue for the sake of it, you'd write a similar C program if the specification demanded it. > But > that might have its own costs (such as in more complex, less readable > code). Yes, as I said there may well be a cost, though I think "less readable" is unlikely if enough care is taken. > Would I would really like to see is other applications put to the same > test (ie. compile on a C with a 64-bit int), and see how many still > work. Mine might have fared well by comparison! That would be interesting. I am old enough to have experienced the 16-bit int to 32-bit int transition, but those were very different times (lots of K&R C, no standard void * etc, etc). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-19 08:44 -0400 |
| Message-ID | <MyDqF.68888$1A2.62906@fx07.iad> |
| In reply to | #147067 |
On 10/19/19 6:16 AM, Bart wrote:
> On 19/10/2019 01:19, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>
>> (Note: the context for "such code" has been lost: you added more
>> problems by suggesting a C struct could be used.)
>
> For this job, structs are used too. Example (generated version but the
> original also uses fixed-width types):
>
> struct coffrelocrec {
> i32 virtualaddr;
> i32 stindex;
> i16 reloctype;
> };
>
> (Notice this last has a size of 10 bytes when summing the individual
> fields, but in C has an overall size of 12 bytes.)
WRONG. The C standard does NOT define the size of that struct (it
provides some rules for what are allowable values). Possible values for
the size that I can think if (if i16 is int_least16_t) would be: 3, 5,
6, 10, 12, and even 24.
The size of the structure will depend on the alignment requirements of
the type i32 (presumably, int32_t). If the implementation aligns this
type on a 4 byte boundary, then the struct needs to be aligned on the
same sort of boundary, and thus (because of the rules for arrays) the
size needs to be a multiple of 4.
>
> The field widths are all correct. What's missing here is that instances
> of such structs have to be assembled into memory in a packed manner
> which means each struct is not at the recommended alignment.
>
> That doesn't matter as memcpy is used to copy an assembled struct into
> the data image, and the whole image is then sent to a file as one block.
>
> However, the memcpy must copy 10 bytes, not 12 bytes.
>
> In C, sizeof(coffrelocrec) would be 12; you'd need to use pack(1) to fix
> that, or not use sizeof for this.
>
> In the original, 'pack(1)' is in permanent effect so that sizeof (.bytes
> there) is safe to use (and in generated output, it uses constant 10
> anyway, as well as pack(1) being set for the whole file).
>
> Sometimes you have to work around the technically correct requirements
> of the language in a way that would be frowned upon in a normal context.
>
Using struct for external files format definitions has always been an
issue, because it is defined for in memory uses. That used to be much
more understood, because there WERE machines with more significant
differences, and thus file format definitions tended to be more precise.
Yes, the mistake you are making has been done many times before from
people thinking all the world uses machines just like mine, so they make
this sort of mistake.
>
>> We are simply talking at cross purposes. For you "correct" means
>> "works". For me, working code can be incorrect. I hope you don't
>> dispute the fact that this bug would not have occurred had the code been
>> Ben-correct rather than Bart-correct. (Of course there may be a cost,
>> but that's another matter.)
>
> Ben-correct might mean code working on any conceivable target with any
> combination of C-legal data types, and any hardware byte-order. But that
> might have its own costs (such as in more complex, less readable code).
>
> In an application like this you may have to by-pass language
> requirements anyway.
>
> Bart-correct means this application that generates x64 code in a Win64
> file format to run on Win64, will work on Win64. As a bonus, it will
> likely work in most other places, even if the output file isn't useful
> there.
>
> Would I would really like to see is other applications put to the same
> test (ie. compile on a C with a 64-bit int), and see how many still
> work. Mine might have fared well by comparison!
>
> (My own attempts to create a 64-bit-int C compiler ran into trouble
> because the binary C library it uses, still uses 32-bit ints, requiring
> a new set of standard headers for a start, as 'int' is used everywhere.)
i.e., you were making a C compiler but didn't want to do the full job.
The Standard Library IS part of a C implementation, and sharing outputs
across implementations requires them to be compatible enough.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-19 14:05 +0100 |
| Message-ID | <XSDqF.3394750$c8w1.657386@fx08.am4> |
| In reply to | #147072 |
On 19/10/2019 13:44, Richard Damon wrote:
> On 10/19/19 6:16 AM, Bart wrote:
>> On 19/10/2019 01:19, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>
>>> (Note: the context for "such code" has been lost: you added more
>>> problems by suggesting a C struct could be used.)
>>
>> For this job, structs are used too. Example (generated version but the
>> original also uses fixed-width types):
>>
>> struct coffrelocrec {
>> i32 virtualaddr;
>> i32 stindex;
>> i16 reloctype;
>> };
>>
>> (Notice this last has a size of 10 bytes when summing the individual
>> fields, but in C has an overall size of 12 bytes.)
>
> WRONG. The C standard does NOT define the size of that struct (it
> provides some rules for what are allowable values). Possible values for
> the size that I can think if (if i16 is int_least16_t) would be: 3, 5,
> 6, 10, 12, and even 24.
Then defining a struct to match a specific layout becomes pretty much
impossible, and you have to use unwieldy and costly (in programmer time)
alternatives.
Sometimes you HAVE to make some assumptions, eg. that char is one 8-bit
byte; i16 is 2 bytes; i32 is 4; there are no padding bits and no padding
bytes, and that pack(1) can be used to ensure no struct padding.
But according to Ben, such a program would be incorrec. Well he can try
explaining to my boss why my program is taking so much longer to write
and is so convoluted! And full of new, more obscure bugs.
>> (My own attempts to create a 64-bit-int C compiler ran into trouble
>> because the binary C library it uses, still uses 32-bit ints, requiring
>> a new set of standard headers for a start, as 'int' is used everywhere.)
>
> i.e., you were making a C compiler but didn't want to do the full job.
Not just to test to test my assertion that many C projects would stop
working. Although I might try again soon; it would still be simpler than
going for a 16-bit int, as that involves extensive code-gen changes when
the result must still run on x64).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-19 07:35 -0700 |
| Message-ID | <5da2e1fa-1f4a-4ea2-91e5-c1d74864fe05@googlegroups.com> |
| In reply to | #147075 |
On Saturday, 19 October 2019 14:06:06 UTC+1, Bart wrote:
> On 19/10/2019 13:44, Richard Damon wrote:
> > On 10/19/19 6:16 AM, Bart wrote:
> >> On 19/10/2019 01:19, Ben Bacarisse wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>
> >>>
> >>> (Note: the context for "such code" has been lost: you added more
> >>> problems by suggesting a C struct could be used.)
> >>
> >> For this job, structs are used too. Example (generated version but the
> >> original also uses fixed-width types):
> >>
> >> struct coffrelocrec {
> >> i32 virtualaddr;
> >> i32 stindex;
> >> i16 reloctype;
> >> };
> >>
> >> (Notice this last has a size of 10 bytes when summing the individual
> >> fields, but in C has an overall size of 12 bytes.)
> >
> > WRONG. The C standard does NOT define the size of that struct (it
> > provides some rules for what are allowable values). Possible values for
> > the size that I can think if (if i16 is int_least16_t) would be: 3, 5,
> > 6, 10, 12, and even 24.
>
> Then defining a struct to match a specific layout becomes pretty much
> impossible, and you have to use unwieldy and costly (in programmer time)
> alternatives.
>
Yes, it's impossible if you must use C and you don't know your particular
compiler. It's usually easy, and tempting, if you which compiler will
be used to compile the code. The standard library encourages this
with the fread and fwrite routines.
To do things portably, you need to set up a buffer of unsigned char (we
can probably assume that chars are octets), then push the data into
it, byte at a time. It's a real nuisance. However you rarely need a
defined bit pattern buffer in memory, only on disk or to write to
an output port. The exception is when you are interfacing with modules
written in other languages, or to interface to C modules compiled
with a different compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-19 18:01 +0100 |
| Message-ID | <sjHqF.710909$CO2.479405@fx30.am4> |
| In reply to | #147076 |
On 19/10/2019 15:35, Malcolm McLean wrote: > On Saturday, 19 October 2019 14:06:06 UTC+1, Bart wrote: >> On 19/10/2019 13:44, Richard Damon wrote: >>> WRONG. The C standard does NOT define the size of that struct (it >>> provides some rules for what are allowable values). Possible values for >>> the size that I can think if (if i16 is int_least16_t) would be: 3, 5, >>> 6, 10, 12, and even 24. >> >> Then defining a struct to match a specific layout becomes pretty much >> impossible, and you have to use unwieldy and costly (in programmer time) >> alternatives. >> > Yes, it's impossible if you must use C and you don't know your particular > compiler. It's usually easy, and tempting, if you which compiler will > be used to compile the code. The standard library encourages this > with the fread and fwrite routines. > > To do things portably, you need to set up a buffer of unsigned char (we > can probably assume that chars are octets), then push the data into > it, byte at a time. It's a real nuisance. However you rarely need a > defined bit pattern buffer in memory, only on disk or to write to > an output port. The exception is when you are interfacing with modules > written in other languages, or to interface to C modules compiled > with a different compiler. > That's a pretty big exception! In practice you're not going to get anywhere if the size of my example struct might be 3, 5, 6, 10, 12 or 24, even if its understood these will be char units not bytes, not that that helps. It should be OK to assume that your target is going to be the same one that also runs Java, C#, D, Rust, Go and so on, byte-addressable machines with no padding bits, no padding bytes, that use twos complement, and support 8/16/32/64-bit basic types, so that sizeof() will give 12 or 10 depending on pack(). That won't be enough for the purists here of course.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-19 20:14 +0100 |
| Message-ID | <87pniszgwy.fsf@bsb.me.uk> |
| In reply to | #147075 |
Bart <bc@freeuk.com> writes:
> On 19/10/2019 13:44, Richard Damon wrote:
>> On 10/19/19 6:16 AM, Bart wrote:
>>> On 19/10/2019 01:19, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>
>>>> (Note: the context for "such code" has been lost: you added more
>>>> problems by suggesting a C struct could be used.)
>>>
>>> For this job, structs are used too. Example (generated version but the
>>> original also uses fixed-width types):
>>>
>>> struct coffrelocrec {
>>> i32 virtualaddr;
>>> i32 stindex;
>>> i16 reloctype;
>>> };
>>>
>>> (Notice this last has a size of 10 bytes when summing the individual
>>> fields, but in C has an overall size of 12 bytes.)
>>
>> WRONG. The C standard does NOT define the size of that struct (it
>> provides some rules for what are allowable values). Possible values for
>> the size that I can think if (if i16 is int_least16_t) would be: 3, 5,
>> 6, 10, 12, and even 24.
>
> Then defining a struct to match a specific layout becomes pretty much
> impossible,
No, it makes it pretty much impossible in 100% portable code. You know
this. At no point have you said what degree of portability is required
for this imaginary code, so everyone has been guessing. As a result,
whatever we guess you can claim it's wrong.
It is very common to match some external format with a C struct. I hope
(someone contrary to experience) that programmer who do this know what
they are doing. (I get more comfortable when I see static asserts in
such code.)
> Sometimes you HAVE to make some assumptions, eg. that char is one
> 8-bit byte; i16 is 2 bytes; i32 is 4; there are no padding bits and no
> padding bytes, and that pack(1) can be used to ensure no struct
> padding.
When do you /have/ assume all that? When you are in a rush? I don't
think anyone is arguing against cutting corners when you are under
extreme time pressure. We've all hacked code together in a rush and
kept our fingers crossed, and we've had to fix code like that that
someone else wrote late one Friday afternoon.
> But according to Ben, such a program would be incorrec.
Don't put words into my mouth. You either misrepresent or misunderstand
too often for this to be a good strategy for you. I explicitly said
that if the requirements was for something in a hurry, it would not be
incorrect to make time-saving assumptions.
> Well he can try explaining to my boss why my program is taking so much
> longer to write and is so convoluted! And full of new, more obscure
> bugs.
That's just dishonestly misrepresenting my point of view. If the spec
allows simplifying assumptions, I'll use them. If it doesn't, then you
would agree that I'd be wrong to use your "shortcuts" (AKA bugs).
I don't think there really is a difference of opinion here; you are
trying to manufacture one. You know it's wrong to assume that int is,
say, 32 bits, just as I know that there can be situations in which it's
worth assume that it is (though I hope I'd put in a check).
I think we disagree on two points:
(A) I think you want C to specify all this so that struct s { int i;
char c; }; means what you want it to mean on all systems for all
time.
(B) You would make these kinds of assumption more often than I would.
I've spent a lot of time on portable code that packs byte arrays, so
I don't think it's clumsy, time consuming or error prone.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-19 23:12 +0100 |
| Message-ID | <ATLqF.990733$Jh2.953939@fx39.am4> |
| In reply to | #147085 |
On 19/10/2019 20:14, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Sometimes you HAVE to make some assumptions, eg. that char is one
>> 8-bit byte; i16 is 2 bytes; i32 is 4; there are no padding bits and no
>> padding bytes, and that pack(1) can be used to ensure no struct
>> padding.
>
> When do you /have/ assume all that?
I spent 15 years writing commercial software for PCs, an architecture
that only very slowly evolved, and stayed backwards compatible.
Then you could make such assumptions, because they would be correct for
all machines of interest. And most customers would only be able to buy
those anyway. So it would have been pointless from a business point of
view to waste time on trying to support anything else.
Now I'm interested in programming for the range of architectures I can
myself buy as hands-on consumer equipment, which isn't actually that
much wider - ARM can be added to the x86 family, and that's about it. (I
don't write programs for servers which I know nothing about anyway.)
Those assumptions still hold.
> (A) I think you want C to specify all this so that struct s { int i;
> char c; }; means what you want it to mean on all systems for all
> time.
And, for an even longer time, I generally coded in a language where such
a struct would have exactly 3, 5 or 9 bytes (depending on the default
int size of the language).
C is supposed to gives lots of control, but you have to make some effort
to stop it padding fields and padding the overall size of a struct.
(Most of my structs are carefully crafted to have a tidy, efficient
layout. If I had one that was 65 bytes, then that wouldn't pass.)
> (B) You would make these kinds of assumption more often than I would.
> I've spent a lot of time on portable code that packs byte arrays, so
> I don't think it's clumsy, time consuming or error prone.
>
Yes, I understand you're an academic, such things would be of more
interest. I'd only be interested if they solve an actual problem.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-10-20 00:45 +0100 |
| Message-ID | <87eez8z4do.fsf@bsb.me.uk> |
| In reply to | #147094 |
Bart <bc@freeuk.com> writes: > On 19/10/2019 20:14, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Sometimes you HAVE to make some assumptions, eg. that char is one >>> 8-bit byte; i16 is 2 bytes; i32 is 4; there are no padding bits and no >>> padding bytes, and that pack(1) can be used to ensure no struct >>> padding. >> >> When do you /have/ assume all that? > > I spent 15 years writing commercial software for PCs, an architecture > that only very slowly evolved, and stayed backwards compatible. > > Then you could make such assumptions, because they would be correct > for all machines of interest. Yes, I know. You haven't answered the question. You stressed "HAVE" to suggest a very strong imperative. Your example is simply of a "could" not of a "HAVE". > And most customers would only be able to > buy those anyway. So it would have been pointless from a business > point of view to waste time on trying to support anything else. If you had said "Sometimes it's POINTLESS not to make some assumptions" who would have argued? (But then I think you want an argument.) > C is supposed to gives lots of control, but you have to make some > effort to stop it padding fields and padding the overall size of a > struct. C gives you lots of control. It does not let you control the padding in a struct. Both are true and you (and everyone here) knows that. Putting the two together as you have is spin. You really do write like a political speech writer. >> (B) You would make these kinds of assumption more often than I would. >> I've spent a lot of time on portable code that packs byte arrays, so >> I don't think it's clumsy, time consuming or error prone. > > Yes, I understand you're an academic, such things would be of more > interest. I'd only be interested if they solve an actual problem. That's a nasty remark. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-20 10:24 +0100 |
| Message-ID | <7JVqF.2997876$xm3.1836092@fx15.am4> |
| In reply to | #147101 |
On 20/10/2019 00:45, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> Yes, I understand you're an academic, such things would be of more >> interest. I'd only be interested if they solve an actual problem. > > That's a nasty remark. Why?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 14:39 +0200 |
| Message-ID | <qohkhk$oro$1@dont-email.me> |
| In reply to | #147075 |
On 19/10/2019 15:05, Bart wrote:
> On 19/10/2019 13:44, Richard Damon wrote:
>> On 10/19/19 6:16 AM, Bart wrote:
>>> On 19/10/2019 01:19, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>
>>>>
>>>> (Note: the context for "such code" has been lost: you added more
>>>> problems by suggesting a C struct could be used.)
>>>
>>> For this job, structs are used too. Example (generated version but the
>>> original also uses fixed-width types):
>>>
>>> struct coffrelocrec {
>>> i32 virtualaddr;
>>> i32 stindex;
>>> i16 reloctype;
>>> };
>>>
>>> (Notice this last has a size of 10 bytes when summing the individual
>>> fields, but in C has an overall size of 12 bytes.)
>>
>> WRONG. The C standard does NOT define the size of that struct (it
>> provides some rules for what are allowable values). Possible values for
>> the size that I can think if (if i16 is int_least16_t) would be: 3, 5,
>> 6, 10, 12, and even 24.
>
> Then defining a struct to match a specific layout becomes pretty much
> impossible, and you have to use unwieldy and costly (in programmer time)
> alternatives.
Yes - now you are beginning to understand.
C - the standard - does not have any facilities for defining a struct to
match a specific layout. Many aspects of a struct's representation is
implementation dependent, such as the sizes of the fields, the
alignments, the padding, the endianness.
When you have to match an external format, you have three choices.
You can use portable and independent methods, such as reading bytes at a
time and calculating larger values with shifts and or's, independent of
endianness, alignments and sizes. This is a bit more programmer effort,
but usually only needed at a few specific points (such reading and
writing the file format). On poorer compilers the code will be slow -
on better compilers, it can often be quite efficient.
Or you can write compiler and target specific code, that only works on
the platforms you need, and can rely on assumptions about the compiler
and target because these are fixed. It can use compiler extensions like
"packed" pragmas or attributes. Compile-time checks and static
assertions can ensure that the code fails to compile on other targets.
Or you can write a combination - use conditional compilation to pick
compiler or target specific efficient methods, with a fall-back to
portable but perhaps inefficient code in other cases.
I suppose there is a third method - write non-portable code in a
thoughtless, ignorant and lazy way and just hope it works.
>
> Sometimes you HAVE to make some assumptions, eg. that char is one 8-bit
> byte; i16 is 2 bytes; i32 is 4; there are no padding bits and no padding
> bytes, and that pack(1) can be used to ensure no struct padding.
>
> But according to Ben, such a program would be incorrec. Well he can try
> explaining to my boss why my program is taking so much longer to write
> and is so convoluted! And full of new, more obscure bugs.
Personally, I am happy with code that makes assumptions - as long as
things are going to fail /hard/ (i.e., compile-time errors) if the
assumptions don't hold, and that the assumptions are clear in the code.
So if you really need 8-bit bytes (and you don't need them as often as
many people think, but you /do/ need them sometimes), use "uint8_t" as
your type. It makes the assumptions clear, and on platforms that don't
fulfil those assumptions, compilation will fail. Similarly, int16_t and
int32_t types fulfil your requirements about padding and alignment.
A _Static_assert on the size of the struct will keep you safe regarding
unexpected alignments or paddings - /and/ give you an extra check that
you haven't made a mistake in your struct definition.
Rather than using "pack", I much prefer to put any padding in manually.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-20 06:11 -0700 |
| Message-ID | <580858af-4704-4100-80a9-24edff9ff59a@googlegroups.com> |
| In reply to | #147107 |
On Sunday, 20 October 2019 13:39:30 UTC+1, David Brown wrote: > > A _Static_assert on the size of the struct will keep you safe regarding > unexpected alignments or paddings - /and/ give you an extra check that > you haven't made a mistake in your struct definition. > But when the static assert fails, what is the maintaining programmer expected to do? It's unlikely that he can set compiler flags so that the struct comes in at the correct size.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-20 15:36 +0200 |
| Message-ID | <qohnt7$oq0$1@dont-email.me> |
| In reply to | #147111 |
On 20/10/2019 15:11, Malcolm McLean wrote: > On Sunday, 20 October 2019 13:39:30 UTC+1, David Brown wrote: >> >> A _Static_assert on the size of the struct will keep you safe regarding >> unexpected alignments or paddings - /and/ give you an extra check that >> you haven't made a mistake in your struct definition. >> > But when the static assert fails, what is the maintaining programmer > expected to do? It's unlikely that he can set compiler flags so that > the struct comes in at the correct size. > He or she will then need to see if the code can be adapted to work on the platform in question, and make the changes. Surely you are not suggesting that it is better to let the program compile, knowing that it could not possibly work correctly?
[toc] | [prev] | [next] | [standalone]
Page 7 of 25 — ← Prev page 1 … 5 6 [7] 8 9 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web