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 12 of 25 — ← Prev page 1 … 10 11 [12] 13 14 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-12 19:13 +0200 |
| Message-ID | <qnt1ju$90l$1@dont-email.me> |
| In reply to | #146894 |
On 12/10/2019 16:29, Bart wrote: > On 12/10/2019 14:00, David Brown wrote: >> On 12/10/2019 13:42, Bart wrote: > >>> I guess not. C's zoo of types is one thing that hasn't much been >>> copied by anything else. >> >> Many newer programming languages have more ways to make new types than >> C, and stronger typing. > > It's not even about new types, but the same type. The generic int32 type > can be represented in most desktop Cs as: > > int, long (sometimes) long long (possible?) int32_t > > C implementations may contain their own internal versions (eg. __int32) > > MS additionally defines INT, INT32, LONG, LONG32 for that type. > > SDL uses Sint32; Opengl has GLint; GTK has gint32; STB uses stb__int32 > > Seed7 uses INT32TYPE and int32Type. > > SQLite doesn't have signed int32, but uses UINT32_TYPE and u32 > > What is it about C that makes every program want to define its own > version of the basic types? (And I do the same in C!) > Most of these are for projects from before C99 and <stdint.h> was standardised. I have no idea what /your/ excuse is. > C has poor support for such type aliases so their uses should be kept to > a minimum. C has perfectly good support for type aliases - you use "typedef" to make an alias. What more could you want? (For complex types, you might want a nicer syntax - C++ gained it with "using", but C has not followed.) Typedef's should be used freely whenever the programmer feels it improves the clarity of the program. They would certainly make /your/ work a great deal easier. > > Given integer type aliases T and U, what type will T*U be? What is the > MIN and MAX values of T or U? What format code should be used for T or > U? What size of literal will they accommodate? Will it need an L or LL > suffix? Are T* and U* compatible? Will I lose info storing a U type into > a T type? > Sorry, but if you don't know what you are doing when you are programming, don't program. That means you should not use types, functions, variables, etc., that you don't understand. > > Certainly if I were designing a new language, >> I'd have a way to make new integer types that were not implicitly >> convertible back or forth with other integer types. I'd expect to go >> through a lot more types defined in my code than I do in C programming >> (and in C, my programs can easily have 50-100 typedefs). > > One 45Kloc project of mine uses exactly two numeric user types (plus two > dozen to do with defining versions of the MS Windows types so that I can > declare WinAPI functions). > > This is partly because the language provides a solid and reliable set of > basic types, whose names are not too objectionable and are consistent. We write different kinds of programs in different styles and with different languages. So? > >> What makes C typing a little unusual is that it is designed to support >> such a range of possible target systems - that leads to it having a >> large number of basic types with different characteristics, letting >> people pick the types they want to suit their needs. Languages that >> have more fixed requirements (such as requiring a 32-bit target with >> 64-bit support) can let them simplify things. > > Power-of-two types can be easily accommodated. Then you just have to > choose whether 'int', and default calculations, use 8, 16, 32 or 64 > bits, and whether it's worth supporting 64 or possibly 32-bit ops. > >> There are use-cases for languages with different typing systems. Some >> people prefer stronger type systems (I do). Others like weaker type >> systems or typeless languages - clearly your preferences are more in >> that direction. C is a language that is sort of in the middle in >> regards to typing. > > I see any strongly enforced scheme or user numeric types heading in the > direction of Ada, which makes my kind of casual programming difficult. > > Since we are talking about low-level languages, we can use low-level types. > Ada is a language designed for low-level programming (and portable higher level programming). >>> Dozens more are named pointer types to those 30, or to char or other >>> types. >> >> Again, those are useful. > > Sorry, no. Your job, when trying to call any of the plethora of WinAPI > functions from your own language, and therefore have to painstakingly > recreate every function in that language, is whether any pointer type is > one of these: C was not designed for people writing in other languages - it was designed for people in C. Maybe that's what's confusing you. > > i8* i16* i32* i64* > u8* u16* u32* u64* > void* > > Most of the time a void* will do. The actual thing that is passed will > be a 32-bit address, or 64-bit address, depending on machine. > > All those Long-pointer-to-string types are a waste of time. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-12 19:04 +0100 |
| Message-ID | <YAooF.296775$3C5.108226@fx01.am4> |
| In reply to | #146896 |
On 12/10/2019 18:13, David Brown wrote:
> On 12/10/2019 16:29, Bart wrote:
> Most of these are for projects from before C99 and <stdint.h> was
> standardised.
Which is now 20 years ago, and was available for longer. It also shows
there is a real need for such types as most non-trivial programs seems
to use them.
> I have no idea what /your/ excuse is.
I use a set of names that matches the original language, which are also
compact names that save space in the generated code. But I would also
use aliases anyway because I dislike typing names with _t suffixes as it
affects code readability, and it affects my ability to type them. (_ is
a shift key on my keyboard, and I am a very clumsy typist.)
>> C has poor support for such type aliases so their uses should be kept
>> to a minimum.
>
> C has perfectly good support for type aliases - you use "typedef" to
> make an alias.
>> Given integer type aliases T and U, what type will T*U be? What is the
>> MIN and MAX values of T or U? What format code should be used for T or
>> U? What size of literal will they accommodate? Will it need an L or LL
>> suffix? Are T* and U* compatible? Will I lose info storing a U type
>> into a T type?
>>
>
> Sorry, but if you don't know what you are doing when you are
> programming, don't program.
So you create a new numeric typedef like this:
typedef ??? T;
The idea is partly to make the original type ??? opaque. But there are
some problems:
* How do you do equivalent of INT_MAX for T? (Assume it is an int)
* How do you do the equivalent of prinf("%d",X) when X is of type T?
You can't just brush these off by insulting the person who raises them.
I said that C has these problems with such typedefs - FACT.
Here is hoe a language can make it easier, with examples from mine:
type T = ???
* The equivalent of INT_MAX, you do 'T.maxvalue'
* To print X of type T, you do 'print X'
Simple, yes?
That means you should not use types,
> functions, variables, etc., that you don't understand.
In a properly designed language, it's not a problem. I'm not saying that
C should be redesigned now, but since it has such issues, typedefs
should be used less, and certainly now gratuitously, something I see all
the time.
> C was not designed for people writing in other languages - it was
> designed for people in C.
So any programs using the WinAPI must use the C language and no other?
Rubbish. The same for the 100s/1000s of libraries that use the C interface.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 20:13 -0400 |
| Message-ID | <t_toF.117829$LG2.38599@fx48.iad> |
| In reply to | #146897 |
On 10/12/19 2:04 PM, Bart wrote:
> On 12/10/2019 18:13, David Brown wrote:
>> On 12/10/2019 16:29, Bart wrote:
>
>> Most of these are for projects from before C99 and <stdint.h> was
>> standardised.
>
> Which is now 20 years ago, and was available for longer. It also shows
> there is a real need for such types as most non-trivial programs seems
> to use them.
>
>> I have no idea what /your/ excuse is.
>
> I use a set of names that matches the original language, which are also
> compact names that save space in the generated code. But I would also
> use aliases anyway because I dislike typing names with _t suffixes as it
> affects code readability, and it affects my ability to type them. (_ is
> a shift key on my keyboard, and I am a very clumsy typist.)
>
>>> C has poor support for such type aliases so their uses should be kept
>>> to a minimum.
>>
>> C has perfectly good support for type aliases - you use "typedef" to
>> make an alias.
>
>
>>> Given integer type aliases T and U, what type will T*U be? What is
>>> the MIN and MAX values of T or U? What format code should be used for
>>> T or U? What size of literal will they accommodate? Will it need an L
>>> or LL suffix? Are T* and U* compatible? Will I lose info storing a U
>>> type into a T type?
>>>
>>
>> Sorry, but if you don't know what you are doing when you are
>> programming, don't program.
>
> So you create a new numeric typedef like this:
>
> typedef ??? T;
>
> The idea is partly to make the original type ??? opaque. But there are
> some problems:
>
> * How do you do equivalent of INT_MAX for T? (Assume it is an int)
Of course, when you define your typedef, YOU should know what type you
are using so you can define your own T_MAX and such, perhaps refering to
the defines of the type you are basing it on.
>
> * How do you do the equivalent of prinf("%d",X) when X is of type T?
You define your own version of the PRIxxx macro, maybe PRI_T, again you
know the type you are starting from, so you know the code for that (or
at least what macro defines it)
>
> You can't just brush these off by insulting the person who raises them.
> I said that C has these problems with such typedefs - FACT.
>
> Here is hoe a language can make it easier, with examples from mine:
>
> type T = ???
>
> * The equivalent of INT_MAX, you do 'T.maxvalue'
>
> * To print X of type T, you do 'print X'
>
> Simple, yes?
If you want that, maybe you want C++ which define a lot of that
information with templages. You also should be able to build something
like that out of C's newish _Generic support
>
>
> That means you should not use types,
>> functions, variables, etc., that you don't understand.
>
> In a properly designed language, it's not a problem. I'm not saying that
> C should be redesigned now, but since it has such issues, typedefs
> should be used less, and certainly now gratuitously, something I see all
> the time.
>
>> C was not designed for people writing in other languages - it was
>> designed for people in C.
>
> So any programs using the WinAPI must use the C language and no other?
> Rubbish. The same for the 100s/1000s of libraries that use the C interface.
>
Actually, the WinAPI isn't really defined in C terms, but in Microsoft's
variant of the C language. Most of the parameters zre defined in terms
of macros defined in Windows headers. Microsoft also uses a bunch of
extentions for calling conventions. The fact that the Microsoft C
compiler doesn't conform to any of the more recent C Standards doesn't
help there either.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-13 01:36 +0100 |
| Message-ID | <WjuoF.1059364$WI2.610641@fx34.am4> |
| In reply to | #146905 |
On 13/10/2019 01:13, Richard Damon wrote:
> On 10/12/19 2:04 PM, Bart wrote:
>> typedef ??? T;
>>
>> The idea is partly to make the original type ??? opaque. But there are
>> some problems:
>>
>> * How do you do equivalent of INT_MAX for T? (Assume it is an int)
>
> Of course, when you define your typedef, YOU should know what type you
> are using so you can define your own T_MAX and such, perhaps refering to
> the defines of the type you are basing it on.
>>
>> * How do you do the equivalent of prinf("%d",X) when X is of type T?
>
> You define your own version of the PRIxxx macro, maybe PRI_T, again you
> know the type you are starting from, so you know the code for that (or
> at least what macro defines it)
That is not how anybody ever uses typedef! And would anyway create a
group of inter-depencies, where you change the definition of T, but now
also have to change the MAX macro and the format code.
>>
>> You can't just brush these off by insulting the person who raises them.
>> I said that C has these problems with such typedefs - FACT.
>>
>> Here is hoe a language can make it easier, with examples from mine:
>>
>> type T = ???
>>
>> * The equivalent of INT_MAX, you do 'T.maxvalue'
>>
>> * To print X of type T, you do 'print X'
>>
>> Simple, yes?
>
>
> If you want that, maybe you want C++
Actually, I already have it, but thanks all the same...
>You also should be able to build something
> like that out of C's newish _Generic support
_Generic has a problem, because you can't for example have both int64_t
and long long int as cases, if they are the same type, as they will
clash. This can happen when int64_t is defined in terms of long long int.
Even if not the same type, it can fail on a machine where they are.
> Actually, the WinAPI isn't really defined in C terms, but in Microsoft's
> variant of the C language.
They called it C, now they take the same APIs and call it C++, but it is
really just C. Some newer libraries do use actual C++, but the old ones
are still C.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 22:52 -0400 |
| Message-ID | <wjwoF.113916$TC2.60866@fx43.iad> |
| In reply to | #146907 |
On 10/12/19 8:36 PM, Bart wrote:
> On 13/10/2019 01:13, Richard Damon wrote:
>> On 10/12/19 2:04 PM, Bart wrote:
>
>>> typedef ??? T;
>>>
>>> The idea is partly to make the original type ??? opaque. But there are
>>> some problems:
>>>
>>> * How do you do equivalent of INT_MAX for T? (Assume it is an int)
>>
>> Of course, when you define your typedef, YOU should know what type you
>> are using so you can define your own T_MAX and such, perhaps refering to
>> the defines of the type you are basing it on.
>>>
>>> * How do you do the equivalent of prinf("%d",X) when X is of type T?
>>
>> You define your own version of the PRIxxx macro, maybe PRI_T, again you
>> know the type you are starting from, so you know the code for that (or
>> at least what macro defines it)
>
> That is not how anybody ever uses typedef! And would anyway create a
> group of inter-depencies, where you change the definition of T, but now
> also have to change the MAX macro and the format code.
>
Strange, that is EXACTLY how I and most people I know use them. You
write a header to provide a type. In that header (if I need to support
the _MAX macro) I put
typedef int Type;
#define Type_MAX INT_MAX
#define PRI_Type "d"
or if using a stdint type
typedef int16_t Type
#define Type_MAX INT16_MAX
#define PRI_Type PRI_i16
Yes, if I change the type, I need to make the corresponding change to
the next two lines. Not a big issue for me.
>>>
>>> You can't just brush these off by insulting the person who raises them.
>>> I said that C has these problems with such typedefs - FACT.
>>>
>>> Here is hoe a language can make it easier, with examples from mine:
>>>
>>> type T = ???
>>>
>>> * The equivalent of INT_MAX, you do 'T.maxvalue'
>>>
>>> * To print X of type T, you do 'print X'
>>>
>>> Simple, yes?
>>
>>
>> If you want that, maybe you want C++
>
> Actually, I already have it, but thanks all the same...
>
>> You also should be able to build something
>> like that out of C's newish _Generic support
>
> _Generic has a problem, because you can't for example have both int64_t
> and long long int as cases, if they are the same type, as they will
> clash. This can happen when int64_t is defined in terms of long long int.
>
> Even if not the same type, it can fail on a machine where they are.
>
The solution is you define the _Generic for all the base types (which
int65_t isn't) and not for any of the derived typedef types, these have
the advantage that C provides a complete enumeration of the standard
base types. Thus you would build the definitions for the following set
of types
_Bool (if applicable for what you are doing)
char
signed char
unsigned char
short
unsigned short
int
unsigned int
long
unsigned long
long long
unsigned long long
All of these MUST be distinct types (as far as the C type system is
concerned, some may have compatible representation)
If the implementation defines additional extended integer types (or
types that are almost extended integer types like __int128) you would
need to add those to the list.
Because all the other types are define via typedef as an alias, they
will lookup the _Generic for that basic type.
>> Actually, the WinAPI isn't really defined in C terms, but in Microsoft's
>> variant of the C language.
>
> They called it C, now they take the same APIs and call it C++, but it is
> really just C. Some newer libraries do use actual C++, but the old ones
> are still C.
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-12 23:06 -0700 |
| Message-ID | <86zhi56ux1.fsf@linuxsc.com> |
| In reply to | #146907 |
Bart <bc@freeuk.com> writes: > On 13/10/2019 01:13, Richard Damon wrote: > > [how to find the maximum value of a typedef'ed type name] > >> You also should be able to build something >> like that out of C's newish _Generic support > > _Generic has a problem, because you can't for example have both > int64_t and long long int as cases, if they are the same type, as they > will clash. This can happen when int64_t is defined in terms of long > long int. > > Even if not the same type, it can fail on a machine where they are. Think harder. This isn't that hard a problem. An important thing to understand about Bart is he isn't looking for answers, he's looking for an argument. He isn't trying to solve problems; if a solution is suggested it will elicit from him either (a) some disagreement or complaint about the solution, or (b) a change of subject to another "problem". Wash, rinse, repeat. In essence there is really only one problem: Bart is a narcissist, and the only ideas that have value are the ones he likes (or even better, that he thought up himself). This problem will never be resolved by any technical discussion.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-13 10:25 +0100 |
| Message-ID | <74CoF.3142699$c8w1.71653@fx08.am4> |
| In reply to | #146911 |
On 13/10/2019 07:06, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > >> On 13/10/2019 01:13, Richard Damon wrote: >> >> [how to find the maximum value of a typedef'ed type name] >> >>> You also should be able to build something >>> like that out of C's newish _Generic support >> >> _Generic has a problem, because you can't for example have both >> int64_t and long long int as cases, if they are the same type, as they >> will clash. This can happen when int64_t is defined in terms of long >> long int. >> >> Even if not the same type, it can fail on a machine where they are. > > Think harder. This isn't that hard a problem. That in itself is the issue. You shouldn't NEED to think harder to avoid a clash between two types or to get around all these myriad problems. Not everyone is Tim Rentsch and able to think up weird and wonderful solutions. C's type system IS a mess - fact. No argument needed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-13 16:42 +0200 |
| Message-ID | <qnvd5j$3rb$1@dont-email.me> |
| In reply to | #146897 |
On 12/10/2019 20:04, Bart wrote:
> On 12/10/2019 18:13, David Brown wrote:
>> On 12/10/2019 16:29, Bart wrote:
>
>> Most of these are for projects from before C99 and <stdint.h> was
>> standardised.
>
> Which is now 20 years ago, and was available for longer. It also shows
> there is a real need for such types as most non-trivial programs seems
> to use them.
Yes, which is why they were introduced in C99! The world moved slower
in 1999 - it took a long time before compilers supported it properly (MS
was spectacularly bad), and longer before programmers started using it
regularly, and even longer before people making code that would be
widely used could rely on it.
If you have some suggestion for how to encourage people to move over to
C99 <stdint.h> types instead of project-specific or library-specific
versions, I'd love to hear it. Claiming "C types are a joke" or
inventing your own pet language certainly aren't useful suggestions.
>
>> I have no idea what /your/ excuse is.
>
> I use a set of names that matches the original language, which are also
> compact names that save space in the generated code.
You use non-standard types to save a few bytes of space in a C file.
Really? This is your justification?
> But I would also
> use aliases anyway because I dislike typing names with _t suffixes as it
> affects code readability, and it affects my ability to type them. (_ is
> a shift key on my keyboard, and I am a very clumsy typist.)
This is /generated/ code. You don't need to type it.
>
>>> C has poor support for such type aliases so their uses should be kept
>>> to a minimum.
>>
>> C has perfectly good support for type aliases - you use "typedef" to
>> make an alias.
>
>
>>> Given integer type aliases T and U, what type will T*U be? What is
>>> the MIN and MAX values of T or U? What format code should be used for
>>> T or U? What size of literal will they accommodate? Will it need an L
>>> or LL suffix? Are T* and U* compatible? Will I lose info storing a U
>>> type into a T type?
>>>
>>
>> Sorry, but if you don't know what you are doing when you are
>> programming, don't program.
>
> So you create a new numeric typedef like this:
>
> typedef ??? T;
>
> The idea is partly to make the original type ??? opaque. But there are
> some problems:
>
> * How do you do equivalent of INT_MAX for T? (Assume it is an int)
>
Define it - if you need to use it. I can't speak for anyone else, but I
have almost never needed to use these limits.
> * How do you do the equivalent of prinf("%d",X) when X is of type T?
C only has standardised IO functions for the base types, plus a couple
more. It does not have a way to extend existing functions. It does not
support object oriented programming, function overloads, or other
features needed to be able to make /new/ types that are treated like
built-in types. It is a small language with a small library - you have
to write these kinds of things yourself. (If you don't like it, pick a
different language.)
In this particular case, of course, you can just define a macro with the
same printf format specifier as the type you are aliasing. It will work
perfectly well.
So you can write:
typedef counter_t int;
#define counter_t_max INT_MAX
#define PRIicounter %i
Most of the time, I would expect the define's to be unnecessary.
>
> You can't just brush these off by insulting the person who raises them.
> I said that C has these problems with such typedefs - FACT.
It is a fact that you said this, yes. It is not a fact C has a problem
with making type aliases. It /is/ a fact that if you try, you can
invent artificial problems.
>
> Here is hoe a language can make it easier, with examples from mine:
>
> type T = ???
>
> * The equivalent of INT_MAX, you do 'T.maxvalue'
>
> * To print X of type T, you do 'print X'
>
> Simple, yes?
I agree that having something like Ada's "attributes" is a nice feature
in a language, and that C doesn't have anything equivalent.
Having a "print X" statement is convenient here. But unless you also
have a way to extend /any/ function to work with your new types, you
have only gone one small step forward.
>
>
> That means you should not use types,
>> functions, variables, etc., that you don't understand.
>
> In a properly designed language, it's not a problem.
Really? I'd say it is always a problem, in all programming, in all
languages. I certainly have never come across a programming language
that was so "perfectly designed" that it was okay to mess around with
code you don't understand.
> I'm not saying that
> C should be redesigned now, but since it has such issues, typedefs
> should be used less, and certainly now gratuitously, something I see all
> the time.
Typedefs should be used whenever they make the code clearer, more
portable, more maintainable, more likely to be error-free, or simply
because the code is easier to write. /No/ feature in any language
should be used gratuitously - and I have no reason to suspect that
typedef /is/ used gratuitously in code.
>
>> C was not designed for people writing in other languages - it was
>> designed for people in C.
>
> So any programs using the WinAPI must use the C language and no other?
> Rubbish. The same for the 100s/1000s of libraries that use the C interface.
>
The original C language was designed primarily by Deniis Ritchie and his
collegues in about 1972. Can you show me a reference to where he was
involved in making the WinAPI at the time?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-13 18:03 +0100 |
| Message-ID | <iNIoF.887096$yH4.625540@fx18.am4> |
| In reply to | #146914 |
On 13/10/2019 15:42, David Brown wrote: > On 12/10/2019 20:04, Bart wrote: >> I use a set of names that matches the original language, which are >> also compact names that save space in the generated code. > > You use non-standard types to save a few bytes of space in a C file. No, so that when I examine the code, it matches the original language, by using canonical representations. > Really? This is your justification? Using uint64_t instead of u8 only adds about 3% to file sizes (of generated code) but it adversely affects readability when you do need to look at it. >> But I would also use aliases anyway because I dislike typing names >> with _t suffixes as it affects code readability, and it affects my >> ability to type them. (_ is a shift key on my keyboard, and I am a >> very clumsy typist.) > > This is /generated/ code. You don't need to type it. Here, the 'anyway' means when I /am/ typing it. > C only has standardised IO functions for the base types, plus a couple > more. It does not have a way to extend existing functions. It does not > support object oriented programming, function overloads, or other > features needed to be able to make /new/ types that are treated like > built-in types. It is a small language with a small library - you have > to write these kinds of things yourself. (If you don't like it, pick a > different language.) C can't even properly do I/O for its built-in types. But I'm not suggesting fixing any of that. Just pointing out that it's inflexible format codes scheme doesn't work well with more opaque types. >> So any programs using the WinAPI must use the C language and no other? >> Rubbish. The same for the 100s/1000s of libraries that use the C >> interface. >> > > The original C language was designed primarily by Deniis Ritchie and his > collegues in about 1972. Can you show me a reference to where he was > involved in making the WinAPI at the time? > Ritchie et al weren't at fault. It started, on Windows, when OS functionality was exposed to user applications via an interface specified in C, and on Unix probably earlier than that. Of course, people will want to program in any language. The only OS interfaces I'd come across before then, used assembly or machine-code (when you didn't just go through your HLL), which was more solidly defined.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-13 19:50 +0200 |
| Message-ID | <qnvo5p$8ie$1@dont-email.me> |
| In reply to | #146915 |
On 13/10/2019 19:03, Bart wrote: > On 13/10/2019 15:42, David Brown wrote: >> On 12/10/2019 20:04, Bart wrote: > >>> I use a set of names that matches the original language, which are >>> also compact names that save space in the generated code. >> >> You use non-standard types to save a few bytes of space in a C file. > > No, so that when I examine the code, it matches the original language, > by using canonical representations. > >> Really? This is your justification? > > Using uint64_t instead of u8 only adds about 3% to file sizes (of > generated code) but it adversely affects readability when you do need to > look at it. I can appreciate wanting to have the names match the source and the generated code. > >>> But I would also use aliases anyway because I dislike typing names >>> with _t suffixes as it affects code readability, and it affects my >>> ability to type them. (_ is a shift key on my keyboard, and I am a >>> very clumsy typist.) >> >> This is /generated/ code. You don't need to type it. > > Here, the 'anyway' means when I /am/ typing it. Fair enough. I don't think it's much of an excuse - there are lots of characters typed with the shift key. And as for code readability - well, I guess that's a matter of taste. > >> C only has standardised IO functions for the base types, plus a couple >> more. It does not have a way to extend existing functions. It does >> not support object oriented programming, function overloads, or other >> features needed to be able to make /new/ types that are treated like >> built-in types. It is a small language with a small library - you >> have to write these kinds of things yourself. (If you don't like it, >> pick a different language.) > > C can't even properly do I/O for its built-in types. But I'm not > suggesting fixing any of that. Just pointing out that it's inflexible > format codes scheme doesn't work well with more opaque types. > I can quite agree that C has somewhat limited I/O support for its built-in types, and it has no standardised extensible method of printing out anything. > >>> So any programs using the WinAPI must use the C language and no >>> other? Rubbish. The same for the 100s/1000s of libraries that use the >>> C interface. >>> >> >> The original C language was designed primarily by Deniis Ritchie and >> his collegues in about 1972. Can you show me a reference to where he >> was involved in making the WinAPI at the time? >> > > Ritchie et al weren't at fault. It started, on Windows, when OS > functionality was exposed to user applications via an interface > specified in C, and on Unix probably earlier than that. > > Of course, people will want to program in any language. > I said "C was designed for people programming in C, not for people writing in other languages". Presumably you agree with that? People have later used C and C calling conventions as a go-between for different languages, but that was not part of its original design. > The only OS interfaces I'd come across before then, used assembly or > machine-code (when you didn't just go through your HLL), which was more > solidly defined. C API's are /far/ more solidly defined and standardised than assembly API's were. On almost all systems - with Windows being the only exception I know of - you have a well-documented ABI that specifies exactly what sizes, alignments, etc., you have for the different C types used, as well as exactly which registers and stack conventions are in play. It doesn't matter that "int" might be 16-bit on one platform and 32-bit on a different platform - the ABI says what it means on the platform in question. It is precisely because it is (relatively) simple and clear, as well as commonly used and understood, that C is the lingua franca of APIs. (The WinAPI is a bit of an oddity, since - despite your claims - it is /not/ defined in C terms, does not use a calling convention that matches common C conventions, and there is no standardised ABI or calling convention for the platform. It is a kind of hybrid between old assembly habits, Pascal-like calling conventions, and C.)
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-14 12:27 -0700 |
| Message-ID | <b03b3771-ce94-4e09-86fa-5a7b1a7b771f@googlegroups.com> |
| In reply to | #146916 |
On Sunday, October 13, 2019 at 8:50:57 PM UTC+3, David Brown wrote: > On 13/10/2019 19:03, Bart wrote: > > On 13/10/2019 15:42, David Brown wrote: > >> On 12/10/2019 20:04, Bart wrote: > > > >>> I use a set of names that matches the original language, which are > >>> also compact names that save space in the generated code. > >> > >> You use non-standard types to save a few bytes of space in a C file. > > > > No, so that when I examine the code, it matches the original language, > > by using canonical representations. > > > >> Really? This is your justification? > > > > Using uint64_t instead of u8 only adds about 3% to file sizes (of > > generated code) but it adversely affects readability when you do need to > > look at it. > > I can appreciate wanting to have the names match the source and the > generated code. > > > > >>> But I would also use aliases anyway because I dislike typing names > >>> with _t suffixes as it affects code readability, and it affects my > >>> ability to type them. (_ is a shift key on my keyboard, and I am a > >>> very clumsy typist.) > >> > >> This is /generated/ code. You don't need to type it. > > > > Here, the 'anyway' means when I /am/ typing it. > > Fair enough. I don't think it's much of an excuse - there are lots of > characters typed with the shift key. And as for code readability - > well, I guess that's a matter of taste. > > > > >> C only has standardised IO functions for the base types, plus a couple > >> more. It does not have a way to extend existing functions. It does > >> not support object oriented programming, function overloads, or other > >> features needed to be able to make /new/ types that are treated like > >> built-in types. It is a small language with a small library - you > >> have to write these kinds of things yourself. (If you don't like it, > >> pick a different language.) > > > > C can't even properly do I/O for its built-in types. But I'm not > > suggesting fixing any of that. Just pointing out that it's inflexible > > format codes scheme doesn't work well with more opaque types. > > > > I can quite agree that C has somewhat limited I/O support for its > built-in types, and it has no standardised extensible method of printing > out anything. > > > > >>> So any programs using the WinAPI must use the C language and no > >>> other? Rubbish. The same for the 100s/1000s of libraries that use the > >>> C interface. > >>> > >> > >> The original C language was designed primarily by Deniis Ritchie and > >> his collegues in about 1972. Can you show me a reference to where he > >> was involved in making the WinAPI at the time? > >> > > > > Ritchie et al weren't at fault. It started, on Windows, when OS > > functionality was exposed to user applications via an interface > > specified in C, and on Unix probably earlier than that. > > > > Of course, people will want to program in any language. > > > > I said "C was designed for people programming in C, not for people > writing in other languages". Presumably you agree with that? > > People have later used C and C calling conventions as a go-between for > different languages, but that was not part of its original design. > > > > The only OS interfaces I'd come across before then, used assembly or > > machine-code (when you didn't just go through your HLL), which was more > > solidly defined. > > C API's are /far/ more solidly defined and standardised than assembly > API's were. On almost all systems - with Windows being the only > exception I know of - you have a well-documented ABI that specifies > exactly what sizes, alignments, etc., you have for the different C types > used, as well as exactly which registers and stack conventions are in > play. It doesn't matter that "int" might be 16-bit on one platform and > 32-bit on a different platform - the ABI says what it means on the > platform in question. It is precisely because it is (relatively) simple > and clear, as well as commonly used and understood, that C is the lingua > franca of APIs. > Or, may be, your horizons for OSes and OS interfaces are .., a little narrow ?! I'd guess that those, more than myself acquainted with Z/OS, would not agree with your assertion. I don't have to guess to tell you, that people, more than myself acquainted with VMS, do not agree with your assertion. > (The WinAPI is a bit of an oddity, since - despite your claims - it is > /not/ defined in C terms, does not use a calling convention that matches > common C conventions, and there is no standardised ABI or calling > convention for the platform. It is a kind of hybrid between old > assembly habits, Pascal-like calling conventions, and C.) Not sure what you mean by "assembly habits". May be, something related to DOS-compatible parts of Win16 API? Win32 is certainly an example of C-oriented API. Calling conventions are slightly different from prevalent C calling conventions of platform, but they are supported by all C compilers. But, more importantly, basic assumptions of the API are very much C-ish. Like passing parameters by value or through pointer, which is also sort of "by value". Passing array as pointer. Extensive use of structures that are defined and documented in terms of C language. Even strings are mostly ASCIIZ, at least for non-Unicode variant of the API. I'd say, among non-unices, Windows API is one of the most C-oriented. Non counting, of course, various "executives" which or not quite OSes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-15 10:26 +0200 |
| Message-ID | <qo3vru$9kp$1@dont-email.me> |
| In reply to | #146971 |
On 14/10/2019 21:27, already5chosen@yahoo.com wrote: > On Sunday, October 13, 2019 at 8:50:57 PM UTC+3, David Brown wrote: >> On 13/10/2019 19:03, Bart wrote: >>> The only OS interfaces I'd come across before then, used assembly >>> or machine-code (when you didn't just go through your HLL), which >>> was more solidly defined. >> >> C API's are /far/ more solidly defined and standardised than >> assembly API's were. On almost all systems - with Windows being >> the only exception I know of - you have a well-documented ABI that >> specifies exactly what sizes, alignments, etc., you have for the >> different C types used, as well as exactly which registers and >> stack conventions are in play. It doesn't matter that "int" might >> be 16-bit on one platform and 32-bit on a different platform - the >> ABI says what it means on the platform in question. It is >> precisely because it is (relatively) simple and clear, as well as >> commonly used and understood, that C is the lingua franca of APIs. >> > > Or, may be, your horizons for OSes and OS interfaces are .., a little > narrow ?! > > I'd guess that those, more than myself acquainted with Z/OS, would > not agree with your assertion. I don't have to guess to tell you, > that people, more than myself acquainted with VMS, do not agree with > your assertion. > The context was more for PC's than systems like Z/OS. Mainframe and mini computers have generally had far tighter specifications than the PC world. (And at the other end of the scale, on microcontrollers, API's are usually specified in C, usually with rigidly defined type sizes. On the smallest devices, they might be specified at assembly level. But you often have the source code of all the parts, and you often have a small API since you have a small device.) > >> (The WinAPI is a bit of an oddity, since - despite your claims - it >> is /not/ defined in C terms, does not use a calling convention that >> matches common C conventions, and there is no standardised ABI or >> calling convention for the platform. It is a kind of hybrid >> between old assembly habits, Pascal-like calling conventions, and >> C.) > > Not sure what you mean by "assembly habits". May be, something > related to DOS-compatible parts of Win16 API? Yes. The Windows API evolved in parts from the DOS world, 16-bit Windows, and then 32-bit Windows. Some of the older stuff was more free-form assembly, then later I believe a Pascal-like calling convention (i.e., stack the first parameter first, rather than last as is common in C) became common. > > Win32 is certainly an example of C-oriented API. Calling conventions > are slightly different from prevalent C calling conventions of > platform, but they are supported by all C compilers. The Windows API morphed into an API defined in C style, but it did not start that way. > But, more > importantly, basic assumptions of the API are very much C-ish. Like > passing parameters by value or through pointer, which is also sort of > "by value". Passing array as pointer. Extensive use of structures > that are defined and documented in terms of C language. Even strings > are mostly ASCIIZ, at least for non-Unicode variant of the API. > These are all very common characteristics of any API - you'd get the same thing for Pascal or a range of other languages. (Which is, of course, what you want for an OS API - functions that can be called easily by any language that can support the calling convention used.) > I'd say, among non-unices, Windows API is one of the most C-oriented. > Non counting, of course, various "executives" which or not quite > OSes. >
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2019-10-14 21:02 +0000 |
| Message-ID | <slrn3n7cqq9ojm.ba2.ike@sdf.lonestar.org> |
| In reply to | #146914 |
On 2019-10-13, David Brown <david.brown@hesbynett.no> wrote: > So you can write: > > typedef counter_t int; typedef int counter_t;
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-14 01:39 +0300 |
| Message-ID | <20191014013916.333bfd71e8363156058a1b2e@gmail.com> |
| In reply to | #146897 |
Bart: > Here is hoe a language can make it easier, with examples > from mine: > type T = ??? > * The equivalent of INT_MAX, you do 'T.maxvalue' > * To print X of type T, you do 'print X' I agree that no harm but good would come from implementing something like your .maxvalue feature C, e.g. as MAXVAL( int ), MINVAL( long int ). As to printf() in C, can't the compiler turn it into a call to some typed tprintf(), which would accept the original printf() arguments plus type indexes or pointers to functons that know how to print them, supplied at compile-time? Can C's va_arg facilily be extended with the ability to query the type of each argument rather than to require it? This would make it possible to implement a typed tprintf() without type specifiers: tprintf( "My name is %, and I am % years old.\n", "Bob", 8 ); -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-14 01:51 +0100 |
| Message-ID | <lEPoF.1077393$WI2.618453@fx34.am4> |
| In reply to | #146926 |
On 13/10/2019 23:39, Anton Shepelev wrote:
> Bart:
>
>> Here is hoe a language can make it easier, with examples
>> from mine:
>> type T = ???
>> * The equivalent of INT_MAX, you do 'T.maxvalue'
>> * To print X of type T, you do 'print X'
>
> I agree that no harm but good would come from implementing
> something like your .maxvalue feature C, e.g. as
> MAXVAL( int ), MINVAL( long int ).
>
> As to printf() in C, can't the compiler turn it into a call
> to some typed tprintf(), which would accept the original
> printf() arguments plus type indexes or pointers to functons
> that know how to print them, supplied at compile-time?
>
> Can C's va_arg facilily be extended with the ability to
> query the type of each argument rather than to require it?
> This would make it possible to implement a typed tprintf()
> without type specifiers:
>
> tprintf( "My name is %, and I am % years old.\n", "Bob", 8 );
If compilers can warn about incorrect formats, then why can't just
insert the correct ones?
I've just done a 30-minute experiment on my compiler to see how
practical it was, using a new "%?" format which adapts to the actual
type. With this program:
#include <stdio.h>
int a = 100;
double b = 92.54;
char *c = "hello";
int main(void) {
printf("A=%? B=%? C=%?", a, b, c);
}
The compiler changed the format string (it only works when constant) to:
"A=%d B=%f C=%s"
and the output was:
A=100 B=92.540000 C=hello
When I changed the declarations of a,b,c to:
long long int a = 6000000000;
unsigned int b = 4000000000;
int *c = (int*)&a;
Then, without touching the printf line at all, the new format string is:
"A=%lld B=%u C=%p"
and the output is now:
A=6000000000 B=4000000000 C=0000000000402000
Of course, this only sets the basic format type, and doesn't deal with
display options, such as width or hex, or showing an int as a character.
For that, that can added in to the %? format, or you just use the old
format code like %c.
This is just to see how it might work. For strings, it assumes a char*
type will be a string.
----------------------------------------------------------------------------------
These are the 40-odd lines of code hacked together to try out this idea
(not C code):
if d and eqstring(d.name, "printf") and q and q.tag = j_const and
q.slength < str.len/2 then
ss := q.svalue
tt := &.str
u := q.nextunit
while c := ss++^ do
if c = '%' and ss^ = '?' and u then
tt++^ := '%'
++ss
case ttbasetype[u.mode]
when tsint then
tt++^ := 'd'
when tsllong then
tt++^ := 'l'
tt++^ := 'l'
tt++^ := 'd'
when tuint then
tt++^ := 'u'
when tullong then
tt++^ := 'l'
tt++^ := 'l'
tt++^ := 'u'
when tfloat, tdouble, tldouble then
tt++^ := 'f'
when tref then
if tttarget[u.mode] = tschar then
tt++^ := 's'
else
tt++^ := 'p'
fi
else
tt++^ := '?'
esac
u := u.nextunit
else
tt++^ := c
fi
od
tt^ := 0
q.svalue := pcm_copyheapstring(&.str)
q.slength := strlen(&.str)
fi
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-14 12:16 +0300 |
| Message-ID | <20191014121620.df4393838259717b7dae25c6@g{oogle}mail.com> |
| In reply to | #146928 |
Bart:
>If compilers can warn about incorrect formats, then why
>can't just insert the correct ones?
Because that would be, as in your example, implementing a
funciton in the compiler rather than in the language being
compiled.
>I've just done a 30-minute experiment on my compiler to see
>how practical it was, using a new "%?" format which adapts
>to the actual type. With this program:
>
> #include <stdio.h>
>
> int a = 100;
> double b = 92.54;
> char *c = "hello";
>
> int main(void) {
> printf("A=%? B=%? C=%?", a, b, c);
> }
>The compiler changed the format string (it only works when
>constant) to:
>
> "A=%d B=%f C=%s"
>and the output was:
>
> A=100 B=92.540000 C=hello
Understood, but I was suggesting a small and backwards-
compatible modification to C that would allow one to
implement such a function in C. If I am not missing
anything, it only requires a faciltiy to query the argument
type via a new macro in stdarg.h. The type should be
encoded as an enumaration testable at run-time.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-14 10:45 +0100 |
| Message-ID | <4tXoF.777928$Xs5.98229@fx06.am4> |
| In reply to | #146929 |
On 14/10/2019 10:16, Anton Shepelev wrote:
> Bart:
>
>> If compilers can warn about incorrect formats, then why
>> can't just insert the correct ones?
>
> Because that would be, as in your example, implementing a
> funciton in the compiler rather than in the language being
> compiled.
>
>> I've just done a 30-minute experiment on my compiler to see
>> how practical it was, using a new "%?" format which adapts
>> to the actual type. With this program:
>>
>> #include <stdio.h>
>>
>> int a = 100;
>> double b = 92.54;
>> char *c = "hello";
>>
>> int main(void) {
>> printf("A=%? B=%? C=%?", a, b, c);
>> }
>> The compiler changed the format string (it only works when
>> constant) to:
>>
>> "A=%d B=%f C=%s"
>> and the output was:
>>
>> A=100 B=92.540000 C=hello
>
> Understood, but I was suggesting a small and backwards-
> compatible modification to C that would allow one to
> implement such a function in C. If I am not missing
> anything, it only requires a faciltiy to query the argument
> type via a new macro in stdarg.h. The type should be
> encoded as an enumaration testable at run-time.
Well, OK. Your suggestion can be simplified to the following challenge:
Write a function Showtype(dummy, ...) which takes the first variadic
argument, and prints out its type. Or at least one of int, double,
pointer or other.
The dummy parameter is because variadic functions require at least one
named parameter.
I don't understand exactly how variadic parameters work, but I thought
that you had to TELL the va- macros what type each argument is expected
to be.
And that information is derived from %-codes in the format string (the
dummy parameter here). So it's not something you can pick up from
variadic argument itself.
No doubt Tim Rentsch would be able to wangle some solution, but I think
it if was practical, everybody would be using your tprintf idea.
I suspect any answer would involve _Generic, and require each argument
to be wrapped in macro (to turn that into two arguments: a string giving
a type code - the information required - and the original argument). But
it would be a clunky solution.
Or maybe the entire tprintf() function will be a complex variadic macro.
Making a tweak such as mine to a compiler is far easier...
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-10-14 13:16 +0300 |
| Message-ID | <20191014131657.cfd17dc779b466c237aeef49@g{oogle}mail.com> |
| In reply to | #146930 |
Bart: >Well, OK. Your suggestion can be simplified to the >following challenge: > >Write a function Showtype(dummy, ...) which takes the first >variadic argument, and prints out its type. Or at least one >of int, double, pointer or other. > >The dummy parameter is because variadic functions require >at least one named parameter. > >I don't understand exactly how variadic parameters work, >but I thought that you had to TELL the va- macros what type >each argument is expected to be. Right. >And that information is derived from %-codes in the format >string (the dummy parameter here). So it's not something >you can pick up from variadic argument itself. Right. >No doubt Tim Rentsch would be able to wangle some solution, >but I think it if was practical, everybody would be using >your tprintf idea. I think it is impossible in C, wherefore my proposal of a new macro va_type macro expanding into the value of a enum identifying the type. >I suspect any answer would involve _Generic, and require >each argument to be wrapped in macro (to turn that into two >arguments: a string giving a type code -- the information >required -- and the original argument). But it would be a >clunky solution. I don't know the preprocessor language well enough to say whether it is possible. But if it, you write the clumsy solution once and reuse it instead of changing the language. >Or maybe the entire tprintf() function will be a complex >variadic macro. The same. Can you write a macro that would expand into something *plus* produce some side-effects necessary for a later modification of the format string? >Making a tweak such as mine to a compiler is far easier... True, but in my opinion the functions of a programming language are best implemented in this language. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-10-14 03:34 -0700 |
| Message-ID | <52d65268-b105-4920-be2d-52b8abb14c34@googlegroups.com> |
| In reply to | #146932 |
On Monday, 14 October 2019 11:17:05 UTC+1, Anton Shepelev wrote: > > True, but in my opinion the functions of a programming > language are best implemented in this language. > C decided that there would be no input output statements, only functions, which were implemented either in non-portable C or in assembly. However that was an unusual design decision at the time. The formatting of output isn't output itself, of course, but it is closely tied to it.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-10-14 03:54 -0700 |
| Subject | Lack of language I/O support (was Re: Sort char array, many posts ago) |
| Message-ID | <c85969fe-5079-4ac6-852b-e49db7e5ab0c@googlegroups.com> |
| In reply to | #146934 |
On Monday, 14 October 2019 11:34:58 UTC+1, Malcolm McLean wrote: > C decided that there would be no input output statements, only functions, > which were implemented either in non-portable C or in assembly. > However that was an unusual design decision at the time. I'm not convinced it was that unusual. I worked for Prime Computer in the early '80s and the operating system and utilties (dating back to the early '70s) were written in a mixture of Assembler, Fortran (yes, really) and 2 PL/1 derivatives (PL/P and SPL), and as far as I remember all I/O was done via function calls - certainly neither PL/1 variant had any language I/O support. I believe some later development on Primos was done in Modula-2. I don't know anything about I/O support in that case. C was implemented with difficulty on Prime, because the architecture - segmented memory, default 16-bit I/O and memory addressing, etc. - didn't fit well with C's assumptions.
[toc] | [prev] | [next] | [standalone]
Page 12 of 25 — ← Prev page 1 … 10 11 [12] 13 14 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web