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 5 of 25 — ← Prev page 1 … 3 4 [5] 6 7 … 25 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-14 16:18 -0700 |
| Message-ID | <lnr23erk5h.fsf@kst-u.example.com> |
| In reply to | #146973 |
Bart <bc@freeuk.com> writes:
[...]
> Yet it doesn't contain the essential information I listed. Could you,
> just from that, create a table of field names, sizes and offsets,
> followed by a total struct size?
You could write a C program that prints the offsetof and sizeof values
for the members of the struct.
> And since this can vary by platform, how to get an accurate table for yours?
By compiling and running that program on each platform.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-14 23:42 +0000 |
| Message-ID | <qJ7pF.40267$FB1.12393@fx44.iad> |
| In reply to | #146979 |
Keith Thompson <kst-u@mib.org> writes:
>Bart <bc@freeuk.com> writes:
>[...]
>> Yet it doesn't contain the essential information I listed. Could you,
>> just from that, create a table of field names, sizes and offsets,
>> followed by a total struct size?
>
>You could write a C program that prints the offsetof and sizeof values
>for the members of the struct.
Indeed; One might even find a public domain program that processes
the debug information in the code file and prints details of a
structure:
$ pahole bin/a.out
struct lconv {
char * decimal_point; /* 0 8 */
char * thousands_sep; /* 8 8 */
char * grouping; /* 16 8 */
char * int_curr_symbol; /* 24 8 */
char * currency_symbol; /* 32 8 */
char * mon_decimal_point; /* 40 8 */
char * mon_thousands_sep; /* 48 8 */
char * mon_grouping; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
char * positive_sign; /* 64 8 */
char * negative_sign; /* 72 8 */
char int_frac_digits; /* 80 1 */
char frac_digits; /* 81 1 */
char p_cs_precedes; /* 82 1 */
char p_sep_by_space; /* 83 1 */
char n_cs_precedes; /* 84 1 */
char n_sep_by_space; /* 85 1 */
char p_sign_posn; /* 86 1 */
char n_sign_posn; /* 87 1 */
char int_p_cs_precedes; /* 88 1 */
char int_p_sep_by_space; /* 89 1 */
char int_n_cs_precedes; /* 90 1 */
char int_n_sep_by_space; /* 91 1 */
char int_p_sign_posn; /* 92 1 */
char int_n_sign_posn; /* 93 1 */
/* size: 96, cachelines: 2, members: 24 */
/* padding: 2 */
/* last cacheline: 32 bytes */
};
struct FILE {
int _flags; /* 0 4 */
/* XXX 4 bytes hole, try to pack */
char * _IO_read_ptr; /* 8 8 */
char * _IO_read_end; /* 16 8 */
char * _IO_read_base; /* 24 8 */
char * _IO_write_base; /* 32 8 */
char * _IO_write_ptr; /* 40 8 */
char * _IO_write_end; /* 48 8 */
char * _IO_buf_base; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
char * _IO_buf_end; /* 64 8 */
char * _IO_save_base; /* 72 8 */
char * _IO_backup_base; /* 80 8 */
char * _IO_save_end; /* 88 8 */
class _IO_marker * _markers; /* 96 8 */
class _IO_FILE * _chain; /* 104 8 */
int _fileno; /* 112 4 */
int _flags2; /* 116 4 */
__off_t _old_offset; /* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
short unsigned int _cur_column; /* 128 2 */
signed char _vtable_offset; /* 130 1 */
char _shortbuf[1]; /* 131 1 */
/* XXX 4 bytes hole, try to pack */
_IO_lock_t * _lock; /* 136 8 */
__off64_t _offset; /* 144 8 */
void * __pad1; /* 152 8 */
void * __pad2; /* 160 8 */
void * __pad3; /* 168 8 */
void * __pad4; /* 176 8 */
size_t __pad5; /* 184 8 */
/* --- cacheline 3 boundary (192 bytes) --- */
int _mode; /* 192 4 */
char _unused2[20]; /* 196 20 */
/* size: 216, cachelines: 4, members: 29 */
/* sum members: 208, holes: 2, sum holes: 8 */
/* last cacheline: 24 bytes */
};
....
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-10-15 16:40 +1300 |
| Message-ID | <h0ktd9FldqU19@mid.individual.net> |
| In reply to | #146973 |
On 15/10/2019 08:52, Bart wrote: > On 14/10/2019 20:33, Ian Collins wrote: >> On 15/10/2019 08:24, Bart wrote: > >>> Now I only need to find out what hell dev_t, ino_t, mode_t, nlink_t, >>> uid_t, gid_t, off_t, blksize_t and (phew!) blkcnt_t are when they're at >>> home! >> >> gcc -E /usr/include/sys/stat.h | grep typedef > > You have to compile it to unscramble it, OK (maybe there's an option to > just display the sizes and offsets of each field suitable for assembly, > and hence in a form adaptable to anything else). > > Doing that on Linux tells me that on Linux, there's YET ANOTHER layer of > typedefs involved. And not all the relevant ones are present in that file. Another layer, who cares? Everything you need is in the output of gcc -E. > Further, what that doesn't show is that some typedefs are guarded - only > defined if not already defined, so their actual definitions may be quite > different. That makes no sense? > Apart from which, I work on Windows. So why are you bitching about Linux? >> If you care about the fields in the structure, you should know what they >> are! > > Why can't I find out just by looking at the struct definition? > >> How many platforms doe glibc get use on? How many platforms does your >> version get used on? > > How about each platform only gets the customised version it needs? Really, are you serious? What a maintenance nightmare! >>> Now perhaps you'll understand why your suggestion doesn't really work. >>> >>> The man page is fine as a superficial description for someone coding in >>> C, who merely has to write '#include <sys/stat.h>' and has to worry >>> about nothing else. >> >> The man page isn't a superficial, it's a thorough one! > > Yet it doesn't contain the essential information I listed. Could you, > just from that, create a table of field names, sizes and offsets, > followed by a total struct size? > > And since this can vary by platform, how to get an accurate table for yours? That's already been answered elsethread -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2019-10-15 05:10 -0700 |
| Message-ID | <ff188b60-f50a-4800-b39d-2b33ab380e58@googlegroups.com> |
| In reply to | #146982 |
On Monday, October 14, 2019 at 8:40:34 PM UTC-7, Ian Collins wrote: > On 15/10/2019 08:52, Bart wrote: > > On 14/10/2019 20:33, Ian Collins wrote: > >> On 15/10/2019 08:24, Bart wrote: > > > >>> Now I only need to find out what hell dev_t, ino_t, mode_t, nlink_t, > >>> uid_t, gid_t, off_t, blksize_t and (phew!) blkcnt_t are when they're at > >>> home! > >> > >> gcc -E /usr/include/sys/stat.h | grep typedef > > > > You have to compile it to unscramble it, OK (maybe there's an option to > > just display the sizes and offsets of each field suitable for assembly, > > and hence in a form adaptable to anything else). > > > > Doing that on Linux tells me that on Linux, there's YET ANOTHER layer of > > typedefs involved. And not all the relevant ones are present in that file. > > Another layer, who cares? Everything you need is in the output of gcc -E. > > > Further, what that doesn't show is that some typedefs are guarded - only > > defined if not already defined, so their actual definitions may be quite > > different. > > That makes no sense? > > > Apart from which, I work on Windows. > > So why are you bitching about Linux? > > >> If you care about the fields in the structure, you should know what they > >> are! > > > > Why can't I find out just by looking at the struct definition? > > > >> How many platforms doe glibc get use on? How many platforms does your > >> version get used on? > > > > How about each platform only gets the customised version it needs? > > Really, are you serious? What a maintenance nightmare! > For once I agree. By the way, there is a large tech company located near Uber Corporate office on Market Street in San Francisco that went the route of having each platform getting a customized version. As a result, they have over 100 different builds. And I won't even mention the army of engineers that are needed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-14 12:00 -0700 |
| Message-ID | <lnv9srqhi8.fsf@kst-u.example.com> |
| In reply to | #146965 |
Bart <bc@freeuk.com> writes:
[...]
> Most people will not need to get that deeply involved, but I do, and I
> can see how ugly, badly patched and unreadable it all is, as well as
> sprawling. (Try and find struct stat inside sys/stat.h; it's not there!)
[...]
As you know, there's no requirement (in POSIX) for <sys/stat.h> to
define struct stat directly. It's perfectly legitimate for it to be
defined in some other header that <sys/stat.h> includes, directly or
indirectly.
To find out:
gcc -E /usr/include/sys/stat.h
This produces 557 lines of output on my system. Search for
"struct stat" at the beginning of a line and look for preprocessor
directives just before the definition.
The details can of course vary for compilers other than gcc and/or
library implementations other than glibc.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 12:33 +0200 |
| Message-ID | <qnkd2j$hpb$1@dont-email.me> |
| In reply to | #146783 |
On 09/10/2019 01:02, Anton Shepelev wrote:
> Bart:
>
>> I decided that void* should accommodate all kinds of
>> pointers, and that all would also use the same 32/64-bit
>> representation.
>
> If that is a property of your language, I have no
> objections. If that is a property that you impose upon the
> non-standard dialect of C that your tools generate, I demur.
>
>>> So your language is tied to a certain bit depth?
>>
>> The language supports 8/16/32/64/128-bit data types but
>> the default 'int' size is 64 bits, and calculations are
>> done at at least 64 bits.
>
> Then I should say it is tie. Native types (with hardware-
> dependent sizes) with minimal introspection (limits.h) are a
> good idea in terms of both long-term scalability and
> efficiency, whereas fixed-size types must also be supported
> for obvious reasons. An alternative solution to fixed-with
> types could be a macro or an extra-language facility that
> would expand into the smallest native type that can
> accomodate a specifed range or generate a compile-time error
> if such a type is not available on the machine, e.g.
>
> i: int // a/the native integer
> j: int(6000); // the smallest native int that can hold 6000
>
> My intuitive and simplified (mis)understanding and
> justification of the basic C types is as follows:
>
> -- Simple type identifiers unmodifed by adjectives
> represent the most natural type for the machine, so
> that `int' would be the most natural integer for the
> CPU.
>
> -- `long' identifes a extended size, perhaps unnatural or
> even unsupported natively by the CPU.
>
> -- `short' identifies a smaller size than the CPU can
> easily handle.
>
That is a reasonable approximation. It is not entirely accurate, but
I'm sure you know where to find more exact definitions.
One important point about the types in C is that the minimum sizes are
well defined. "int" is at least 16 bits (even on 8-bit systems), "long
int" is at least 32 bits, and "long long int" is at least 64 bits. But
the maximum sizes are not defined, and if you want maximum portability,
there are different representations allowed with ones' complement,
padding bits, etc. In practice, most people can assume two's complement
and no padding, with all sizes being powers of two.
And C provides a variety of fixed size types in <stdint.h>. So when you
want a 32-bit integer, you can use int32_t. If you want a type that is
as small as possible, but holds at least 8-bit unsigned and works even
on DSP's with CHAR_BIT > 8, you can use uint_least8_t. If you want to
hold a 16-bit number and have it as fast as possible for anything from
8-bit to 64-bit systems, you can use int_fast16_t. And so on. (You can
of course use typedefs here to suit application convenience.) So C lets
you use either kind of integer typing - fixed size or "target natural".
It doesn't let you be as specific about sizes and ranges as, say, Pascal
or Ada does.
>> But the generated C has to be either C32 or C64 form,
>> because the C code contains embedded assumptions about the
>> size of the target.
>
> I am not a systems programmer and have no idea what those
> assumptions are, but the type sizes may also depend on the
> compiler, unless they are the new C99 "extended integer-type
> names"...
>
I think what he means is that he, and some other programmers, make
unwarranted assumptions when programming for 32-bit systems or for
64-bit systems. It seems to be common amongst people with DOS and
Windows background, where it is common to think "long means 32-bit" and
"you can store a pointer in a long int". This is despite Windows common
headers having typedefs for fixed size types (MSVC didn't provide
<stdint.h> until recently, I believe.)
>> (Some people have suggested it is possible to generate C
>> without those assumptions; well those people can try
>> writing their own C code generators!)
>
> And you can follow their advice if it is sound, but I know
> nothing of the subject.
There is a lot that is hard about making a C code generator, or
designing and implementing your own language. Making code that is
correct for 32-bit and 64-bit targets (especially if limited to Windows
and Linux) is not one of these hard things - nor is getting object
pointer types and function pointer types right. It is quite a bit
harder if you have a pathological hatred of macros, typedefs, C99, or
any of the other useful language features that would make the job
simple. However, any use of C features that made the code generation
easier, more portable, or (heaven forbid!) correct, would detract from
Bart's primary aim of complaining about C.
>
>> I don't always see the message, so I'm not sure what will
>> trigger it. But with this for example, by itself in a
>> file:
>>
>> extern int sprintf(unsigned char*, ...);
>>
>> gcc will say: 'warning: conflicting types for built-in
>> function `sprintf'. This is a not a correct sprint
>> declaration, but it indicates it knows about the
>> 'official' sprintf and is keeping tabs.
>
> Yes, the names of standard C functions are reserved for
> external linkage. How do you want that declaration to work
> and what implementation to have?
>
>> Maybe there is a way around this but eliminating all or
>> most standard headers is something for which I don't know
>> the full implications.
>
> How's about a wrapper:
>
> #include <stdio.h>
> #include <string.h>
>
> static int bstrlen( unsigned char const *s )
> { return strlen( ( const char * )s ); }
>
> int main( int argc, char** argv )
> { printf("%i\n", bstrlen( (unsigned char * )"Hi, Bart!" ) );
> return 0;
> }
>
Ah, you are trying to confuse him with sensible solutions!
Bart doesn't want to do that sort of thing. He wants to use a function
called "sprintf" in his original language, with slightly different
details or semantics from the function in C, but to translate it
directly to the function "sprintf" in C. It is the same with his types
- he wants to translate a "generic reference" in his language directly
into "void *" in C, despite them being significantly different concepts,
and he wants to translate his "int" directly into C "int" despite
differences (such as overflow behaviour). These differences are, in
Bart's view, failings in C for not picking the exact behaviour he has in
his own language. The sane solution is to use wrappers or translations
as needed, but that would go against his principles of directly
translating and then blaming C for being wrong.
>> And for now, everything works fine, except for the people
>> who will say that C isn't C unless it passes
>> -std=cx -pedantic. I guess my code is not for them, then.
>
> You are interested in code that works with a set of
> compilers rather than in the standard. But do you have the
> specificaion of the exact common subset of the C dialect
> that your C compilers accept when invoked with default
> options? If not, how can you guarrantee that "everything
> works" in your code generator?
>
>> I think any additional efforts are better directed at a
>> proper native code back-end, thus eliminating the C stage
>> completely, than at keeping people here happy.
>
> What about the future generations of users and maintainers
> of your tools? Whereas the standard is set in stone, the C
> dialect that a set of currenly maintained compilers happen
> to accept by default is subject to change!
What future generations of users and maintainers would there be for
Bart's tools?
>
>> (Or I might just keep on using my C backend, which in
>> actuality works remarkably well, especially with a brisk
>> compiler like tcc in the chain, and not tell anyone about
>> it!)
>
> Especially if you build a specific version of TCC into your
> tool.
>
>> A pointer is simply an indirect reference to something
>> else.
>
> But this reference need not be made by means of an address.
> A pointer is an abstract concept with many possible
> implementations. Especially so in case of a function
> pointer.
>
>> If dealing with collections of non-matching pointers, or
>> writing a function that can deal generically with any kind
>> of pointer, then a common representation (like C's void*)
>> is useful.
>
> Not in true C, as you know.
>
>> C's arbitrary restriction (which you can get around with a
>> double cast anyway) is not helpful.
>
> Well, I have already said why I think it is not arbitrary.
> And no, you don't get around this restriction in true C. It
> is just that the compilers you employ *happen* to let you do
> that. They are not obliged to.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 14:22 +0100 |
| Message-ID | <5alnF.1041354$WI2.353384@fx34.am4> |
| In reply to | #146795 |
On 09/10/2019 11:33, David Brown wrote:
> One important point about the types in C is that the minimum sizes are
> well defined. "int" is at least 16 bits (even on 8-bit systems), "long
> int" is at least 32 bits, and "long long int" is at least 64 bits. But
> the maximum sizes are not defined, and if you want maximum portability,
> there are different representations allowed with ones' complement,
> padding bits, etc. In practice, most people can assume two's complement
> and no padding, with all sizes being powers of two.
How wide is 'long'? Is it wider than 'int'?
Is 'int64_t*' compatible with 'long long int*'?
Could 'long long int' be 128-bits? Is it?
Is 'char' signed or unsigned?
What is the printf format for 'clock_t'?
How wide is 'off_t'?
> There is a lot that is hard about making a C code generator, or
> designing and implementing your own language. Making code that is
> correct for 32-bit and 64-bit targets (especially if limited to Windows
> and Linux) is not one of these hard things - nor is getting object
> pointer types and function pointer types right. It is quite a bit
> harder if you have a pathological hatred of macros, typedefs, C99, or
> any of the other useful language features that would make the job
> simple. However, any use of C features that made the code generation
> easier, more portable, or (heaven forbid!) correct, would detract from
> Bart's primary aim of complaining about C.
The ASM target I've used up to know has none of those things, and
actually has fewer problems than using C. That's because I don't need to
grapple with its type system, among other things.
> Bart doesn't want to do that sort of thing. He wants to use a function
> called "sprintf" in his original language, with slightly different
> details or semantics from the function in C, but to translate it
I've actually eliminated all uses of sprintf (I used my own print
formatting), except one or two yet to do.
And I eliminated all uses of fprintf and printf, except in a handle of
places where it needs to directly do output via C function (the
alternative being via WinAPI), then I have a special directive that
emits literal C code, so it can be just right:
emitc "fprintf(f,""%.*s"",(i32)length,s);"
> What future generations of users and maintainers would there be for
> Bart's tools?
There won't be any. One reason for my tools to exist is as a protest.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 15:35 +0200 |
| Message-ID | <qnknn7$hs7$1@dont-email.me> |
| In reply to | #146798 |
On 09/10/2019 15:22, Bart wrote: > On 09/10/2019 11:33, David Brown wrote: > >> One important point about the types in C is that the minimum sizes are >> well defined. "int" is at least 16 bits (even on 8-bit systems), "long >> int" is at least 32 bits, and "long long int" is at least 64 bits. But >> the maximum sizes are not defined, and if you want maximum portability, >> there are different representations allowed with ones' complement, >> padding bits, etc. In practice, most people can assume two's complement >> and no padding, with all sizes being powers of two. > > How wide is 'long'? Is it wider than 'int'? You know the answer to that - it doesn't matter. > > Is 'int64_t*' compatible with 'long long int*'? You know the answer to that. (Not that it matters. Use the type that suits your needs - and access data by its type.) > > Could 'long long int' be 128-bits? Is it? It could be. If you are using "long long int", it is because you want at least 64 bits but don't care about the exact size. If you want /exactly/ 64-bits, use "int64_t". It is quite simple. > > Is 'char' signed or unsigned? Neither. If you care, use "signed char" or "unsigned char". > > What is the printf format for 'clock_t'? > It doesn't have one. Why would it? If you want a language where you can conveniently print out any type, pick something other than C. > How wide is 'off_t'? How would I know? It is not a standard type. > >> What future generations of users and maintainers would there be for >> Bart's tools? > > There won't be any. One reason for my tools to exist is as a protest. > But you are the only one protesting, and the only one who considers the protests remotely relevant. Really, it's not much of a protest.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 16:15 +0100 |
| Message-ID | <6QmnF.671262$VE7.222823@fx11.am4> |
| In reply to | #146800 |
On 09/10/2019 14:35, David Brown wrote:
> On 09/10/2019 15:22, Bart wrote:
>> How wide is 'long'? Is it wider than 'int'?
>
>> Is 'int64_t*' compatible with 'long long int*'?
>
> You know the answer to that - it doesn't matter.
> You know the answer to that. (Not that it matters. Use the type that
> suits your needs - and access data by its type.)
> Neither. If you care, use "signed char" or "unsigned char".
> It doesn't have one. Why would it?
> How would I know? It is not a standard type.
OK. Now suppose you want to access this C function, with its interface
defined as:
char* fn(long, long long int, char*, clock_t, off_t)
as a foreign function called from your own language. You need to declare
it as in your language using its own types:
i8 i16 i32 i64 u8 u16 u32 u64 plus pointers to those.
Which types would you choose? You will need to make a choice of i8 or u8
to suit the 'char' type.
What would you do with variable types (that vary between platforms)?
Once you've done that, you decide your language's compiler needs to
target C. How would you declare your replacement char*? How would you
declare your version of the function if the original C declaration is
also visible?
Would you perform any conversion of argument types to fn(), if only the
original declaration of fn was visible in the C code? (Eg. fn was a
function declared in a standard C header.) Because now you will be
passing 'signed char*' or 'unsigned char*' to something that is declared
as 'char*'.
I've been dealing with stuff like this for 25 years. If you've only been
using C stuff from C, then you haven't got a clue.
Try translating 100,000 lines of windows.h (spread over between 90 and
150 headers) into your language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 20:24 +0200 |
| Message-ID | <qnl8kb$tlp$1@dont-email.me> |
| In reply to | #146807 |
On 09/10/2019 17:15, Bart wrote: > On 09/10/2019 14:35, David Brown wrote: >> On 09/10/2019 15:22, Bart wrote: > >>> How wide is 'long'? Is it wider than 'int'? >> >>> Is 'int64_t*' compatible with 'long long int*'? >> > >> You know the answer to that - it doesn't matter. > >> You know the answer to that. (Not that it matters. Use the type that >> suits your needs - and access data by its type.) > >> Neither. If you care, use "signed char" or "unsigned char". > >> It doesn't have one. Why would it? > > >> How would I know? It is not a standard type. > > OK. Now suppose you want to access this C function, with its interface > defined as: > > char* fn(long, long long int, char*, clock_t, off_t) > > as a foreign function called from your own language. You need to declare > it as in your language using its own types: > > i8 i16 i32 i64 u8 u16 u32 u64 plus pointers to those. > > Which types would you choose? You will need to make a choice of i8 or u8 > to suit the 'char' type. > > What would you do with variable types (that vary between platforms)? Sorry, but you are asking a somewhat meaningless question. If you want to call a function written in C from your own language "Q", then you need to accommodate C's calling conventions on that platform (and, if you are unlucky enough to be working on Win32 which doesn't have a fixed ABI, the conventions for the particular compiler). If you are programming in C and want to call a function written in Q, then you need to interface to Q's calling conventions. So if C has a type "char" and Q does not have a suitable equivalent, then you need a translation layer in between. And the same applies if the positions are reversed. This happens all the time in calling foreign functions from other languages. The translation layer can vary from trivial (such as translating "i8" to "char"), to complex (like translating a UTF-16 string to a UTF-8 string, or a Visual Basic "variant" to a C++ object). Your problem is you insist this should be simple and a blind translation - and when it is not, you blame C rather than your own limited understanding. > > Once you've done that, you decide your language's compiler needs to > target C. How would you declare your replacement char*? How would you > declare your version of the function if the original C declaration is > also visible? > > Would you perform any conversion of argument types to fn(), if only the > original declaration of fn was visible in the C code? (Eg. fn was a > function declared in a standard C header.) Because now you will be > passing 'signed char*' or 'unsigned char*' to something that is declared > as 'char*'. > > I've been dealing with stuff like this for 25 years. If you've only been > using C stuff from C, then you haven't got a clue. > You mean you have been moaning pointlessly about C for 25 years, and you /still/ haven't learned how this works? > Try translating 100,000 lines of windows.h (spread over between 90 and > 150 headers) into your language. No, thank you.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 20:42 +0100 |
| Message-ID | <wKqnF.808606$bS1.336532@fx13.am4> |
| In reply to | #146814 |
On 09/10/2019 19:24, David Brown wrote: > On 09/10/2019 17:15, Bart wrote: >> What would you do with variable types (that vary between platforms)? > > Sorry, but you are asking a somewhat meaningless question. > > If you want to call a function written in C from your own language "Q", > then you need to accommodate C's calling conventions on that platform > (and, if you are unlucky enough to be working on Win32 which doesn't > have a fixed ABI, the conventions for the particular compiler). If you > are programming in C and want to call a function written in Q, then you > need to interface to Q's calling conventions. The ABI is not the problem (it's rather irrelevant actually; it's a technical detail of my compiler, for a specific target, and is not considered at all for a C target). So if C has a type "char" and Q does not have a suitable equivalent, > then you need a translation layer in between. And the same applies if > the positions are reversed. We are talking about universal types such as i8 i16 i32 i64, and pointers to such types. Or, sometimes, a pointer to a struct composed of those types. No translation layer is needed because both sides are low level. The problem is that C uses its own language and its poorly defined sets of types for such APIs (the limitations of which also result in libraries creating their own sets of types). Given the proper information, I can directly call C foreign functions even from my the dynamic, interpreted language. > This happens all the time in calling foreign functions from other > languages. The translation layer can vary from trivial (such as > translating "i8" to "char"), to complex (like translating a UTF-16 > string to a UTF-8 string, or a Visual Basic "variant" to a C++ object). As I said, no translation is needed. Only a universal interface language for which C is a poor substitute. C headers are designed to be used from C programs, so that all the issues of what types mean, whether functions are actual functions or macros etc, becomes irrelevant. > Your problem is you insist this should be simple and a blind translation > - and when it is not, you blame C rather than your own limited > understanding. Yes, the problem IS C, because if that function: char* fn(long, long long int, char*, clock_t, off_t) was instead specified as: u8* fn(i32, i64, u8*, u64, i64) then there would be no problem whatsoever. C insists on exposing woolly, poorly specified types such as 'char' and 'long long' and 'off_t' and 'clock_t' (the latter, on Linux, having its true type buried under 6 layers of typedefs and macros on one implementation). A universal interface would use universally understood types such as u8 or i32. > You mean you have been moaning pointlessly about C for 25 years, and you > /still/ haven't learned how this works? If you have never tried using C from a language entirely of your own, and tried using major libraries from it, then I'm sorry but you don't know what you're talking about. >> Try translating 100,000 lines of windows.h (spread over between 90 and >> 150 headers) into your language. > > No, thank you. Why not? According to you, it's a piece of piss. Everything is, and it's never C's fault!
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-09 10:40 -0700 |
| Message-ID | <dd99aeb0-e773-4bf8-8244-3b2564f992c1@googlegroups.com> |
| In reply to | #146800 |
On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown wrote: > On 09/10/2019 15:22, Bart wrote: > > On 09/10/2019 11:33, David Brown wrote: > > > >> One important point about the types in C is that the minimum sizes are > >> well defined. "int" is at least 16 bits (even on 8-bit systems), "long > >> int" is at least 32 bits, and "long long int" is at least 64 bits. But > >> the maximum sizes are not defined, and if you want maximum portability, > >> there are different representations allowed with ones' complement, > >> padding bits, etc. In practice, most people can assume two's complement > >> and no padding, with all sizes being powers of two. > > > > How wide is 'long'? Is it wider than 'int'? > > You know the answer to that - it doesn't matter. > > > > > Is 'int64_t*' compatible with 'long long int*'? > > You know the answer to that. (Not that it matters. Use the type that > suits your needs - and access data by its type.) > Actually, decision of Linux variants of gcc and clang to make thise type incompatible is really annoying and I can't think about any reasonable justification for such incompatibility. Your advice does not work in practice when you deal with includes written by somebody else (sometimes all of them "system' somebody else) part of which expects int64_t and the other part expects 'long long'. Then you have no choice than ugly casts, that, as it's always case with cast, can later on in the code's life, hide real bugs. > > > > > Could 'long long int' be 128-bits? Is it? > > It could be. If you are using "long long int", it is because you want > at least 64 bits but don't care about the exact size. If you want > /exactly/ 64-bits, use "int64_t". It is quite simple. > > > > > Is 'char' signed or unsigned? > > Neither. If you care, use "signed char" or "unsigned char". > > > > > What is the printf format for 'clock_t'? > > > > It doesn't have one. Why would it? If you want a language where you > can conveniently print out any type, pick something other than C. > > > How wide is 'off_t'? > > How would I know? It is not a standard type. > > > > >> What future generations of users and maintainers would there be for > >> Bart's tools? > > > > There won't be any. One reason for my tools to exist is as a protest. > > > > But you are the only one protesting, and the only one who considers the > protests remotely relevant. Really, it's not much of a protest.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 20:31 +0200 |
| Message-ID | <qnl92t$ns$1@dont-email.me> |
| In reply to | #146812 |
On 09/10/2019 19:40, already5chosen@yahoo.com wrote: > On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown > wrote: >> On 09/10/2019 15:22, Bart wrote: >>> On 09/10/2019 11:33, David Brown wrote: >>> >>>> One important point about the types in C is that the minimum >>>> sizes are well defined. "int" is at least 16 bits (even on >>>> 8-bit systems), "long int" is at least 32 bits, and "long long >>>> int" is at least 64 bits. But the maximum sizes are not >>>> defined, and if you want maximum portability, there are >>>> different representations allowed with ones' complement, >>>> padding bits, etc. In practice, most people can assume two's >>>> complement and no padding, with all sizes being powers of two. >>> >>> How wide is 'long'? Is it wider than 'int'? >> >> You know the answer to that - it doesn't matter. >> >>> >>> Is 'int64_t*' compatible with 'long long int*'? >> >> You know the answer to that. (Not that it matters. Use the type >> that suits your needs - and access data by its type.) >> > > > Actually, decision of Linux variants of gcc and clang to make thise > type incompatible is really annoying and I can't think about any > reasonable justification for such incompatibility. I would personally be happier if C were defined to make integer types with identical sizes and representations compatible. But they are not. I'm not sure why not - the only reason I can think of is to have compilers give diagnostics on a conversion that might hinder portability. Still, this is a decision of the C standards - not gcc or clang. (They could have made in64_t compatible with "long long int" - but then it would be incompatible with "long int" of the same size on 64-bit targets.) > > Your advice does not work in practice when you deal with includes > written by somebody else (sometimes all of them "system' somebody > else) part of which expects int64_t and the other part expects 'long > long'. Then you have no choice than ugly casts, that, as it's always > case with cast, can later on in the code's life, hide real bugs. > It is only pointers to these types that lead to compatibility issues, not the types themselves. But yes, you need to deal with this somehow. Often I think it is a good idea to consider the fixed size types and the base types as parallel sets of types - pick one set that is appropriate for the type of code, and use it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-09 12:02 -0700 |
| Message-ID | <lna7a9vj21.fsf@kst-u.example.com> |
| In reply to | #146815 |
David Brown <david.brown@hesbynett.no> writes:
> On 09/10/2019 19:40, already5chosen@yahoo.com wrote:
>> On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown
>> wrote:
>>> On 09/10/2019 15:22, Bart wrote:
[...]
>>>> Is 'int64_t*' compatible with 'long long int*'?
>>>
>>> You know the answer to that. (Not that it matters. Use the type
>>> that suits your needs - and access data by its type.)
>>
>> Actually, decision of Linux variants of gcc and clang to make thise
>> type incompatible is really annoying and I can't think about any
>> reasonable justification for such incompatibility.
The types long and long long are distinct and incompatible types, even
if they happen to be the same size. This is a language feature, not a
decision by gcc or clang.
The type int64_t is very likely to be a typedef for either long or
long long, which means it's either the same type as long or the same
type as long long (and is incompatible with the other).
For an implementation where long and long long are both 64 bits, and
therefore candidates for int64_t, it wouldn't occur to me to have a
preference for which one the implementation should pick. It's not safe
to assume that *any* [u]intN_t type is compatible with (meaning, in this
case, the same type as) any particular predefined type. If you're
making such an assumption, I suggest you're doing something wrong and
should reconsider your design.
> I would personally be happier if C were defined to make integer types
> with identical sizes and representations compatible. But they are not.
So C is too type-safe for you? 8-)}
> 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.
That's the reason, or at least part of it. If long and long long are
both 64 bits, making them compatible would mean you could freely assign
long* and long long* pointers without a cast -- and your code would
break on an implementation where they have different sizes.
They're different types.
Personally, I would have preferred it if the [u]intN_t types were all
incompatible with each other and with the predefined types. For this to
be done without compiler magic, we'd need something similar to typedef
except that it defines a new type rather than a new name for an existing
type. (int64_t would still be an integer type, and would still be
implicitly convertible to any other arithmetic type.) On the other
hand, that would cause problems with code that uses _Generic to cover
all possible integer types. (Such code already can't handle extended
integer types, but few compilers implement those.)
> Still, this is a decision of the C standards - not gcc or clang. (They
> could have made in64_t compatible with "long long int" - but then it
> would be incompatible with "long int" of the same size on 64-bit targets.)
>
>> Your advice does not work in practice when you deal with includes
>> written by somebody else (sometimes all of them "system' somebody
>> else) part of which expects int64_t and the other part expects 'long
>> long'. Then you have no choice than ugly casts, that, as it's always
>> case with cast, can later on in the code's life, hide real bugs.
>
> It is only pointers to these types that lead to compatibility issues,
> not the types themselves. But yes, you need to deal with this somehow.
> Often I think it is a good idea to consider the fixed size types and
> the base types as parallel sets of types - pick one set that is
> appropriate for the type of code, and use it.
Functions are another problem. If something requires a callback
function that takes an int64_t argument, you may or may not be able to
use a function that takes a long argument, depending on how the
implementation has defined int64_t.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 22:21 +0200 |
| Message-ID | <qnlffk$ai9$1@dont-email.me> |
| In reply to | #146817 |
On 09/10/2019 21:02, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 09/10/2019 19:40, already5chosen@yahoo.com wrote: >>> On Wednesday, October 9, 2019 at 4:35:43 PM UTC+3, David Brown >>> wrote: >>>> On 09/10/2019 15:22, Bart wrote: > [...] >>>>> Is 'int64_t*' compatible with 'long long int*'? >>>> >>>> You know the answer to that. (Not that it matters. Use the type >>>> that suits your needs - and access data by its type.) >>> >>> Actually, decision of Linux variants of gcc and clang to make thise >>> type incompatible is really annoying and I can't think about any >>> reasonable justification for such incompatibility. > > The types long and long long are distinct and incompatible types, even > if they happen to be the same size. This is a language feature, not a > decision by gcc or clang. > > The type int64_t is very likely to be a typedef for either long or > long long, which means it's either the same type as long or the same > type as long long (and is incompatible with the other). > > For an implementation where long and long long are both 64 bits, and > therefore candidates for int64_t, it wouldn't occur to me to have a > preference for which one the implementation should pick. It's not safe > to assume that *any* [u]intN_t type is compatible with (meaning, in this > case, the same type as) any particular predefined type. If you're > making such an assumption, I suggest you're doing something wrong and > should reconsider your design. > >> I would personally be happier if C were defined to make integer types >> with identical sizes and representations compatible. But they are not. > > So C is too type-safe for you? 8-)} > Not often, no! Very occasionally, I would like the convenience of being able to access data in odd ways through incompatible pointers - perhaps explicitly using 32-bit types for copying data around. (Usually memcpy is fine for the task.) But if I need that, I can get it - using pointer-to-volatile types, or using gcc extensions (the "may_alias" attribute) - this would be in low-level non-portable code anyway. It does, however, strike me as odd that types that represent identical data are incompatible. It doesn't hinder my programming, but I do think it would be natural to make them (and their pointers) compatible. >> 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. > > That's the reason, or at least part of it. If long and long long are > both 64 bits, making them compatible would mean you could freely assign > long* and long long* pointers without a cast -- and your code would > break on an implementation where they have different sizes. > > They're different types. > > Personally, I would have preferred it if the [u]intN_t types were all > incompatible with each other and with the predefined types. That would be a reasonable alternative, and more consistent that the existing situation. > For this to > be done without compiler magic, we'd need something similar to typedef > except that it defines a new type rather than a new name for an existing > type. That is something that I would /really/ like. I would be more than happy to give up any thoughts of making existing same-sized types compatible if I had a way to make "strong aliases" for existing types, especially ones that /cannot/ be implicitly converted to other types. I guess I'll head over to c.l.c++ now... > (int64_t would still be an integer type, and would still be > implicitly convertible to any other arithmetic type.) On the other > hand, that would cause problems with code that uses _Generic to cover > all possible integer types. (Such code already can't handle extended > integer types, but few compilers implement those.) > >> Still, this is a decision of the C standards - not gcc or clang. (They >> could have made in64_t compatible with "long long int" - but then it >> would be incompatible with "long int" of the same size on 64-bit targets.) >> >>> Your advice does not work in practice when you deal with includes >>> written by somebody else (sometimes all of them "system' somebody >>> else) part of which expects int64_t and the other part expects 'long >>> long'. Then you have no choice than ugly casts, that, as it's always >>> case with cast, can later on in the code's life, hide real bugs. >> >> It is only pointers to these types that lead to compatibility issues, >> not the types themselves. But yes, you need to deal with this somehow. >> Often I think it is a good idea to consider the fixed size types and >> the base types as parallel sets of types - pick one set that is >> appropriate for the type of code, and use it. > > Functions are another problem. If something requires a callback > function that takes an int64_t argument, you may or may not be able to > use a function that takes a long argument, depending on how the > implementation has defined int64_t. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-09 21:31 +0000 |
| Message-ID | <AksnF.113223$LG2.88525@fx48.iad> |
| In reply to | #146817 |
Keith Thompson <kst-u@mib.org> writes: >David Brown <david.brown@hesbynett.no> writes: > > >For an implementation where long and long long are both 64 bits, and >therefore candidates for int64_t, it wouldn't occur to me to have a >preference for which one the implementation should pick. For me, I'd prefer int64_t to always be 'long long'. Then I can use the same format specifiers with printf when compiling for both 32-bit and 64-bit targets.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-09 15:35 -0700 |
| Message-ID | <ln5zkxv968.fsf@kst-u.example.com> |
| In reply to | #146821 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>>For an implementation where long and long long are both 64 bits, and
>>therefore candidates for int64_t, it wouldn't occur to me to have a
>>preference for which one the implementation should pick.
>
> For me, I'd prefer int64_t to always be 'long long'. Then I can use
> the same format specifiers with printf when compiling for both 32-bit
> and 64-bit targets.
You can do that already, using the PRId64 macro from <inttypes.h>.
int64_t max = INT64_MAX;
printf("INT64_MAX = %" PRId64 "\n", max);
Or if you don't like those macros (I'm not a huge fan of them myself),
convert to long long:
printf("INT64_MAX = %lld\n", (long long)max);
If you want to use "%lld", why aren't you declaring your objects as long
long in the first place?
--
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-10 00:32 +0300 |
| Message-ID | <20191010003208.ff29e87d2de1e17c50f96c74@gmail.com> |
| In reply to | #146815 |
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. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-10 10:40 +0200 |
| Message-ID | <qnmqp7$n5p$1@dont-email.me> |
| In reply to | #146822 |
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".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-10 10:42 -0700 |
| Message-ID | <ln1rvkv6ob.fsf@kst-u.example.com> |
| In reply to | #146832 |
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.)
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.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 5 of 25 — ← Prev page 1 … 3 4 [5] 6 7 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web