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 19 of 25 — ← Prev page 1 … 17 18 [19] 20 21 … 25 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 22:16 +0200 |
| Message-ID | <qniqqe$ksv$1@dont-email.me> |
| In reply to | #146765 |
On 08/10/2019 19:09, Bart wrote:
> On 08/10/2019 17:39, Scott Lurndal wrote:
>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>>> Malcolm McLean to Bart:
>>>
>>>>> BTW it sounds like gcc compile times /are/ a problem, if
>>>>> approaches like precompiled headers, conditional make
>>>>> files and 'ccache' need to be employed.
>>>>
>>>> That is a very good point. If you are using stratagems to
>>>> reduce the amount of compilation you actually do, to mask
>>>> the fact that the compiler is slow, then that's one more
>>>> thing to go wrong. The cost is disguised because when the
>>>> build system is set up it will work. However eventually
>>>> something will often break, and then the costs are
>>>> incurred.
>>>
>>> `make' is supposed to optimise build by compiling only
>>> updated files, but that often fails to help.
>>
>> Especially for Bart, who believes that the entire source
>> must always be in a single file and is proud to have 35kloc
>> source files. *shudder*
>>
>
> Then you misunderstood.
>
> This is an intermediate representation, and is no more an issue being in
> one file than a binary executable.
>
> That particular project comprises 73 source, support and bundled C
> header files.
>
> The 35Kloc C rendering is one file for convenience.
And yet it seems to be inconveniencing you greatly.
>
> If you want to see those 73 files of the true sources, then one
> combination (here for Windows target) is here:
>
> https://github.com/sal55/qx/blob/master/cc.ma2
>
> Naturally, bundled into one file for convenience. If you wanted to
> compile these true sources, this is the file I'd send you. No zips or
> .gz2 or anything, nor make files; you can compile this actual file.
Oh, the horrors! Imagine being sent several files in a zip file!
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-08 23:58 +0300 |
| Message-ID | <20191008235835.7eb83598f5c62592ab152666@gmail.com> |
| In reply to | #146769 |
David Brown to Bart: > > Naturally, bundled into one file for convenience. If you > > wanted to compile these true sources, this is the file > > I'd send you. No zips or .gz2 or anything, nor make > > files; you can compile this actual file. > > Oh, the horrors! Imagine being sent several files in a > zip file! A zip file is not a problem. If fact, I should archive even a single combined file for storage and transfer. But the ability to store all the modules comprising a program as a nice and tidy self-contained and human-readable package that a simple tool can build without a make file is a blessing, especially for C, compilers for which are usually unable to figure out the intermodule dependencies and must be fed with a dependecy hierarchy. My proposal of C modules addresses this drawback. -- () 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-08 22:19 +0100 |
| Message-ID | <x37nF.748905$bS1.648858@fx13.am4> |
| In reply to | #146769 |
On 08/10/2019 21:16, David Brown wrote:
> On 08/10/2019 19:09, Bart wrote:
>> The 35Kloc C rendering is one file for convenience.
>
> And yet it seems to be inconveniencing you greatly.
No, it seems to be offending you lot, because I'm disregarding the rules
about function/object pointer conversion.
>> Naturally, bundled into one file for convenience. If you wanted to
>> compile these true sources, this is the file I'd send you. No zips or
>> .gz2 or anything, nor make files; you can compile this actual file.
>
> Oh, the horrors! Imagine being sent several files in a zip file!
Container files are very common (tar, cab etc). What problem do you
think those are trying to solve?
Packed/compressed distributions usually need unpacking (and if you
specify a destination, you often end up with an extra directory level).
The result is 100s or 1000s of files in some sprawling hierarchy, and
one makefile, or maybe a dozen related makefiles, linking some of them
together. In other words, the usual mess.
My scheme allows this:
mm cc.ma
It compiles the bundled source file, cc.ma, into cc.exe. You started
with one file, and now you have two.
Some one step away from a file binary executable, is a single C source
file (but ugly and unreadable and unmaintainable). This next step
present the original sources in a readable (and trivially unpackable)
format, but still has the advantages of one file.
Neat, yes?
I guess I'm not going to sell the idea here to people who've been using
sprawling source directories and cryptic makefiles for decades.
That single sqlite3.c file was created for the convenience of people who
just wanted to use the library and not contend with 100 source files
they are not interested in managing.
Single file solutions are useful for people who appreciate the
advantages. Obviously, not you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 17:39 +0200 |
| Message-ID | <qniais$8ko$1@dont-email.me> |
| In reply to | #146750 |
On 08/10/2019 16:55, Malcolm McLean wrote: > On Tuesday, 8 October 2019 15:06:45 UTC+1, Bart wrote: >> >> BTW it sounds like gcc compile times /are/ a problem, if approaches like >> precompiled headers, conditional make files and 'ccache' need to be >> employed. >> > That is a very good point. If you are using stratagems to reduce the > amount of compilation you actually do, to mask the fact that the compiler > is slow, then that's one more thing to go wrong. The cost is disguised > because when the build system is set up it will work. However eventually > something will often break, and then the costs are incurred. > Someone incapable of using basic build tools like "make", or the project manager of their favourite IDE, should question their career choice as a programmer. I don't mean you have to write fancy automatic makefiles such as discussed on another thread. You use the tools that are convenient - and you use them appropriately, when they are useful. You might have the world's best electric drill, but only a moron would re-do all the holes currently in a piece of wood before drilling the next hole.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-09 00:12 +0300 |
| Message-ID | <20191009001207.b2bab8f5a72bc2252722b219@gmail.com> |
| In reply to | #146756 |
David Brown: > Someone incapable of using basic build tools like "make", > or the project manager of their favourite IDE, should > question their career choice as a programmer. Of course, it is an important skill, and I am gointgto learn `make' in order to replace the simple program I have written and use for formatting e-mails with GNU Troff and other simple tasks. But if you substitute "loth" for "incapable" the statement is no longer correct. The need to write a makefile or to use a full-fledged IDE in order to enable the compiler to build any program consisting of more than a single file is unjustified. Consider languages with proper modules: Borand Pascal, FreePascal, Modula. Thanks to the clear specification of module dependencies, their compilers can build multi-file programs when involed for the root module only. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-10-09 09:48 -0700 |
| Message-ID | <ac9b76dd-5bbf-45a5-a5d6-51cf8c8f2676@googlegroups.com> |
| In reply to | #146756 |
On Tuesday, October 8, 2019 at 6:39:19 PM UTC+3, David Brown wrote: > On 08/10/2019 16:55, Malcolm McLean wrote: > > On Tuesday, 8 October 2019 15:06:45 UTC+1, Bart wrote: > >> > >> BTW it sounds like gcc compile times /are/ a problem, if approaches like > >> precompiled headers, conditional make files and 'ccache' need to be > >> employed. > >> > > That is a very good point. If you are using stratagems to reduce the > > amount of compilation you actually do, to mask the fact that the compiler > > is slow, then that's one more thing to go wrong. The cost is disguised > > because when the build system is set up it will work. However eventually > > something will often break, and then the costs are incurred. > > > > Someone incapable of using basic build tools like "make", Basic build tools like "make" does not handle include file dependencies automatically. You have to either go beyond basics, which would depend on (non-standardized) ability of your compiler to output dependency reports or do it manually. The later could lead to errors or to become maintenance nightmare. For few source files (or dozen, or three dozens if tcc is really as fast as Bart say) fast compiler with all sources supplied on the command line is so much easier and more robust. > or the project > manager of their favourite IDE, should question their career choice as a > programmer. I don't mean you have to write fancy automatic makefiles > such as discussed on another thread. > > You use the tools that are convenient - and you use them appropriately, > when they are useful. > > You might have the world's best electric drill, but only a moron would > re-do all the holes currently in a piece of wood before drilling the > next hole.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 19:49 +0100 |
| Message-ID | <6ZpnF.796631$R83.332161@fx23.am4> |
| In reply to | #146810 |
On 09/10/2019 17:48, already5chosen@yahoo.com wrote:
> On Tuesday, October 8, 2019 at 6:39:19 PM UTC+3, David Brown wrote:
>> Someone incapable of using basic build tools like "make",
>
> Basic build tools like "make" does not handle include file dependencies automatically.
> You have to either go beyond basics, which would depend on (non-standardized) ability of your compiler to output dependency reports or do it manually. The later could lead to errors or to become maintenance nightmare.
>
> For few source files (or dozen, or three dozens if tcc is really as fast as Bart say) fast compiler with all sources supplied on the command line is so much easier and more robust.
Judge for yourself:
C:\lua\src>timeit "gcc -O3 @lua -olua.exe"
gcc -O3 @lua -olua.exe 15.08
C:\lua\src>timeit "gcc -O2 @lua -olua.exe"
gcc -O2 @lua -olua.exe 12.84
C:\lua\src>timeit "gcc -O1 @lua -olua.exe"
gcc -O1 @lua -olua.exe 9.69
C:\lua\src>timeit "gcc -O0 @lua -olua.exe"
gcc -O0 @lua -olua.exe 7.00
C:\lua\src>timeit "tcc @lua -olua.exe"
tcc @lua -olua.exe 0.32
tcc is 20 to 45 times faster to build with than gcc. To get the benefit
of gcc's faster code, you need to use -O1 or above.
Here, 'lua' is the following simple list of modules:
lstate.c
ldo.c
llex.c
lcode.c
lobject.c
lapi.c
lua.c
ltable.c
lgc.c
lauxlib.c
lbaselib.c
lbitlib.c
lcorolib.c
lctype.c
ldblib.c
ldebug.c
ldump.c
lfunc.c
linit.c
liolib.c
lmathlib.c
lmem.c
loadlib.c
lopcodes.c
loslib.c
lparser.c
lstring.c
lstrlib.c
ltablib.c
ltm.c
lundump.c
lutf8lib.c
lvm.c
lzio.c
This can also contain the -olua.exe needed to do the full job of
building. A makefile is not needed.
If I run my own C compiler (which still has an expensive asm source stage):
C:\lua\src>timeit "bcc @lua -out:lua.exe"
Compiling lstate.c to lstate.asm
...
Compiling lzio.c to lzio.asm
Assembling to lua.exe
bcc @lua -out:lua.exe 0.36
As for the generated code, these are the run-times for recursive
Fibonacci in Lua, for fib(34), as compiled as follows:
gcc O3 1.5 seconds
gcc -O2 1.5
gcc -O1 1.6
gcc -O0 3.7
tcc 4.3
bcc 3.5
With an application like a compiler, the difference between being
compiled with tcc and gcc-O3 might be 40%:
bcc compiled with gcc -O3: 0.36 seconds to build Lua (same as above)
bcc compiled with tcc 0.50 seconds to build Lua
bcc compiled with bcc 0.48 seconds to build Lua
bcc compiled with mm 0.43 seconds to build Lua (native)
(mm is the native compiler for bcc, not via C code.)
BTW bcc can be compiled, via C, like this:
mc cc -gcc -opt # 16 seconds
mc cc -gcc # 3 seconds
mc cc -tcc # 0.23 seconds
mc cc -bcc # 0.26 seconds
No make files used anywhere.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 17:29 +0200 |
| Message-ID | <qni9vv$4kf$1@dont-email.me> |
| In reply to | #146747 |
On 08/10/2019 16:06, Bart wrote: > On 08/10/2019 13:05, David Brown wrote: >> On 08/10/2019 12:39, Bart wrote: > >> The primary uses of RPi's is for fun and learning. In both cases, you >> put up with slower or more limited systems, and you are also working >> with much smaller programs. The typical program developed using a Pi is >> a few hundred lines of Python or Lua - not many thousands of lines of C. > > I don't know what people do with them. But that they come with 1-4GB RAM > suggests they might be using or developing some programs that need 1-4GB > RAM. Those are not necessarily small. > > Since they are full Linux systems, they will want to install/build > anything that comes with a regular Linux system. I do know that many > like to push their systems, languages and compilers to the limits. > > >> Are you suggesting that non-professionals /like/ bugs to surface at >> customer (or user) sites? > > Non-professionals won't have paying customers. > > Are you suggesting that amateurs or hobby >> users would prefer to find their bugs later, while running their >> programs, rather than earlier on? > > There are many other ways of finding/avoiding bugs. One way is not to > use C at all as it has too many opportunity for errors. Can your C > compiler detect these three errors: > > for (i=0; i<=N ; ++j) > f(i); > g(i); > Yes, at least the two that I can see. You can write risky C, or you can have good C habits that minimise the risk of errors. Just because you prefer to write weak, poorly structured and fallible C does not mean other people do. Keeping your variable scopes small makes it unlikely that the code will pass without complaint. Loop variables like "i" and "j" should be declared in the "for" statement - then if you attempt to use the variable outside their scope (like "g(i)" here), you'll get an error. And gcc will warn about misleading indentation. (No compiler will warn about every error, of course.) I'm guessing that you meant the "<= N" to be an error, but it is pretty much impossible for a tool, or another programmer, to know that when you wrote one perfectly reasonable thing you actually meant a different perfectly reasonable thing. > In my syntax it would be (using 1-based indexing): > > for i to N do > f(i) > od > g(i) > > so either you can't make the same errors, or it would be more obvious > (eg. writing N+1). Hey, I guessed right! Can your tools spot the two deliberate mistakes in this? setBackgroundColor(green) ? > >> But as usual you are /wildly/ exaggerating the question of compiler >> speed. I have never heard anyone - except you - view the speed of gcc >> as a hinder to using it for C. > > So why did anyone even bother creating something like Tiny C? (I used to > think it was a toy compiler, until I tried it.) > >>> How do you know that? The amalgamated sqlite3.c is 220,000 lines. People >>> running languages with a C back-end might also generate such files. > >> Just for fun, I tried it - yes, it is quite time-consuming. "gcc -O3" >> on sqlite3.c took 21 seconds on my system for its first compile, while >> tcc took 0.1 seconds. > > Your machine is about 3 times the speed of mine then. (That would make > the compiler for my main language, when I've finished removing that > time-consuming intermediate ASM stage, run at over 1 million lines per > second on your computer.) My machine is over five years old, and was not particularly expensive at the time. It is only a little faster than my ten year old system (for a single compile). If you are doing professional work and your development machine is so slow that you are feeling limited, get a new machine. If you can't do that, get a new boss. > > If I had a project using sqlite, and was not >> using the library versions (highly unlikely), and was not using a build >> system like make that avoids unnecessary re-compiles (even less likely), >> then that is slow enough to be annoying. So - since I know about build >> tools - I'd use ccache. Compilation is now 25 milliseconds - about four >> times as fast as tcc. > > Four times as fast as tcc at, what - compiling this source file or not > compiling it? Because my car is always going to be faster than yours on > any round trip - if I can find a way of not doing the journey! > Compiling it exactly as much as needed. > But it does sound like you've found the perfect solution for RPi1 > systems - just use ccache, and it will be 4 times as fast as tcc. > > Or is it not that simple ... > > BTW it sounds like gcc compile times /are/ a problem, if approaches like > precompiled headers, conditional make files and 'ccache' need to be > employed. > When you are doing full compilation of large projects, then compile time becomes an issue. Ways of avoiding needless compilation is therefore useful - and it is precisely because developers (sensible ones, anyway) don't pointlessly re-compile everything that compile times are rarely a problem. And times change. It used to be that compiling the Linux kernel would take an hour or two on a normal system. Now, it takes a few minutes - with serious development machines handling it in less than 20 seconds. (And that is for a full compile, without ccache.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-08 17:56 +0100 |
| Message-ID | <Zc3nF.688743$665.326237@fx28.am4> |
| In reply to | #146752 |
On 08/10/2019 16:29, David Brown wrote:
> On 08/10/2019 16:06, Bart wrote:
>> for (i=0; i<=N ; ++j)
>> f(i);
>> g(i);
>>
>
> Yes, at least the two that I can see.
>
> You can write risky C, or you can have good C habits that minimise the
> risk of errors. Just because you prefer to write weak, poorly
> structured and fallible C does not mean other people do.
>
> Keeping your variable scopes small makes it unlikely that the code will
> pass without complaint. Loop variables like "i" and "j" should be
> declared in the "for" statement - then if you attempt to use the
> variable outside their scope (like "g(i)" here), you'll get an error.
Not if there is also an outer 'i' in scope. But the 'i' in g(i) is a red
herring; I should have written just g().
> And gcc will warn about misleading indentation.
> Hey, I guessed right!
>
> Can your tools spot the two deliberate mistakes in this?
>
> setBackgroundColor(green)
My example highlighted things where it is harder to express your intent
in C, because the language offers extra possibilities ('flexibility'
some people like to call it).
So writing "<" or "<=", ++i or ++j, or the mixup over whether f(i) and
g(i) are in the same block, because C allows you to use {} around a
for-block or not.
The tool needs to infer what it is you are trying to do.
Here, assuming this is C, you might be:
(1) Calling a function 'setBackgroundColor' with argument 'green'
(2) Invoking a macro 'setBackgroundColor' with argument 'green'
(3) Declaring a variable 'green' of type 'setBackgroundColor'
But assuming you mean (1) or(2), I can't see anything wrong other than
the spelling of 'Colour', given suitable visible definitions or
declarations of the two identifiers.
> My machine is over five years old, and was not particularly expensive at
> the time. It is only a little faster than my ten year old system (for a
> single compile). If you are doing professional work and your
> development machine is so slow that you are feeling limited, get a new
> machine. If you can't do that, get a new boss.
There's nothing wrong with my machine; it's the software that is slow.
You can get around such problems by throwing extra money, hardware,
cores and programs at it, and try to mitigate them by avoiding actually
running the compiler as much as possible, but it will still be a slow
compiler.
>> Four times as fast as tcc at, what - compiling this source file or not
>> compiling it? Because my car is always going to be faster than yours on
>> any round trip - if I can find a way of not doing the journey!
>>
>
> Compiling it exactly as much as needed.
So it's not compiling it in 0.25 seconds.
> When you are doing full compilation of large projects, then compile time
> becomes an issue. Ways of avoiding needless compilation is therefore
> useful - and it is precisely because developers (sensible ones, anyway)
> don't pointlessly re-compile everything that compile times are rarely a
> problem.
And it is precisely because people like me are looking at fast
whole-project compilers that interesting new approaches become possible.
For example, the granularity of the units that need to be recompiled can
be whole executables (exe and dll files on Windows) rather than modules.
Where there is an optimiser, it can now trivially be applied to the
whole program (all modules forming the executable) without LTO
complications.
With the right language, you can also forget makefiles, and conditional
compilation.
> And times change. It used to be that compiling the Linux kernel would
> take an hour or two on a normal system. Now, it takes a few minutes -
> with serious development machines handling it in less than 20 seconds.
> (And that is for a full compile, without ccache.)
Building gcc on RPi4 reportedly takes around 3 hours (presumably built
with gcc)
My C compiler (on Linux it would be a cross-compiler for Windows) takes
0.2 seconds built with tcc, 50,000 times faster.
(I don't know how long tcc would take to build gcc; I wouldn't have a
clue how to do it. My own programs, as always, are as hard to build as
hello.c.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-08 22:25 +0200 |
| Message-ID | <qnirc6$o3a$1@dont-email.me> |
| In reply to | #146763 |
On 08/10/2019 18:56, Bart wrote:
> On 08/10/2019 16:29, David Brown wrote:
>> On 08/10/2019 16:06, Bart wrote:
>
>>> for (i=0; i<=N ; ++j)
>>> f(i);
>>> g(i);
>>>
>>
>> Yes, at least the two that I can see.
>>
>> You can write risky C, or you can have good C habits that minimise the
>> risk of errors. Just because you prefer to write weak, poorly
>> structured and fallible C does not mean other people do.
>>
>> Keeping your variable scopes small makes it unlikely that the code will
>> pass without complaint. Loop variables like "i" and "j" should be
>> declared in the "for" statement - then if you attempt to use the
>> variable outside their scope (like "g(i)" here), you'll get an error.
>
> Not if there is also an outer 'i' in scope.
Why would there be an "i" in the outer scope? "i" is a name you give to
a loop variable, and you define it there in the "for" loop. (And if you
have too many nested loops to keep track, you should have split the
function up long ago.)
> But the 'i' in g(i) is a red
> herring; I should have written just g().
>
>> And gcc will warn about misleading indentation.
And it will do so whether it is "g(i)" or "g()".
>
>
>> Hey, I guessed right!
>>
>> Can your tools spot the two deliberate mistakes in this?
>>
>> setBackgroundColor(green)
>
> My example highlighted things where it is harder to express your intent
> in C, because the language offers extra possibilities ('flexibility'
> some people like to call it).
People who program in C don't find this hard. People who dedicate much
of their lives to hating see might construe it as hard.
>
> So writing "<" or "<=", ++i or ++j, or the mixup over whether f(i) and
> g(i) are in the same block, because C allows you to use {} around a
> for-block or not.
>
> The tool needs to infer what it is you are trying to do.
>
> Here, assuming this is C, you might be:
>
> (1) Calling a function 'setBackgroundColor' with argument 'green'
>
> (2) Invoking a macro 'setBackgroundColor' with argument 'green'
>
> (3) Declaring a variable 'green' of type 'setBackgroundColor'
>
> But assuming you mean (1) or(2), I can't see anything wrong other than
> the spelling of 'Colour', given suitable visible definitions or
> declarations of the two identifiers.
The mistakes were the misspelling of setBackgroundColour, and the choice
of a green background instead of a red one.
The point is, no language can spot all your mistakes. It is
particularly difficult to spot things that are perfectly good code in
the language and perfectly reasonable things to write.
C - assuming you know how to use common free tools - is no more prone to
typos or silly mistakes than other languages. For some tasks,
especially memory management, it's easy to get things wrong - if your
code has a lot of "higher level" features then it would make more sense
to use a higher level language to automate these things (C++, Python,
whatever).
>
>> My machine is over five years old, and was not particularly expensive at
>> the time. It is only a little faster than my ten year old system (for a
>> single compile). If you are doing professional work and your
>> development machine is so slow that you are feeling limited, get a new
>> machine. If you can't do that, get a new boss.
>
> There's nothing wrong with my machine; it's the software that is slow.
>
> You can get around such problems by throwing extra money, hardware,
> cores and programs at it, and try to mitigate them by avoiding actually
> running the compiler as much as possible, but it will still be a slow
> compiler.
It sounds like you simply don't have an appropriate computer for the
task of C development in a sensible manner. Maybe that's why you rail
on C and compilers all the time - it is envy of people with the right
tools for the job.
>
>>> Four times as fast as tcc at, what - compiling this source file or not
>>> compiling it? Because my car is always going to be faster than yours on
>>> any round trip - if I can find a way of not doing the journey!
>>>
>>
>> Compiling it exactly as much as needed.
>
> So it's not compiling it in 0.25 seconds.
>
What is the point of re-compiling the same thing in the same way? If I
want to waste a few seconds, I can do so more productively by picking my
nose.
<snip more pointless repetition>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 00:02 +0100 |
| Message-ID | <_z8nF.996242$aI7.450533@fx22.am4> |
| In reply to | #146770 |
On 08/10/2019 21:25, David Brown wrote:
> On 08/10/2019 18:56, Bart wrote:
> The mistakes were the misspelling of setBackgroundColour, and the choice
> of a green background instead of a red one.
>
> The point is, no language can spot all your mistakes. It is
> particularly difficult to spot things that are perfectly good code in
> the language and perfectly reasonable things to write.
That is a very poor example.
/My/ point was, C's design makes commonplace things error prone.
Examples:
(1) Use of = for == inside expressions
(2) Not requiring {} around statement sequences (so you leave out {}
because it's one statement, but later insert an extra statement without
noticing you now need {}, but it is still valid code)
(3) Using the same } terminator for all block types, which combined with
an optional, extra or missing { elsewhere, means block structure can be
screwed up, but its still legal
(4) Not having separators in numeric constants (so writing 100000 for 1
million instead of 1000000, but as 1_000_000 it is easy to check)
(5) Declaring a pointer to one object, but indexing it like an array
(6) Embedding print formats for the arguments to printf, but there is no
guaranteed that they match the actual arguments. And they are not
updated when the argument types change
(7) Declare int abc in one module, and char* abc in another. Now the
same global is accessed as two different types
(8) Create a comment like /* ...*/ XYZ /* ... */, but miss out the first
*/, and the block of code XYZ is silently ignored.
(9) Type 'defualt:' instead of 'default:', but it's still valid, and now
the behaviour changes
(10) Accidentally leave out 'break' after a case block, and the
behaviour silently changes
(11) Type a<<b + c, but this doesn't do what you think
(12) Mix ints of different types (8/16/32/64 and signed/unsigned) and
you have to consult a table to figure whether a binary op will work as
signed or unsigned. Which you won't so can get it wrong
(13) Declare int* p,q,r, and it's not what it looks like.
Etc etc (I can write dozens). It's a car crash. And this is ignoring
what is possible with macros.
Yes it is commendable that various tools have been developed to keep on
top of some of the these, smart editors etc, but not everyone uses them;
it apparently makes compilation slower; and it still means the base
language it what it is. Fixing /that/ would have been a better idea!
FWIW, in my language, either none of these errors are possible, or there
are easy means to avoid them (eg. using numeric separators).
The upshot is that you don't need as complicated a compiler with some
thought applied to the design of a language. (And you don't need to
cripple it either, so that you can hardly do anything without the
compiler squawking -- see Rust, which also seems in the running for the
slowest compiler.)
> C - assuming you know how to use common free tools - is no more prone to
> typos or silly mistakes than other languages.
Yes it is: see above.
> It sounds like you simply don't have an appropriate computer for the
> task of C development in a sensible manner. Maybe that's why you rail
> on C and compilers all the time - it is envy of people with the right
> tools for the job.
What absolute nonsense. Any PC now, even mine, is probably 1000 times as
powerful as anything from the 70s. How did they ever manage to get
anything done?
You are so dependent on your resource-hungry tools that you /need/ your
powerful computers!
> What is the point of re-compiling the same thing in the same way?
You really think I would compile the same program for no reason?
If I
> want to waste a few seconds, I can do so more productively by picking my
> nose.
So, in summary, you have a car with a maximum speed of 10mph, and has
the size and handling of a 40-ton truck (the figures are nearer 1mph and
400 tons), but it doesn't matter because you've worked out how best to
avoid using it so that you're not stuck in in all day!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 13:41 +0200 |
| Message-ID | <qnkh0f$8e3$1@dont-email.me> |
| In reply to | #146782 |
On 09/10/2019 01:02, Bart wrote:
> On 08/10/2019 21:25, David Brown wrote:
>> On 08/10/2019 18:56, Bart wrote:
>
>> The mistakes were the misspelling of setBackgroundColour, and the
>> choice of a green background instead of a red one.
>>
>> The point is, no language can spot all your mistakes. It is
>> particularly difficult to spot things that are perfectly good code in
>> the language and perfectly reasonable things to write.
>
> That is a very poor example.
>
> /My/ point was, C's design makes commonplace things error prone.
>
Let me first point out that I agree that some of C's design decisions
are not good - or at least, not how I would have wanted them. In some
cases, the decisions are for historical reasons and compatibility with
existing programs - I might not like the decisions, but I can understand
them. In some cases, I can understand them as being appropriate for the
time - C is old, and things that are simple or obvious now were not
always so simple back then. In other cases, I think they just made bad
choices.
I know of no one, except in your imagination, who thinks C is a
"perfect" language or agrees with all the design decisions.
But I also know of no one that complains about them as much as you do,
or so actively refuses to deal with them.
And of course the same applies to almost any programmer with almost any
language. The only exceptions are when /one/ person has made their own
personal language - presumably they then design it to suit their own
ideals. Thus you will think your own language is perfect, while
everyone else can easily find flaws in it. (And you will, without
doubt, mistake your subjective opinions as objective facts.)
Most of the points below are, IMHO, quite valid complaints about C's
design. Most of them, however, are easily solved by using appropriate
tools and appropriate coding practices. So they are only a problem if
you choose to let them be a problem. (I'm only noting what gcc handles
below - other good quality compilers will often have similar features.)
> Examples:
>
> (1) Use of = for == inside expressions
>
Solved by gcc warnings (and other compilers, IDEs, linters, etc.).
> (2) Not requiring {} around statement sequences (so you leave out {}
> because it's one statement, but later insert an extra statement without
> noticing you now need {}, but it is still valid code)
Solved by gcc warnings, and by good coding practices.
>
> (3) Using the same } terminator for all block types, which combined with
> an optional, extra or missing { elsewhere, means block structure can be
> screwed up, but its still legal
Solved by gcc warnings, and by good coding practices.
>
> (4) Not having separators in numeric constants (so writing 100000 for 1
> million instead of 1000000, but as 1_000_000 it is easy to check)
>
That would be nice - I will give you this one. (C++ has digit
separators, but C does not.)
> (5) Declaring a pointer to one object, but indexing it like an array
That is part of a feature, not a flaw. It is a powerful but dangerous
feature. C is a language that requires a responsible programmer - and
good coding practices.
>
> (6) Embedding print formats for the arguments to printf, but there is no
> guaranteed that they match the actual arguments. And they are not
> updated when the argument types change
Solved by gcc warnings.
>
> (7) Declare int abc in one module, and char* abc in another. Now the
> same global is accessed as two different types
Solved by appropriate compiler flags and sensible coding practices.
>
> (8) Create a comment like /* ...*/ XYZ /* ... */, but miss out the first
> */, and the block of code XYZ is silently ignored.
>
Solved by gcc warnings.
> (9) Type 'defualt:' instead of 'default:', but it's still valid, and now
> the behaviour changes
Solved by gcc warnings, as well as syntax highlighting editors.
>
> (10) Accidentally leave out 'break' after a case block, and the
> behaviour silently changes
Solved by gcc warnings.
>
> (11) Type a<<b + c, but this doesn't do what you think
Solved by gcc warnings, as well as by good coding practices.
>
> (12) Mix ints of different types (8/16/32/64 and signed/unsigned) and
> you have to consult a table to figure whether a binary op will work as
> signed or unsigned. Which you won't so can get it wrong
Solved by learning a little bit about the language you are using.
>
> (13) Declare int* p,q,r, and it's not what it looks like.
Solved by good programming practices. (Though I would have much
preferred if this were not legal in the code.)
>
> Etc etc (I can write dozens). It's a car crash. And this is ignoring
> what is possible with macros.
I believe I can honestly say that the risk of me getting any of these
wrong, is very close to zero. I might have mixed "=" and "=="
occasionally in my early days, with more limited tools. And while I
might make some of them now by typos, they will immediately be spotted
by my tools - either while editing, or after compiling.
There are many other things that can go wrong in C programming, but that
applies to all programming. I have to find and squash bugs in my code
like everyone else - regardless of the language. But the things you get
hung up about, the things that you feel your language has "fixed",
simply are not a problem if you have good development practices and use
appropriate tools.
>
> Yes it is commendable that various tools have been developed to keep on
> top of some of the these, smart editors etc, but not everyone uses them;
> it apparently makes compilation slower; and it still means the base
> language it what it is. Fixing /that/ would have been a better idea!
>
> FWIW, in my language, either none of these errors are possible, or there
> are easy means to avoid them (eg. using numeric separators).
>
> The upshot is that you don't need as complicated a compiler with some
> thought applied to the design of a language. (And you don't need to
> cripple it either, so that you can hardly do anything without the
> compiler squawking -- see Rust, which also seems in the running for the
> slowest compiler.)
So rather than using freely available, powerful tools (which are
complicated - no doubts there) to avoid these mistakes, you think it
makes more sense to design your own language, write your own tools, and
live in your own private world walled off from every other programmer?
Thanks, but no thanks. If using a better tool avoids problems, I'll
just use the better tools.
>
>> C - assuming you know how to use common free tools - is no more prone
>> to typos or silly mistakes than other languages.
>
> Yes it is: see above.
>
>> It sounds like you simply don't have an appropriate computer for the
>> task of C development in a sensible manner. Maybe that's why you rail
>> on C and compilers all the time - it is envy of people with the right
>> tools for the job.
>
> What absolute nonsense. Any PC now, even mine, is probably 1000 times as
> powerful as anything from the 70s. How did they ever manage to get
> anything done?
>
> You are so dependent on your resource-hungry tools that you /need/ your
> powerful computers!
I write bigger programs than I used to, with programs that do more, and
I do so more efficiently and with a lower defect rate (whether measured
per program, per day, per dollar). The world moves on, if you let it.
>
>> What is the point of re-compiling the same thing in the same way?
>
> You really think I would compile the same program for no reason?
>
Certainly for no /good/ reason, yes.
> If I
>> want to waste a few seconds, I can do so more productively by picking
>> my nose.
>
> So, in summary, you have a car with a maximum speed of 10mph, and has
> the size and handling of a 40-ton truck (the figures are nearer 1mph and
> 400 tons), but it doesn't matter because you've worked out how best to
> avoid using it so that you're not stuck in in all day!
>
No, I have a car that has all the speed I need, plenty of power and
flexibility, and is safe to use. I'll pick that every time over a
little go-kart that can go ridiculously fast down a speed hill but is
otherwise useless.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 14:03 +0100 |
| Message-ID | <rUknF.1213888$HWr.519068@fx36.am4> |
| In reply to | #146796 |
On 09/10/2019 12:41, David Brown wrote:
> On 09/10/2019 01:02, Bart wrote:
> Solved by gcc warnings (and other compilers, IDEs, linters, etc.).
> Solved by gcc warnings, and by good coding practices.
> Solved by gcc warnings, and by good coding practices.
> Solved by gcc warnings.
> Solved by appropriate compiler flags and sensible coding practices.
> Solved by gcc warnings.
> Solved by gcc warnings, as well as syntax highlighting editors.
>
So the onus is all on the compiler, and people wonder why gcc is so
slow? Someone writing a lightweight compiler has to do duplicate all
that analysis.
And the sensible coding practices still need to be enforced.
>> (10) Accidentally leave out 'break' after a case block, and the
>> behaviour silently changes
>
> Solved by gcc warnings.
(Really, you will get a warning each time you actually do want a
fall-through?)
>> (11) Type a<<b + c, but this doesn't do what you think
>
> Solved by gcc warnings, as well as by good coding practices.
(And again, suppose you know and want this to be a<<(b+c), gcc will give
a warning about code that has nothing wrong with it?)
>
>>
>> (12) Mix ints of different types (8/16/32/64 and signed/unsigned) and
>> you have to consult a table to figure whether a binary op will work as
>> signed or unsigned. Which you won't so can get it wrong
>
> Solved by learning a little bit about the language you are using.
A little? Here's a 10x10 table for my language showing whether a mixed
binary op is done as signed (S) or unsigned (U):
i8 i16 i32 i64 i128 u8 u16 u32 u64 u128
i8 S S S S S S S S S S
i16 S S S S S S S S S S
i32 S S S S S S S S S S
i64 S S S S S S S S S S
i128 S S S S S S S S S S
u8 S S S S S U U U U U
u16 S S S S S U U U U U
u32 S S S S S U U U U U
u64 S S S S S U U U U U
u128 S S S S S U U U U U
So basically, it's unsigned if both operands are unsigned. A very simple
rule.
What would the equivalent chart for C look like? You can use an 8x8
chart to over 8 to 64 bits. I can tell you it will be rather different
from the above.
> I believe I can honestly say that the risk of me getting any of these
> wrong, is very close to zero.
But compilers and tools still have to deal with the possibility. People
other than you also write C code.
I might have mixed "=" and "=="
> occasionally in my early days, with more limited tools. And while I
> might make some of them now by typos, they will immediately be spotted
> by my tools - either while editing, or after compiling.
>
> There are many other things that can go wrong in C programming, but that
> applies to all programming. I have to find and squash bugs in my code
> like everyone else - regardless of the language.
No: a lot of this is specific to C, because it's such a old language and
because of many poor design choices.
But the things you get
> hung up about, the things that you feel your language has "fixed",
> simply are not a problem if you have good development practices and use
> appropriate tools.
And what if you want to use other tools, like for example tcc?
Below is a C program (2 modules) demonstrating some of the problems I
listed. gcc with no options, tcc, bcc, lcc, and msvc (latter using
default rextester options) said nothing.
gcc with some options gave quite a few warnings, but missed some things.
clang (with rextester default options) gave fewer. All, when I managed
to create an executable, gave a program that crashed (except bcc that
would not link as given, because it saw two 'abc's).
When I commented out the lines that caused a crash, it gave the wrong
results from what was intended.
A program trying to duplicate the behaviour (ie. the intended behaviour,
plus the coding errors that make it crash and those that affect the
logic) was too difficult to emulate in my language.
(For example, it is impossible to have more than one global 'abc' in a
program in the manner given here. If both c and d export 'abc' then each
will have its own namespace.)
So a simple compiler cannot detect the issues with the C code, but an
equally simple compiler for my language /could/ detect them, or the ones
that language doesn't stop you writing in the first place.
-----------------------------------------
c.c
-----------------------------------------
#include <stdio.h>
int abc;
extern void fn(void);
static int a=1,b=2,c=3,d=4;
static int* p=&a;
static char* fmt="<%s>";
int main(void) {
abc=12345;
fn();
if (a=4)
puts("a is 4");
puts("I repeat, a is 4");
if (b==2) {
puts("b is 2");
if (c==3)
puts("And c is 3");
else
puts("b is not 2");
}
printf("1 million = %d\n",100000);
printf("p[100]= %d\n",p[100]);
printf(fmt, d);
puts("one"); /* comment 1
puts("two"); /* comment 2 */
puts("three");
switch (c) {
case 3:
puts("Sw: c is 3");
case 4:
puts("Sw: c is 4");
defualt:
puts("Sw: c is not 3 nor 4");
}
}
-----------------------------------------------------
d.c
-----------------------------------------------------
#include <stdio.h>
char *abc="hello world";
void fn(void) {
printf("abc=%s\n",abc);
}
-----------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-09 15:53 +0200 |
| Message-ID | <qnkopc$o3v$1@dont-email.me> |
| In reply to | #146797 |
On 09/10/2019 15:03, Bart wrote: > On 09/10/2019 12:41, David Brown wrote: >> On 09/10/2019 01:02, Bart wrote: > >> Solved by gcc warnings (and other compilers, IDEs, linters, etc.). > >> Solved by gcc warnings, and by good coding practices. > >> Solved by gcc warnings, and by good coding practices. > >> Solved by gcc warnings. > >> Solved by appropriate compiler flags and sensible coding practices. > >> Solved by gcc warnings. > >> Solved by gcc warnings, as well as syntax highlighting editors. >> > > So the onus is all on the compiler, and people wonder why gcc is so > slow? Someone writing a lightweight compiler has to do duplicate all > that analysis. No one wonders why gcc is so slow. And no one complains about it being slow (except you, of course). > > And the sensible coding practices still need to be enforced. > If you are not using sensible coding practices, what are you doing as a programmer? > >>> (10) Accidentally leave out 'break' after a case block, and the >>> behaviour silently changes >> >> Solved by gcc warnings. > > (Really, you will get a warning each time you actually do want a > fall-through?) If you want real fall-through - a rare event, but plausible - you add a comment such as "// fall-through". (C++ standardises this with an attribute.) The common situation of multiple cases does not need a comment. > > >>> (11) Type a<<b + c, but this doesn't do what you think >> >> Solved by gcc warnings, as well as by good coding practices. > > (And again, suppose you know and want this to be a<<(b+c), gcc will give > a warning about code that has nothing wrong with it?) There /is/ something wrong with it - it is unclear. So you should write it in a clearer manner - such as with brackets. > >> >>> >>> (12) Mix ints of different types (8/16/32/64 and signed/unsigned) and >>> you have to consult a table to figure whether a binary op will work as >>> signed or unsigned. Which you won't so can get it wrong >> >> Solved by learning a little bit about the language you are using. > > A little? Here's a 10x10 table for my language showing whether a mixed > binary op is done as signed (S) or unsigned (U): Learn the rules of C if you want to program in C. If there is something you find extraordinarily difficult, don't use it. > > >> I believe I can honestly say that the risk of me getting any of these >> wrong, is very close to zero. > > But compilers and tools still have to deal with the possibility. People > other than you also write C code. Sure. Lots of people write code in many languages and many ways. People who are good at programming find ways to minimise the risk of errors. People who write knowingly bad code and refuse to use sensible tools - well, we can only hope that their software will be unpopular and they will gradually either change their ways or leave the profession. > > I might have mixed "=" and "==" >> occasionally in my early days, with more limited tools. And while I >> might make some of them now by typos, they will immediately be spotted >> by my tools - either while editing, or after compiling. >> >> There are many other things that can go wrong in C programming, but that >> applies to all programming. I have to find and squash bugs in my code >> like everyone else - regardless of the language. > > No: a lot of this is specific to C, because it's such a old language and > because of many poor design choices. Ah, so when I program in languages other than C, I don't make mistakes? That is nice of you to tell me - it will save me a lot of effort in my testing and debugging for PHP, Python, Delphi, assembly, C++, and other languages I sometimes use. > > But the things you get >> hung up about, the things that you feel your language has "fixed", >> simply are not a problem if you have good development practices and use >> appropriate tools. > > And what if you want to use other tools, like for example tcc? > I don't want to use tcc - a problem avoided is a problem solved. If I need to use an inferior compiler (as sometimes happens in my line of work), I use gcc as a linter. Other tools are also available, freely (such as clang-tidy or splint), mid price (such as pc-lint), or expensive (such as PVS-Studio, Klockwise, etc.). > Below is a C program (2 modules) demonstrating some of the problems I > listed. gcc with no options, tcc, bcc, lcc, and msvc (latter using > default rextester options) said nothing. > > gcc with some options gave quite a few warnings, but missed some things. > clang (with rextester default options) gave fewer. All, when I managed > to create an executable, gave a program that crashed (except bcc that > would not link as given, because it saw two 'abc's). When you drive your car, do you put on a seatbelt? If you want to write shite, go ahead. Don't expect any sympathy or support from people who try to do their best as programmers. Clearly C is not the language for you - it simply places too many demands on you to learn the language and tools, think about what you are doing, and program sensibly. Maybe you'd be better off here: <https://scratch.mit.edu/>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-10-09 14:39 +0000 |
| Message-ID | <PimnF.50489$SW2.39098@fx24.iad> |
| In reply to | #146804 |
David Brown <david.brown@hesbynett.no> writes: >On 09/10/2019 15:03, Bart wrote: >>>> (10) Accidentally leave out 'break' after a case block, and the >>>> behaviour silently changes >>> >>> Solved by gcc warnings. >> >> (Really, you will get a warning each time you actually do want a >> fall-through?) > >If you want real fall-through - a rare event, but plausible - you add a >comment such as "// fall-through". (C++ standardises this with an >attribute.) The common situation of multiple cases does not need a comment. For some value of rare: $ grep -i fallthrough */*.[ch]* | wc -l 108 Annotating such has been common for over forty years (c.f. lint(1)). https://en.wikipedia.org/wiki/Lint_(software)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-09 15:58 +0100 |
| Message-ID | <NAmnF.2539347$dw4.217270@fx12.am4> |
| In reply to | #146804 |
On 09/10/2019 14:53, David Brown wrote:
> No one wonders why gcc is so slow.
Everybody does, eg:
"GCC is generally agreed to be too slow"
(https://gcc.gnu.org/wiki/Speedup_areas)
For a basic compile, tcc is 40 times faster than gcc-O0 (for sqlite3.c
on my Linux), ie. 0.25 seconds compared with 11 seconds.
Since tcc manages to do all the basic stuff common to any C compiler
(locating headers, tokenising, macro expansions, lookups, parsing,
type-checking, and generating basic code), all in 0.25 seconds, anyone
with an inquiring (and slightly cynical) mind would wonder what on earth
is gcc doing in that other 10.75 seconds?
It's not the optimising!
> And no one complains about it being
> slow (except you, of course).
Anyone who tries out tcc will almost certainly start to balk at the
speed of gcc. If they still tolerate it, it will be cause of gcc's
superior code. Or because software has a dependency on gcc.
> If you are not using sensible coding practices, what are you doing as a
> programmer?
And yet again: a language could enforce those practices, but C doesn't.
> If you want real fall-through - a rare event, but plausible - you add a
> comment such as "// fall-through". (C++ standardises this with an
> attribute.) The common situation of multiple cases does not need a comment.
So, the only real advantage of having to write 'break' all the time, was
not having to write it for fall-through, but now you need to write '//
fallthough!'
> There /is/ something wrong with it - it is unclear.
So a language issue. Since << and >> scale values like * and /, they
belong at the same precedence level. It is possible no else realises
this simple fact?
>> A little? Here's a 10x10 table for my language showing whether a mixed
>> binary op is done as signed (S) or unsigned (U):
>
> Learn the rules of C if you want to program in C. If there is something
> you find extraordinarily difficult, don't use it.
And what are they in this case? The fact is that they are neither simple
nor intuitive.
Is int8_t*uint64_t done as signed or unsigned?
(My C compiler apparently doesn't follow the rules, as this code:
int8_t a = -4;
uint64_t b = 8;
printf("%f\n",(double)(a*b));
produces the answer -32. gcc, tcc, lcc on Windows display:
18446744073709552000.000000
while msvc, clang and gcc on rextester show:
18446744073709551616.000000
However my bcc gives the same common-sense answer as my language:
i8 a := -4
u64 b := 8
println a*b
which is -32. (The C needs the conversion to float, as otherwise you
have to /know/ the expected type, whether it is signed or unsigned, in
order to print it! In my language:
println (a*b).typestr
shows the result type is i64.)
> People who are good at programming find ways to minimise the risk of
> errors.
I minimise errors by using the right languages. I'm sorry but C isn't
one of them.
I used it as an intermediate language because C compilers are ubiquitous.
> If you want to write shite, go ahead.
Yet gcc especially goes to an awful lot of trouble to deal with that
shite! And C, despite the 700 pages of reference, goes to little trouble
to stop people writing it.
> Clearly C is not the language for you - it simply places too many
> demands on you to learn the language and tools, think about what you are
> doing, and program sensibly. Maybe you'd be better off here:
Now you're being ridiculous. I need a systems programming language, and
for 38 years I've used my own. Successfully.
I can't write that 'shite' I showed in that C code, because the language
makes it harder to do so.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-10 22:43 +0100 |
| Message-ID | <bCNnF.797539$aq7.738850@fx09.am4> |
| In reply to | #146797 |
On 09/10/2019 14:03, Bart wrote:
> On 09/10/2019 12:41, David Brown wrote:
>> Solved by learning a little bit about the language you are using.
>
> A little? Here's a 10x10 table for my language showing whether a mixed
> binary op is done as signed (S) or unsigned (U):
>
> i8 i16 i32 i64 i128 u8 u16 u32 u64 u128
>
> i8 S S S S S S S S S S
> i16 S S S S S S S S S S
> i32 S S S S S S S S S S
> i64 S S S S S S S S S S
> i128 S S S S S S S S S S
>
> u8 S S S S S U U U U U
> u16 S S S S S U U U U U
> u32 S S S S S U U U U U
> u64 S S S S S U U U U U
> u128 S S S S S U U U U U
>
> So basically, it's unsigned if both operands are unsigned. A very simple
> rule.
>
> What would the equivalent chart for C look like? You can use an 8x8
> chart to over 8 to 64 bits. I can tell you it will be rather different
> from the above.
Here is the chart for C for the result type of a binary op:
i8 i32 u8 u32
i16 i64 u16 u64
i8 s s s s s s U U
i16 s s s s s s U U
i32 s s s s s s U U
i64 s s s s s s s U
u8 s s s s s s U U
u16 s s s s s s U U
u32 U U U s U U U U
u64 U U U U U U U U
s means the result was unsigned, U means unsigned (in caps to make these
peculiar results stand out). In this implementation, 'int' is 32 bits.
What rules do you have to follow to determine this?
(Program used to create this, other than headings, given below.)
-------------------------------------------------------------
#include <stdio.h>
#include <stddef.h>
#include <stdint.h>
typedef int8_t i8;
typedef int16_t i16;
typedef int32_t i32;
typedef int64_t i64;
typedef uint8_t u8;
typedef uint16_t u16;
typedef uint32_t u32;
typedef uint64_t u64;
void ps(char* s) {printf("%s ",s);}
#define ss(x) _Generic((x), \
i8: "s", \
i16: "s", \
i32: "s", \
i64: "s", \
u8: "U", \
u16: "U", \
u32: "U", \
u64: "U", \
default: "other")
u8 U8;
u16 U16;
u32 U32;
u64 U64;
i8 I8;
i16 I16;
i32 I32;
i64 I64;
int main(void) {
//puts(" i i i i u u u u");
//puts(" 8 1 3 6 8 1 3 6");
//puts(" 6 2 4 6 2 4");
//puts("");
ps("i8 ");ps(ss(I8*I8)); ps(ss(I8*I16)); ps(ss(I8*I32));
ps(ss(I8*I64)); ps(""); ps(ss(I8*U8)); ps(ss(I8*U16));
ps(ss(I8*U32)); ps(ss(I8*U64)); puts("");
ps("i16 ");ps(ss(I16*I8)); ps(ss(I16*I16)); ps(ss(I16*I32));
ps(ss(I16*I64)); ps(""); ps(ss(I16*U8)); ps(ss(I16*U16));
ps(ss(I16*U32)); ps(ss(I16*U64)); puts("");
ps("i32 ");ps(ss(I32*I8)); ps(ss(I32*I16)); ps(ss(I32*I32));
ps(ss(I32*I64)); ps(""); ps(ss(I32*U8)); ps(ss(I32*U16));
ps(ss(I32*U32)); ps(ss(I32*U64)); puts("");
ps("i64 ");ps(ss(I64*I8)); ps(ss(I64*I16)); ps(ss(I64*I32));
ps(ss(I64*I64)); ps(""); ps(ss(I64*U8)); ps(ss(I64*U16));
ps(ss(I64*U32)); ps(ss(I64*U64)); puts("");
puts("");
ps("u8 ");ps(ss(U8*I8)); ps(ss(U8*I16)); ps(ss(U8*I32));
ps(ss(U8*I64)); ps(""); ps(ss(U8*U8)); ps(ss(U8*U16));
ps(ss(U8*U32)); ps(ss(U8*U64)); puts("");
ps("u16 ");ps(ss(U16*I8)); ps(ss(U16*I16)); ps(ss(U16*I32));
ps(ss(U16*I64)); ps(""); ps(ss(U16*U8)); ps(ss(U16*U16));
ps(ss(U16*U32)); ps(ss(U16*U64)); puts("");
ps("u32 ");ps(ss(U32*I8)); ps(ss(U32*I16)); ps(ss(U32*I32));
ps(ss(U32*I64)); ps(""); ps(ss(U32*U8)); ps(ss(U32*U16));
ps(ss(U32*U32)); ps(ss(U32*U64)); puts("");
ps("u64 ");ps(ss(U64*I8)); ps(ss(U64*I16)); ps(ss(U64*I32));
ps(ss(U64*I64)); ps(""); ps(ss(U64*U8)); ps(ss(U64*U16));
ps(ss(U64*U32)); ps(ss(U64*U64)); puts("");
}
--------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-11 01:45 +0300 |
| Message-ID | <20191011014553.ed25e5fbbcfcd0bff86b6ea7@gmail.com> |
| In reply to | #146854 |
Bart: > Here is the chart for C for the result type of a binary > op: > > i8 i32 u8 u32 > i16 i64 u16 u64 > > i8 s s s s s s U U > i16 s s s s s s U U > i32 s s s s s s U U > i64 s s s s s s s U > > u8 s s s s s s U U > u16 s s s s s s U U > u32 U U U s U U U U > u64 U U U U U U U U > > s means the result was unsigned, U means unsigned (in caps > to make these peculiar results stand out). In this > implementation, 'int' is 32 bits. > > What rules do you have to follow to determine this? The rules are published in the standard as the usual unary conversions and the usual binary conversions. If you study the two sets of rules you may find the whole behavior less illogican than it seems from your table. -- () 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-11 01:00 +0100 |
| Message-ID | <CCPnF.712275$665.674905@fx28.am4> |
| In reply to | #146860 |
On 10/10/2019 23:45, Anton Shepelev wrote: > Bart: > >> Here is the chart for C for the result type of a binary >> op: >> >> i8 i32 u8 u32 >> i16 i64 u16 u64 >> >> i8 s s s s s s U U >> i16 s s s s s s U U >> i32 s s s s s s U U >> i64 s s s s s s s U >> >> u8 s s s s s s U U >> u16 s s s s s s U U >> u32 U U U s U U U U >> u64 U U U U U U U U >> >> s means the result was unsigned, U means unsigned (in caps >> to make these peculiar results stand out). In this >> implementation, 'int' is 32 bits. >> >> What rules do you have to follow to determine this? > > The rules are published in the standard as the usual unary > conversions and the usual binary conversions. If you study > the two sets of rules you may find the whole behavior less > illogican than it seems from your table. Would you design a new language with this exact behaviour? (No need to answer; that was rhetorical...)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-12 12:01 -0400 |
| Message-ID | <iNmoF.10267$9v2.2300@fx31.iad> |
| In reply to | #146864 |
On 10/10/19 8:00 PM, Bart wrote: > On 10/10/2019 23:45, Anton Shepelev wrote: >> Bart: >> >>> Here is the chart for C for the result type of a binary >>> op: >>> >>> i8 i32 u8 u32 >>> i16 i64 u16 u64 >>> >>> i8 s s s s s s U U >>> i16 s s s s s s U U >>> i32 s s s s s s U U >>> i64 s s s s s s s U >>> >>> u8 s s s s s s U U >>> u16 s s s s s s U U >>> u32 U U U s U U U U >>> u64 U U U U U U U U >>> >>> s means the result was unsigned, U means unsigned (in caps >>> to make these peculiar results stand out). In this >>> implementation, 'int' is 32 bits. >>> >>> What rules do you have to follow to determine this? >> >> The rules are published in the standard as the usual unary >> conversions and the usual binary conversions. If you study >> the two sets of rules you may find the whole behavior less >> illogican than it seems from your table. > > Would you design a new language with this exact behaviour? > > (No need to answer; that was rhetorical...) > As I remember, there was A LOT of debate over this when the Standard was being worked on, with lots of arguments for several different options of how it should work (with one option making it largely implementation defined). If you haven't (and are unwilling to) look at that body of discussion, putting it down is a sign of narrow mindedness. It WAS a tough decision, and perhaps if made now fresh, it might be made differently, but it would be a VERY high hurdle to justify making a change now, because any change breaks a number of existing programs. I would say from your comments over time that at your core, you strongly disagree with some of the core decisions made by the C Standards Committee early in its life (perhaps because you don't really understand them). Part of that, is that you have a very narrow view of what you want out to the language, in part because you have a narrow view of portability. If C isn't the language that meets your needs, don't use it (I seem to remember you coming up with that decision several times, but then come back). Don't expect the world to change just to meet your personal needs, but see things as they are and work with them. C was around long before your languages. IF you want interoperability then either you need to adopt the 'C' way in your languages, or build a translation layer between the two of them. If you want to be able to import C definitions, then you need to understand the C language. If you want to generate C as an output language, you REALLY need to understand C, and REALLY workout how to translate the differences in concepts.
[toc] | [prev] | [next] | [standalone]
Page 19 of 25 — ← Prev page 1 … 17 18 [19] 20 21 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web