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 17 of 25 — ← Prev page 1 … 15 16 [17] 18 19 … 25 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-14 08:13 -0700 |
| Message-ID | <86mue3742r.fsf@linuxsc.com> |
| In reply to | #146936 |
Richard Damon <Richard@Damon-Family.org> writes: >> [getting C to have integer types of more than 64 bits] > > The issue is that there are many existing libraries (including those > provided by the OS), and changing the definition of an existing type > (like intmax_t) changes how those functions would be caused. To make > that change, and thus create a new incompatible ABI, says that to run a > program with that new ABI says that all the libraries that is uses > (including the OS calls) need to be provided in that new ABI. The OS > library in particular tends to be a bit slow in evolving, and the > existing solution, __int128_t being availble, but NOT considered an > extended integer type, so not considered by intmax_t, seems to work well > enough for practical uses, that the implementations and library > providers aren't rushing to make the change. > > The thing to remember is that supporting multiple ABIs adds complexity > to a system. That's true, but isn't it the case that many or most modern OSes support more than one ABI already (ie, 32-bit and 64-bit)? If they already support more than one, is it that much more work to add a third (or fourth, etc)? Of course the cost is non-zero, but I would think it would be a lot less than the cost of going from one to two, and that cost has already been paid.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-10-15 07:45 -0400 |
| Message-ID | <HjipF.59513$621.43835@fx38.iad> |
| In reply to | #146952 |
On 10/14/19 11:13 AM, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >>> [getting C to have integer types of more than 64 bits] >> >> The issue is that there are many existing libraries (including those >> provided by the OS), and changing the definition of an existing type >> (like intmax_t) changes how those functions would be caused. To make >> that change, and thus create a new incompatible ABI, says that to run a >> program with that new ABI says that all the libraries that is uses >> (including the OS calls) need to be provided in that new ABI. The OS >> library in particular tends to be a bit slow in evolving, and the >> existing solution, __int128_t being availble, but NOT considered an >> extended integer type, so not considered by intmax_t, seems to work well >> enough for practical uses, that the implementations and library >> providers aren't rushing to make the change. >> >> The thing to remember is that supporting multiple ABIs adds complexity >> to a system. > > That's true, but isn't it the case that many or most modern OSes > support more than one ABI already (ie, 32-bit and 64-bit)? If they > already support more than one, is it that much more work to add a > third (or fourth, etc)? Of course the cost is non-zero, but I would > think it would be a lot less than the cost of going from one to two, > and that cost has already been paid. > Yes, many OSes now support two ABIs, for 32 and 64 bit codes, and code that uses one tends to have a very hard time directly interfacing with the other (any interaction tends to be very indirect). I am not sure people wanting to use int128_t, having it be a real 'extended integer type' would think it was worth being THAT isolated from other applications. Adding another mode like that is likely still a moderate amount of work, and I am not sure how easy it would be to add that option to the existing executing program formats.
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2019-10-15 05:12 -0700 |
| Message-ID | <d4af021c-ebcc-4690-a0a1-986d8d2804a0@googlegroups.com> |
| In reply to | #146988 |
On Tuesday, October 15, 2019 at 4:45:53 AM UTC-7, Richard Damon wrote: > On 10/14/19 11:13 AM, Tim Rentsch wrote: > > Richard Damon <Richard@Damon-Family.org> writes: > > > >>> [getting C to have integer types of more than 64 bits] > >> > >> The issue is that there are many existing libraries (including those > >> provided by the OS), and changing the definition of an existing type > >> (like intmax_t) changes how those functions would be caused. To make > >> that change, and thus create a new incompatible ABI, says that to run a > >> program with that new ABI says that all the libraries that is uses > >> (including the OS calls) need to be provided in that new ABI. The OS > >> library in particular tends to be a bit slow in evolving, and the > >> existing solution, __int128_t being availble, but NOT considered an > >> extended integer type, so not considered by intmax_t, seems to work well > >> enough for practical uses, that the implementations and library > >> providers aren't rushing to make the change. > >> > >> The thing to remember is that supporting multiple ABIs adds complexity > >> to a system. > > > > That's true, but isn't it the case that many or most modern OSes > > support more than one ABI already (ie, 32-bit and 64-bit)? If they > > already support more than one, is it that much more work to add a > > third (or fourth, etc)? Of course the cost is non-zero, but I would > > think it would be a lot less than the cost of going from one to two, > > and that cost has already been paid. > > > > Yes, many OSes now support two ABIs, for 32 and 64 bit codes, and code > that uses one tends to have a very hard time directly interfacing with > the other (any interaction tends to be very indirect). > That might be true for C. But for programming languages that use a different runtime mechanism, well, sorry, but that statement is kind of incorrect.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-15 13:04 -0700 |
| Message-ID | <lnmue1g4gx.fsf@kst-u.example.com> |
| In reply to | #146988 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 10/14/19 11:13 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>>> [getting C to have integer types of more than 64 bits]
>>>
>>> The issue is that there are many existing libraries (including those
>>> provided by the OS), and changing the definition of an existing type
>>> (like intmax_t) changes how those functions would be caused. To make
>>> that change, and thus create a new incompatible ABI, says that to run a
>>> program with that new ABI says that all the libraries that is uses
>>> (including the OS calls) need to be provided in that new ABI. The OS
>>> library in particular tends to be a bit slow in evolving, and the
>>> existing solution, __int128_t being availble, but NOT considered an
>>> extended integer type, so not considered by intmax_t, seems to work well
>>> enough for practical uses, that the implementations and library
>>> providers aren't rushing to make the change.
>>>
>>> The thing to remember is that supporting multiple ABIs adds complexity
>>> to a system.
>>
>> That's true, but isn't it the case that many or most modern OSes
>> support more than one ABI already (ie, 32-bit and 64-bit)? If they
>> already support more than one, is it that much more work to add a
>> third (or fourth, etc)? Of course the cost is non-zero, but I would
>> think it would be a lot less than the cost of going from one to two,
>> and that cost has already been paid.
>>
>
> Yes, many OSes now support two ABIs, for 32 and 64 bit codes, and code
> that uses one tends to have a very hard time directly interfacing with
> the other (any interaction tends to be very indirect).
>
> I am not sure people wanting to use int128_t, having it be a real
> 'extended integer type' would think it was worth being THAT isolated
> from other applications. Adding another mode like that is likely still a
> moderate amount of work, and I am not sure how easy it would be to add
> that option to the existing executing program formats.
As I've mentioned, my system (Ubuntu 18.04 x86_64) has separate
64-bit and 32-bit libraries, used with "gcc [-m64]" and "gcc -m32"
respecpectively. (There's also "-mx32", but let's ignore that.)
That means, for example, two different sets of code for printf.
Since pointer sizes differ, it's not feasible to share code; probably
most library functions are affected.
Making intmax_t 128 bits isn't such a radical change, and should only
affect a few library functions (*printf, *scanf, and the 6 functions
declared in <inttypes.h>).
There is some precedent for a similar compatibility issue:
large file support <https://en.wikipedia.org/wiki/Large-file_support>.
Some implementations provide a way to specify 32-bit or 64-bit file size
support by predefining a macro (see the POSIX fseeko() and ftello()
functions). Something similar could be done for 64-bit vs. 128-bit
[u]intmax_t, with alternative forms of the affected functions in the
same library.
I haven't thought through all the details, but if there were enough
demand for 128-bit integers, it could be done without breaking
everything. (My impression is that there isn't really much demand,
though, and what there is is mostly satisfied by gcc's __int128 and
similar features. IPv6 addresses are 128 bits, but there's not much
need to treat them as integers.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-17 10:14 -0700 |
| Message-ID | <86lftj47ma.fsf@linuxsc.com> |
| In reply to | #146988 |
Richard Damon <Richard@Damon-Family.org> writes: > On 10/14/19 11:13 AM, Tim Rentsch wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>>> [getting C to have integer types of more than 64 bits] >>> >>> The issue is that there are many existing libraries (including those >>> provided by the OS), and changing the definition of an existing type >>> (like intmax_t) changes how those functions would be caused. To make >>> that change, and thus create a new incompatible ABI, says that to run a >>> program with that new ABI says that all the libraries that is uses >>> (including the OS calls) need to be provided in that new ABI. The OS >>> library in particular tends to be a bit slow in evolving, and the >>> existing solution, __int128_t being availble, but NOT considered an >>> extended integer type, so not considered by intmax_t, seems to work well >>> enough for practical uses, that the implementations and library >>> providers aren't rushing to make the change. >>> >>> The thing to remember is that supporting multiple ABIs adds complexity >>> to a system. >> >> That's true, but isn't it the case that many or most modern OSes >> support more than one ABI already (ie, 32-bit and 64-bit)? If they >> already support more than one, is it that much more work to add a >> third (or fourth, etc)? Of course the cost is non-zero, but I would >> think it would be a lot less than the cost of going from one to two, >> and that cost has already been paid. > > Yes, many OSes now support two ABIs, for 32 and 64 bit codes, and code > that uses one tends to have a very hard time directly interfacing with > the other (any interaction tends to be very indirect). Sure, but those ABIs are different in some serious ways, such as having differently sized addresses. The ABI I'm suggesting would be the same as the current 64-bit ABI, except with bigger maximum integer types ([u]intmax_t, and some additional typedefs for integer types having greater than 64 bits). So there should be very little problem interfacing between the existing 64-bit ABI and the new enhanced ABI. > I am not sure people wanting to use int128_t, having it be a real > 'extended integer type' would think it was worth being THAT isolated > from other applications. Adding another mode like that is likely still a > moderate amount of work, and I am not sure how easy it would be to add > that option to the existing executing program formats. First I don't think the isolation would be nearly as much as you think. Existing programs that don't use large integer types (and in particular [u]intmax_t) could be used directly. Programs that use __int128_t presumably would be immediately built again to take advantage of the new regime. Second I don't think adding an enhanced 64-bits-and-larger ABI will be that much work, because nearly all of it is the same as the existing 64-bit ABI. Furthermore the transition cost will be less if the work is started sooner rather than later. Personally I would like to see ISO C adopt a higher value for INTMAX_MAX and UINTMAX_MAX, at least 256 bits (and maybe a Recommended Practice suggesting a still higher value). There are lots of computations that fall in the middle ground between the de facto current limit of 64 bits and needing a full-blown multiple-precision arithmetic package. I would much rather use standard large integer types, and have the compiler figure out how to make things work nicely, than either code it myself or try to pull in a probably-too-large multiple-precision package to do it for me. AFAICS the main holdup is the silly restriction that [u]intmax_t cannot practically be more than 64 bits, because of ABI limitations. If there were some good reason why 64 bits should be the limit that would be one thing, but it looks like the only thing holding us back is inertia. I remember too well the times when people said 16 bit words were enough. Bleah. It's deja vu all over again.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-15 12:24 -0400 |
| Message-ID | <qo4rse$o8a$1@dont-email.me> |
| In reply to | #146899 |
On 10/12/19 3:17 PM, Keith Thompson wrote: ... > I don't see a requirement in the standard to support constants of > type int128_t. But an implementation could support such constants > as an extension. (gcc doesn't.) That's true, but if int128_t is supported, it's inherently the case that int_least128_t can be supported too, and I think that it should be, though the standard fails to mandate it. If so, and you #include <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is required to expand to an integer constant expression with the same type as the promoted type of int_least128_t (7.20.4.1). That would be same as int_least128_t except in the extremely unlikely case that INT_LEAST128_MAX < INTMAX :-). On most systems that support int128_t, I'd expect int_least128_t to be the same as int128_t. Therefore, the expansion of INT128_C() is likely to involve some non-portable method that could be used to create such constants without using that macro.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-16 04:12 -0700 |
| Message-ID | <86bluh54he.fsf@linuxsc.com> |
| In reply to | #146994 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/12/19 3:17 PM, Keith Thompson wrote:
> ...
>
>> I don't see a requirement in the standard to support constants of
>> type int128_t. But an implementation could support such constants
>> as an extension. (gcc doesn't.)
>
> That's true, but if int128_t is supported, it's inherently the case that
> int_least128_t can be supported too, and I think that it should be,
> though the standard fails to mandate it. If so, and you #include
> <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is
> required to expand to an integer constant expression with the same type
> as the promoted type of int_least128_t (7.20.4.1). That would be same as
> int_least128_t except in the extremely unlikely case that
> INT_LEAST128_MAX < INTMAX :-). On most systems that support int128_t,
> I'd expect int_least128_t to be the same as int128_t.
> Therefore, the expansion of INT128_C() is likely to involve some
> non-portable method that could be used to create such constants without
> using that macro.
I believe it could be done completely portably as follows:
#define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-16 14:21 -0700 |
| Message-ID | <lneezcfkub.fsf@kst-u.example.com> |
| In reply to | #147007 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/12/19 3:17 PM, Keith Thompson wrote:
>> ...
>>
>>> I don't see a requirement in the standard to support constants of
>>> type int128_t. But an implementation could support such constants
>>> as an extension. (gcc doesn't.)
>>
>> That's true, but if int128_t is supported, it's inherently the case that
>> int_least128_t can be supported too, and I think that it should be,
>> though the standard fails to mandate it. If so, and you #include
>> <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is
>> required to expand to an integer constant expression with the same type
>> as the promoted type of int_least128_t (7.20.4.1). That would be same as
>> int_least128_t except in the extremely unlikely case that
>> INT_LEAST128_MAX < INTMAX :-). On most systems that support int128_t,
>> I'd expect int_least128_t to be the same as int128_t.
>> Therefore, the expansion of INT128_C() is likely to involve some
>> non-portable method that could be used to create such constants without
>> using that macro.
>
> I believe it could be done completely portably as follows:
>
> #define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n)
7.20.4p1 requires INTn_C(value) to expand to an integer constant, not
just an integer constant expression. I'm not sure that requirement is
necessary (i.e., I'm not sure we'd lose anything if it were allowed more
generally to be an integer constant expression), but there it is.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-16 19:12 -0400 |
| Message-ID | <qo884n$3as$1@dont-email.me> |
| In reply to | #147011 |
On 10/16/19 5:21 PM, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >>> though the standard fails to mandate it. If so, and you #include >>> <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is >>> required to expand to an integer constant expression with the same type >>> as the promoted type of int_least128_t (7.20.4.1). ... >> >> I believe it could be done completely portably as follows: >> >> #define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n) > > 7.20.4p1 requires INTn_C(value) to expand to an integer constant, not > just an integer constant expression. I'm not sure that requirement is > necessary (i.e., I'm not sure we'd lose anything if it were allowed more > generally to be an integer constant expression), but there it is. "The macro INTN_C(value) shall expand to an integer constant expression corresponding to the type int_leastN_t." (7.20.4p1).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-10-16 16:33 -0700 |
| Message-ID | <ln36fsfepi.fsf@kst-u.example.com> |
| In reply to | #147012 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 10/16/19 5:21 PM, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>>> though the standard fails to mandate it. If so, and you #include
>>>> <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is
>>>> required to expand to an integer constant expression with the same type
>>>> as the promoted type of int_least128_t (7.20.4.1).
> ...
>>>
>>> I believe it could be done completely portably as follows:
>>>
>>> #define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n)
>>
>> 7.20.4p1 requires INTn_C(value) to expand to an integer constant, not
>> just an integer constant expression. I'm not sure that requirement is
>> necessary (i.e., I'm not sure we'd lose anything if it were allowed more
>> generally to be an integer constant expression), but there it is.
>
> "The macro INTN_C(value) shall expand to an integer constant expression
> corresponding to the type int_leastN_t." (7.20.4p1).
That's 7.20.4.1p1. 7.20.4p1 says:
The following function-like macros expand to integer constants
suitable for initializing objects that have integer types
corresponding to types defined in <stdint.h>.
Of course an integer constant is an integer constant expression,
but I don't know why the paragraph you quoted uses the more general
term when the paragraph above it uses the more specific term.
It's hard to tell what the intent is. I think this is a flaw in the
standard. (The same flaw appears in the latest draft, N2386.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-10-16 19:48 -0400 |
| Message-ID | <qo8a8m$c4o$1@dont-email.me> |
| In reply to | #147013 |
On 10/16/19 7:33 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >> "The macro INTN_C(value) shall expand to an integer constant expression >> corresponding to the type int_leastN_t." (7.20.4p1). > > That's 7.20.4.1p1. 7.20.4p1 says: > The following function-like macros expand to integer constants > suitable for initializing objects that have integer types > corresponding to types defined in <stdint.h>. > > Of course an integer constant is an integer constant expression, > but I don't know why the paragraph you quoted uses the more general > term when the paragraph above it uses the more specific term. > It's hard to tell what the intent is. I think this is a flaw in the > standard. (The same flaw appears in the latest draft, N2386.) You're right. Both requirements can be met at the same time (at least, for those types for which an implementation supports an appropriate suffix, not necessarily a standard one), so technically it's clear, but the discrepancy is suspicious.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-10-18 06:57 -0700 |
| Message-ID | <86zhhygnqs.fsf@linuxsc.com> |
| In reply to | #147013 |
Keith Thompson <kst-u@mib.org> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 10/16/19 5:21 PM, Keith Thompson wrote:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>> ...
>>
>>>>> though the standard fails to mandate it. If so, and you #include
>>>>> <stdint.h>, then INT128_C(123456789012345678901234567890123456789) is
>>>>> required to expand to an integer constant expression with the same type
>>>>> as the promoted type of int_least128_t (7.20.4.1).
>>
>> ...
>>
>>>> I believe it could be done completely portably as follows:
>>>>
>>>> #define INT128_C(n) (INT_LEAST128_MAX - INT_LEAST128_MAX + n)
>>>
>>> 7.20.4p1 requires INTn_C(value) to expand to an integer constant, not
>>> just an integer constant expression. I'm not sure that requirement is
>>> necessary (i.e., I'm not sure we'd lose anything if it were allowed more
>>> generally to be an integer constant expression), but there it is.
>>
>> "The macro INTN_C(value) shall expand to an integer constant expression
>> corresponding to the type int_leastN_t." (7.20.4p1).
>
> That's 7.20.4.1p1. 7.20.4p1 says:
> The following function-like macros expand to integer constants
> suitable for initializing objects that have integer types
> corresponding to types defined in <stdint.h>.
>
> Of course an integer constant is an integer constant expression,
> but I don't know why the paragraph you quoted uses the more general
> term when the paragraph above it uses the more specific term.
> It's hard to tell what the intent is. I think this is a flaw in the
> standard. (The same flaw appears in the latest draft, N2386.)
To me it seems clear that the requirement is meant to be an integer
constant expression (that may be used in a #if directive), and not
limited to 'integer constant' as defined in 6.4.4.1. Consider the
following:
* The quoted sentence in 7.20.4 p1 looks like a description more
than it does a requirement. In particular, it does not contain
the word "shall".
* The second paragraph, 7.20.4 p2 (which incidentally does use
the word "shall"), says explicitly "as defined in 6.4.4.1"
when it means to refer specifically to the syntactic form.
* The third paragraph, 7.20.4 p3, says "Each invocation of one of
these macros shall expand to an integer constant expression
suitable for use in #if preprocessing directives." Surely that
sentence is meant to state the requirement, whereas 7.20.4 p1
is meant to be read as "integer-valued constant", or something
along those lines.
Note also:
* The term "integer constant" is used in some other places in
the Standard where it is meant in the usual sense rather than
the term defined in 6.4.4.1. For example, 6.5.3.4 p3: "The
alignof operator yields the alignment requirement of its
operand type. The result is an integer constant."
* When the specific 6.4.4.1 meaning of "integer constant" is
intended, this is called out explicitly also in some other
places in the Standard. For example, 7.22.1.4 p3: "If the
value of base is zero, the expected form of the subject
sequence is that of an integer constant as described in
6.4.4.1, [...]"
Taking all these together it seems pretty convincing that
"integer constant expression" is what was intended.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-13 21:22 +0300 |
| Message-ID | <20191013212235.8d971d3f75e7182c8f10e22a@gmail.com> |
| In reply to | #146865 |
James Kuyper: > How would you feel about a platform where long is a 64-bit > type, and long long is a 128-bit type? Do you still think > int64_t should be compatible with long long on such a > platform? If so, what should that even mean -- how would > it be implemented? For those who want the convenience of compatibility between types with identical size and representation, the standard could introduce a concept of "non-portable C" with a set of corresponding relaxations and means of specifying platform- specific assertions that make those relaxations possible on the given platform. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-10-11 01:02 +0300 |
| Message-ID | <20191011010223.5aa0eec89e326578300f27d2@gmail.com> |
| In reply to | #146795 |
David Brown to Anton Shepelev: > > My intuitive and simplified (mis)understanding and > > justification of the basic C types is as follows: > > > > -- Simple type identifiers unmodifed by adjectives > > represent the most natural type for the machine, so > > that `int' would be the most natural integer for > > the CPU. > > > > -- `long' identifes a extended size, perhaps unnatural > > or even unsupported natively by the CPU. > > > > -- `short' identifies a smaller size than the CPU can > > easily handle. > > That is a reasonable approximation. It is not entirely > accurate, but I'm sure you know where to find more exact > definitions. I knew it was not precisely correct, therefore calling it a (mis)understanding, but I am amazed that I guessed the spirit and the original intention of the notaion -- I have never read about it. > Bart doesn't want to do that sort of thing. He wants to > use a function called "sprintf" in his original language, > with slightly different details or semantics from the > function in C, but to translate it directly to the > function "sprintf" in C. It is the same with his > types -- he wants to translate a "generic reference" in > his language directly into "void *" in C, despite them > being significantly different concepts, and he wants to > translate his "int" directly into C "int" despite > differences (such as overflow behaviour). These > differences are, in Bart's view, failings in C for not > picking the exact behaviour he has in his own language. > The sane solution is to use wrappers or translations as > needed, but that would go against his principles of > directly translating and then blaming C for being wrong. I agree. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-07 17:01 +0200 |
| Message-ID | <qnfjvs$ba3$1@dont-email.me> |
| In reply to | #146686 |
On 07/10/2019 16:01, Bart wrote: > On 07/10/2019 12:57, David Brown wrote: >> On 07/10/2019 13:42, Bart wrote: > >>> mov rax, QWORD PTR -8[rbp] >>> mov QWORD PTR -16[rbp], rax >>> mov rax, QWORD PTR -16[rbp] >>> mov QWORD PTR -8[rbp], rax >> >> >> That's not what I get when I compile it. I get an empty main(), and >> some warnings about unused variables. Oh, wait - we are back to the >> idiotic "it worked on my tiny, unrealistic unoptimised test therefore it >> is perfectly valid code" attitude. > > It works also on 100,000 lines of generated C. Or 600,000 lines > including all combinations of target OSes and machine word sizes. Code > that uses function pointer tables designed around void* extensively. That is a small test - all the code is generated by your generators. It will use the limited subset of C that you generate. It will be tested with the limited set of optimisation flags, the limited set of targets, limited set of compilers. Really, it is a /very/ small test sample - the number of lines in it simply doesn't matter. Of course it is likely that converting a function pointer to a void* pointer will work in the "obvious" way on targets that have the same size of pointers for functions and data. That's not the point. The point is, you can't be sure of that from a few tests (and you have only done a few). Maybe in some circumstances, some compilers will use the undefined behaviour nature of the code to eliminate code that clearly (by the definition of the language) has no meaning. >> The big issue with doing this kind of undefined behaviour code is that >> tests are worthless. It does not matter what code your test case >> generates, you have absolutely no guarantees that it will work in >> practice with real code. > > You're missing the point. Those compilers generated what would be the > correct code, if that restriction wasn't in the language. Yes, that is true. But since the language does have that restriction, compilers can do whatever they like with the code (once they have generated whatever diagnostics the language standards require). Compilers can also document the validity of such conversions as an extension - in which case the code is valid on such compilers, even if it is not portable. No matter what you would like this code to mean, however, and no matter how simple it might be for compilers to implement it, the simple fact is that the C standards don't defined these conversions, and compilers don't document the conversions as an extension. Therefore, they are not part of the language - regardless of what code happens to be generated by test runs of a compiler. (Since such conversions would be easy to implement, and they are not, ask yourself why? Could it be because they are simply not a useful feature, or a feature that many people want?) > > How did they manage that, by chance? It's because it's perfectly clear > what the code should be. Yes - it should be an error message (or a diagnostic of some kind). > > BTW you can get around this restriction by writing the assignments like > this: > > p=(void*)(intptr_t)f; > f=(void(*)(void))(intptr_t)p; > That is implementation defined (intptr_t may not exist, and it is only guaranteed to be of a size suitable for pointer-to-void, i.e., data pointers). But yes, it is (AFAICS) allowed - and compilers should implement it. You can't use it to change the type of a function pointer before calling it - you need to convert back to a proper (compatible) type before the call. But converting back and forth to and from an integer type of sufficient size should work. The difference between this code and earlier code, however, is that the C standards say what it does (though it is implementation defined). That is critically different from undefined behaviour. > (Where presumably the argument that f and p might be different sizes > goes out of the window.). It doesn't go out the window at all - "intptr_t" does not have to be big enough for function pointers. (I don't know off-hand of any gcc targets for which that would be an issue, but I have used devices with different sizes of pointers for data and function pointers.) > Unsurprisingly, it generates exactly the same > code: > > mov rax, QWORD PTR -8[rbp] > mov QWORD PTR -16[rbp], rax > mov rax, QWORD PTR -16[rbp] > mov QWORD PTR -8[rbp], rax > > If there is a way to legally convert such pointers, why don't compilers > do that? If it needs an explicit cast, then (void*) should suffice as > indication that the programmer intends that to happen. If this were a useful feature, it might have been in the C standards, or a documented extension for compilers. There are endless numbers of things that compilers could easily support and that one odd-bod thinks would be useful, without being part of the language or compiler extensions. > > The downsides of this double cast, is having to go and dig up the exact > function signature needed converting to function pointer, and having the > cast now being an extra piece of maintenance to do. Here's an idea - don't write such unnecessarily pointless code. If you want a "generic function pointer type", use "void (*)(void)". Use a typedef to make it nicer. This isn't rocket science. typedef void (fvoid)(void); Then you can use "fvoid *" for generic function pointers rather than "void *". > > (This also makes it tricky to use in generated code, especially where > the function in question is from the C library, and the alternate HLL > may have needed to use a modified declaration from the original.) If you are writing a code generator, it is /your/ responsibility to generate valid code. Don't moan about something being "tricky", especially when it really is not. (There are lots of tricky things about a code generator - but this is not one of them.) > >>> And here is bcc's output: >>> >>> mov D0, [Dframe-16] >>> mov [Dframe-8], D0 >>> mov [Dframe-16], D0 >>> >>> All perfectly well-defined, and exactly as expected: just moving a >>> 64-bit bit-pattern. >>> >>> So what purpose does -pedantic serve here? >> >> It might help you stop writing bad code? > > No, it stops me running my programs on Linux systems. Or least makes it > much harder to compile because of the 1000s of lines of messages that > needs to be ignored. > > The programs run otherwise well enough that I can run some of tools on > Linux (which are interpreted code and need that 43,000-line generated C > program to compilable). > > So why should I care? What do you think I should do, spend another month > refining my C generator, or rewriting my applications, so that they > compile with -pedantic, rather than simply not using that option? What a > waste of time! Talk about making a mountain out of a molehill! It would take you far, far less time to implement generation of generic function pointers properly than you have wasted in finding excuses for writing bad code. This has nothing to do with how hard it might be, or how big the changes might be - it is purely about your silly attempts at finding things to hate about C. > > I've already spent 3 weeks dealing with issues that would fill a dozen > threads; this is one of the most insignificant and simplest to deal > with, because it is so easily ignored. > >> If you have an issue with the way C is specified, there are procedures >> for filing defect reports or suggestions. > > No thanks. I know how to use my tools. That's what you guys are always > going on about, right? I guess that knowing when to leave out an option > is not as good as knowing when to add it! > > (I don't know what they are, >> and they might be a bit bureaucratic, but they do exist.) If you think >> gcc should support such conversions as a documented extension, file a >> "feature request" bug with gcc. >> >> But at the moment, you are like someone who thinks the 30 mph speed >> limit on a road is wrong, > > Wrong analogy. This like not being able to drive my car at all in the UK > (-pedantic-errors), because I don't carry a breathalyser kit in my glove > box. And the restriction exists because it is a requirement in France. > > And this for someone who doesn't drink anyway. > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-07 12:24 +0200 |
| Message-ID | <qnf3p8$cng$1@dont-email.me> |
| In reply to | #146678 |
On 07/10/2019 11:59, Bart wrote: > On 07/10/2019 08:39, mark.bluemel@gmail.com wrote: >> On Monday, 7 October 2019 01:32:33 UTC+1, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> So I'll leave you guys to it. >>> >>> You've threatened to leave this newsgroup before. >> >> s/threatened/offered/ >> >> Can I propose Bluemel's law please? >> >> "Any discussion on comp.lang.c will eventually resolve to teaching Bart >> how to make gcc a conforming C compiler". > > > Why gcc? Why not tcc? gcc is not the only free compiler around. > > tcc accepts '-pedantic' but will not report anything amiss with my void* > function pointer conversion. Does tcc's documentation say that it is conforming (modulo bugs and occasional missing features) when "-pedantic" is given? Or does it have another way to make it conforming (or as close as it can)? Does it even specify what C standard version it follows? If not, then it is irrelevant here. > > On Windows I primarily use my own 'bcc', which doesn't report any error > either. Does bcc's documentation say that it is conforming (modulo bugs and occasional missing features) when "-pedantic" is given? Or does it have another way to make it conforming (or as close as it can)? Does it even specify what C standard version it follows? If not, then it is irrelevant here. If you want to substitute a different free (or commonly used) compiler that /does/ try to provide a conforming mode, then that would be fine. clang might be a reasonable example, as might Intel's compiler. I'm sure there are others. > > When I write or generate source code that I label as 'C', it is code > that will be accepted by any of: > > gcc prog.c > tcc prog.c > bcc prog > That is not how "C" is defined. > If that code is not the 100% standards-conformant C that is favoured in > this heavily gcc/Linux-centric group, then I don't care. Consider English as an analogy. Imagine you were posting to human.languages.english, in a thread about grammar. People there are trying to help a new student understand the difference between "it's" and "its". And then some comes alone and says "Just write "itz". I checked with a couple of neighbours - one is Chinese, the other is half deaf, but they both understood me. Therefore it is perfectly correct English."
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-07 12:18 +0100 |
| Message-ID | <laFmF.798865$Nw3.166890@fx40.am4> |
| In reply to | #146680 |
On 07/10/2019 11:24, David Brown wrote: > On 07/10/2019 11:59, Bart wrote: >> On 07/10/2019 08:39, mark.bluemel@gmail.com wrote: >> Why gcc? Why not tcc? gcc is not the only free compiler around. >> >> tcc accepts '-pedantic' but will not report anything amiss with my void* >> function pointer conversion. > > Does tcc's documentation say that it is conforming (modulo bugs and > occasional missing features) when "-pedantic" is given? Or does it have > another way to make it conforming (or as close as it can)? Does it even > specify what C standard version it follows? If not, then it is > irrelevant here. I consider tcc an important and useful compiler, especially on Linux, and especially on slower machines such as the RPis. Its speed makes it a more practical way of processing the output of my 'M' compiler, as it will complete instantly, compared to the annoying lag you get with gcc, and for that you get -O0 code which is as slow as tcc. Try -O3 and it will take forever. I don't care about diagnostics when in this role, because it's processing generated code that has already been verified by my compiler, for a language that allows void*/function pointer conversions. There are some minor issues still with tcc, but I am happy to code around them in my C code generator (eg. doesn't like "$" in identifiers, or some code-gen bugs), because there are tangible benefits. >> On Windows I primarily use my own 'bcc', which doesn't report any error >> either. > > Does bcc's documentation say that it is conforming (modulo bugs and > occasional missing features) when "-pedantic" is given? No. When I had documentation for it, it called itself a C-dialect compiler. It is still a highly useful language (eg. it can compile Lua, or tcc, or any of my compilers/interpreters). On Windows, I use mainly bcc, followed by gcc and tcc, unless some C code annoyingly uses features I don't support (VLAs, designated initialisers, compound literals). > If you want to substitute a different free (or commonly used) compiler > that /does/ try to provide a conforming mode, then that would be fine. As I said, I'm not interested. As it is, the C generated by my compiler already can only represent a subset of my original language. So if I need a key application to go through a C compiler, then I need to avoid certain features. If every C compiler rejected void*/fnptr conversions as errors, then that would be yet another thing I couldn't use. But it's a key feature I rely on, and it is very difficult to write workarounds in generated C. (I've had enough fun and games with *printf-family functions, which I only got around by getting rid of 99.9% of those calls in both the generated C and explicit ones in the source language; see 'What are you working on?' thread in comp.lang.misc.) I've already said that void*/fnptr pointer conversions prohibitions are a C language artefact, since it isn't an actual hardware issue for the machines I'm ever likely to work on. >> When I write or generate source code that I label as 'C', it is code >> that will be accepted by any of: >> >> gcc prog.c >> tcc prog.c >> bcc prog > That is not how "C" is defined. That's how /I/ use C. You feed those compilers some text, out comes an executable that works as expected. What language did the text represent? My money is on C. >> If that code is not the 100% standards-conformant C that is favoured in >> this heavily gcc/Linux-centric group, then I don't care. > Consider English as an analogy. Imagine you were posting to > human.languages.english, in a thread about grammar. People there are > trying to help a new student understand the difference between "it's" > and "its". Half the people here don't understand it either. Even if they do, people make typos. But it doesn't matter. There is such a thing as using a language informally and colloquially, and that applies to both kinds. BTW, does anyone ever use gcc without using '-Wpedantic'? If so, why?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-07 14:11 +0200 |
| Message-ID | <qnfa1e$fgv$1@dont-email.me> |
| In reply to | #146681 |
On 07/10/2019 13:18, Bart wrote: > On 07/10/2019 11:24, David Brown wrote: >> On 07/10/2019 11:59, Bart wrote: >>> On 07/10/2019 08:39, mark.bluemel@gmail.com wrote: > >>> Why gcc? Why not tcc? gcc is not the only free compiler around. >>> >>> tcc accepts '-pedantic' but will not report anything amiss with my void* >>> function pointer conversion. >> >> Does tcc's documentation say that it is conforming (modulo bugs and >> occasional missing features) when "-pedantic" is given? Or does it have >> another way to make it conforming (or as close as it can)? Does it even >> specify what C standard version it follows? If not, then it is >> irrelevant here. > > I consider tcc an important and useful compiler, especially on Linux, > and especially on slower machines such as the RPis. I assume this means you can't answer my question - and therefore any testing with tcc is irrelevant with regards to whether C code is conforming or not. (And no sane person compilers code on older RPi's - compile it on a PC, or get a Pi 3 or 4.) > > Its speed makes it a more practical way of processing the output of my > 'M' compiler, as it will complete instantly, compared to the annoying > lag you get with gcc, and for that you get -O0 code which is as slow as > tcc. Try -O3 and it will take forever. I don't care if you want to use tcc, bcc, gcc, or anything else for compiling your code. Use whatever suits your needs best. But unless you are using a compiler (and flags) that tries to be conforming, stop pretending that it can be used to tell if your C code is conforming. > >>> On Windows I primarily use my own 'bcc', which doesn't report any error >>> either. >> >> Does bcc's documentation say that it is conforming (modulo bugs and >> occasional missing features) when "-pedantic" is given? > > No. When I had documentation for it, it called itself a C-dialect > compiler. It is still a highly useful language (eg. it can compile Lua, > or tcc, or any of my compilers/interpreters). Again - use it for whatever purposes you like, that's up to you. But don't imagine it is remotely relevant for conformance checking of your code. > > As I said, I'm not interested. > > As it is, the C generated by my compiler already can only represent a > subset of my original language. So if I need a key application to go > through a C compiler, then I need to avoid certain features. Great - and irrelevant. > > If every C compiler rejected void*/fnptr conversions as errors, then > that would be yet another thing I couldn't use. But it's a key feature I > rely on, and it is very difficult to write workarounds in generated C. It is a stupid and pointless thing to rely on, completely unnecessary. But if you want to rely on it, that is up to you - generate sort-of-C if you like, and compile it with tools that are accepting of mistakes in the source code. Just stop trying to pretend it is reasonable C, and stop recommending your bad habits to others. > > I've already said that void*/fnptr pointer conversions prohibitions are > a C language artefact, since it isn't an actual hardware issue for the > machines I'm ever likely to work on. You've said that kind of thing before. Mostly it boils down to misunderstandings about what C is, how the language is defined, and why it is defined that way. But experience suggests your stubbornness far exceeds your willingness to learn, so there is no point in repeating the old lessons. > >>> When I write or generate source code that I label as 'C', it is code >>> that will be accepted by any of: >>> >>> gcc prog.c >>> tcc prog.c >>> bcc prog > >> That is not how "C" is defined. > > That's how /I/ use C. You feed those compilers some text, out comes an > executable that works as expected. What language did the text represent? > My money is on C. "When I use a word," Humpty Dumpty said, "it means just what I choose it to mean - neither more nor less." > >>> If that code is not the 100% standards-conformant C that is favoured in >>> this heavily gcc/Linux-centric group, then I don't care. > >> Consider English as an analogy. > > Imagine you were posting to >> human.languages.english, in a thread about grammar. People there are >> trying to help a new student understand the difference between "it's" >> and "its". > > Half the people here don't understand it either. Even if they do, people > make typos. But it doesn't matter. It does not matter much in a C language group - it would matter a great deal in a group dedicated to discussing the English language. If you go to a group for discussing games programming on Windows, for example, then details of the C language will not be a big issue - but this is a group for discussing C. > > There is such a thing as using a language informally and colloquially, > and that applies to both kinds. > > BTW, does anyone ever use gcc without using '-Wpedantic'? If so, why? > Do you bother reading posts anyone else makes? There is no need to answer that, as it is obvious that you don't.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-10-07 15:22 +0100 |
| Message-ID | <FSHmF.756187$bv6.594065@fx04.am4> |
| In reply to | #146684 |
On 07/10/2019 13:11, David Brown wrote: > On 07/10/2019 13:18, Bart wrote: >> I consider tcc an important and useful compiler, especially on Linux, >> and especially on slower machines such as the RPis. > > I assume this means you can't answer my question - and therefore any > testing with tcc is irrelevant with regards to whether C code is > conforming or not. > > (And no sane person compilers code on older RPi's - compile it on a PC, > or get a Pi 3 or 4.) I have an Rpi4. Tcc runs at about 300Klps on that. I think the RPi1 is about 1/4 the speed, which means tcc would compile C at some 70,000 lines per second, which is still considerably faster than gcc on my PC! Especially when using -O3 otherwise there is no point in using gcc over tcc. This is why tcc is important. (Partly why I created bcc too, but tcc does the job better and on more platforms. So I'm concentrating on my own language.) I get it: you guys are overly preoccupied with writing highly standards conformant C. And some of you are 'standards-heads' in being obsessed with the subject. Well I'm not, and I doubt it's just me. C and a C compiler are just tools to get a job done. Especially in hobby work when you can do things informally. It is just a different point of view from yours; that doesn't mean it is not valid. > I don't care if you want to use tcc, bcc, gcc, or anything else for > compiling your code. Use whatever suits your needs best. But unless > you are using a compiler (and flags) that tries to be conforming, stop > pretending that it can be used to tell if your C code is conforming. OK, it's non-conforming C code; is that better? > But experience suggests your stubbornness far > exceeds your willingness to learn, so there is no point in repeating the > old lessons. Oh, I learn all right, how to better design languages without stupid rules!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-10-07 17:17 +0200 |
| Message-ID | <qnfktl$gvl$1@dont-email.me> |
| In reply to | #146687 |
On 07/10/2019 16:22, Bart wrote: > On 07/10/2019 13:11, David Brown wrote: >> On 07/10/2019 13:18, Bart wrote: > >>> I consider tcc an important and useful compiler, especially on Linux, >>> and especially on slower machines such as the RPis. >> >> I assume this means you can't answer my question - and therefore any >> testing with tcc is irrelevant with regards to whether C code is >> conforming or not. >> >> (And no sane person compilers code on older RPi's - compile it on a PC, >> or get a Pi 3 or 4.) > > I have an Rpi4. Tcc runs at about 300Klps on that. I think the RPi1 is > about 1/4 the speed, which means tcc would compile C at some 70,000 > lines per second, which is still considerably faster than gcc on my PC! Nobody /cares/ if you can do 300 Klps compilation - especially not for compiling /your/ code. It is a meaningless figure. What people - normal programmers, that is - care about in compiler speed is that their build process is fast enough with /their/ compiler, compiling /their/ code with /their/ choice of options. If your (manually written) C files are more than a couple of thousand lines, they are probably too big for good structure anyway. > > Especially when using -O3 otherwise there is no point in using gcc over > tcc. There is rarely any point in using -O3, as the results are seldom significantly faster. But there are very many reasons why gcc is a better development tool than tcc for almost every usage. (No, I'm not going to go into detail.) > > This is why tcc is important. (Partly why I created bcc too, but tcc > does the job better and on more platforms. So I'm concentrating on my > own language.) The discussion was about checking for conforming code. Since tcc does not even pretend to be conforming, to give appropriate diagnostics, or even to pick a specific C standard, it is useless for the job. Being small and fast does not help if the tool fails to do the job you want. > > I get it: you guys are overly preoccupied with writing highly standards > conformant C. And some of you are 'standards-heads' in being obsessed > with the subject. > > Well I'm not, and I doubt it's just me. C and a C compiler are just > tools to get a job done. Especially in hobby work when you can do things > informally. > > It is just a different point of view from yours; that doesn't mean it is > not valid. Again, you haven't bothered reading my posts, have you? You haven't even bothered learning the aims of the C language. It is specifically designed so that you can use it for highly portable code (by writing conforming code and sticking to standards-defined code as much as possible), /and/ for writing systems-specific code (taking advantage of whatever you want or need from the compiler or target implementation). And as I have written, several times, the code /I/ write is usually implementation specific, non-standard, and uses extensions from whatever compiler I use. But when I write code that is non-standard, non-conforming, non-portable, I don't claim it is valid standard C just because it worked for me. And I don't write it that way because I don't understand C, or because I think C should be defined differently - I write it that way when it has a noticeable advantage (or necessity). > >> I don't care if you want to use tcc, bcc, gcc, or anything else for >> compiling your code. Use whatever suits your needs best. But unless >> you are using a compiler (and flags) that tries to be conforming, stop >> pretending that it can be used to tell if your C code is conforming. > > OK, it's non-conforming C code; is that better? Certainly. > >> But experience suggests your stubbornness far >> exceeds your willingness to learn, so there is no point in repeating the >> old lessons. > > Oh, I learn all right, how to better design languages without stupid rules! > As I say - your stubbornness significantly exceeds your willingness to learn.
[toc] | [prev] | [next] | [standalone]
Page 17 of 25 — ← Prev page 1 … 15 16 [17] 18 19 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web