Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #142080 > unrolled thread
| Started by | Howard Chu <highlandsun@gmail.com> |
|---|---|
| First post | 2019-03-19 14:58 -0700 |
| Last post | 2019-04-16 11:13 -0700 |
| Articles | 20 on this page of 276 — 21 participants |
Back to article view | Back to comp.lang.c
C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-19 14:58 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-19 15:58 -0700
Re: C wish list Wouter Verhelst <w@uter.be> - 2019-03-20 08:27 +0200
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-20 06:54 +0000
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-20 07:00 +0000
Re: C wish list Wouter Verhelst <w@uter.be> - 2019-03-20 13:26 +0200
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 08:17 -0400
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 13:20 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 01:43 -0700
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-03-20 13:11 +0000
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 09:17 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 09:34 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 10:06 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 10:47 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-20 17:59 +0000
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 11:12 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 13:47 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 11:46 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-20 19:21 +0000
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 12:31 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 12:41 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 14:34 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 13:52 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 11:04 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 13:43 -0700
C wish list fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 16:57 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-20 05:45 +0000
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 09:22 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 14:02 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-20 22:55 +0100
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 15:15 -0700
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-20 23:56 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 17:52 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 11:08 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-20 22:54 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-20 22:22 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 15:29 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-21 14:47 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 22:26 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-21 22:18 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 09:28 +0100
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-21 18:00 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-21 18:57 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 22:32 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-21 22:11 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 11:30 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-22 11:39 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 14:26 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-22 14:40 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 16:10 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-22 16:05 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-22 11:54 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-22 19:19 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-22 12:29 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-22 19:36 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-22 13:54 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 13:33 +0000
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-23 14:46 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 15:00 +0000
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-23 15:24 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 18:23 +0000
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-23 22:40 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 22:59 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 16:24 -0700
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-24 01:57 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 11:14 +0000
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-24 14:01 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 16:11 +0100
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-25 07:34 -0700
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-25 17:11 +0000
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-23 11:41 -0400
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-23 19:52 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 22:30 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 16:07 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 16:42 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 16:12 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-24 17:59 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 22:19 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 22:13 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 01:27 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-23 16:51 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 18:34 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 16:48 +0100
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 13:51 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 17:05 +0100
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 12:41 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 22:55 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 16:20 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 23:40 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 18:35 -0700
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-23 20:19 -0400
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 12:06 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 17:41 +0100
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-24 22:42 -0400
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-24 20:21 -0700
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-25 07:53 -0400
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 11:22 -0700
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-26 23:28 -0400
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-27 07:49 -0400
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-10 08:35 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-10 09:18 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 17:23 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 16:51 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-24 16:38 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 01:32 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-25 00:51 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-24 17:57 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-25 01:05 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-24 18:35 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-25 06:19 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-24 18:51 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 19:08 +0000
Re: C wish list Ike Naar <ike@sdf.lonestar.org> - 2019-03-24 19:36 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 19:45 +0000
Re: C wish list Ike Naar <ike@sdf.lonestar.org> - 2019-03-24 19:49 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 20:10 +0000
Re: C wish list Ike Naar <ike@sdf.lonestar.org> - 2019-03-25 06:43 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-25 11:17 +0000
Re: C wish list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-25 06:22 -0700
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-25 17:01 +0000
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-25 00:44 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 17:09 +0100
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-24 16:12 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-23 13:47 +0100
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-23 14:24 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-23 17:18 +0100
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-23 17:53 +0000
On "high-levelness" of languages (was "C wish list") Spiros Bousbouras <spibou@gmail.com> - 2019-03-24 00:23 +0000
Re: On "high-levelness" of languages (was "C wish list") Keith Thompson <kst-u@mib.org> - 2019-03-23 18:37 -0700
Re: On "high-levelness" of languages (was "C wish list") David Brown <david.brown@hesbynett.no> - 2019-03-24 22:22 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 21:58 +0100
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-25 01:12 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 09:48 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 14:25 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-23 18:06 +0100
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-03-23 17:59 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-22 11:46 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-22 19:59 +0000
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-22 20:30 -0700
Re: C wish list Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-25 22:33 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-23 18:12 +0100
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-23 13:00 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 22:27 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 23:34 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-24 17:43 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 19:44 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 22:55 +0100
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-24 20:37 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-24 21:54 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-25 06:11 +0000
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-25 07:59 -0400
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 14:26 +0100
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-25 15:59 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 22:04 +0100
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 14:54 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-25 22:35 +0000
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 21:41 -0400
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-26 09:44 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-26 09:42 +0100
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-10 08:32 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-25 12:53 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 13:20 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-25 13:40 -0700
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-26 07:28 -0400
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-26 09:42 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-26 13:08 -0400
Re: C wish list Ian Collins <ian-news@hotmail.com> - 2019-03-27 08:57 +1300
Re: C wish list Richard Damon <Richard@Damon-Family.org> - 2019-03-26 22:53 -0400
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-27 10:27 +0100
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-28 08:04 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-28 09:03 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-28 16:26 +0000
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-28 13:02 -0700
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-09 04:25 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-09 07:03 -0700
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-04-09 14:31 +0000
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-10 08:27 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-25 13:05 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-25 06:06 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 09:39 +0100
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 21:26 -0400
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-26 09:55 +0100
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-26 08:57 -0400
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-26 15:22 +0000
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-26 13:10 -0400
Re: C wish list Bart <bc@freeuk.com> - 2019-03-25 19:08 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-25 22:24 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-25 22:08 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-26 10:20 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-26 11:58 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-26 16:49 +0100
Re: C wish list Bart <bc@freeuk.com> - 2019-03-26 16:23 +0000
Re: C wish list Lowell Gilbert <lgusenet@be-well.ilk.org> - 2019-03-26 13:24 -0400
Re: C wish list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-26 10:31 -0700
Re: C wish list Robert Wessel <robertwessel2@yahoo.com> - 2019-03-26 13:03 -0500
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-26 11:53 -0700
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-03-26 19:59 +0000
Re: C wish list Ian Collins <ian-news@hotmail.com> - 2019-03-27 09:24 +1300
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-03-26 20:54 +0000
Re: C wish list Ian Collins <ian-news@hotmail.com> - 2019-03-27 09:58 +1300
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-26 13:43 -0700
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-26 22:49 +0000
Re: C wish list Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-27 21:02 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-28 18:04 +0000
Re: C wish list Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-28 19:53 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-26 18:25 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-26 14:47 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-26 18:14 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-26 22:31 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-27 00:08 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-28 18:45 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-21 15:13 -0700
Re: C wish list Bart <bc@freeuk.com> - 2019-03-21 22:29 +0000
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 23:51 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 11:37 +0100
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-22 07:54 -0400
Re: C wish list Bart <bc@freeuk.com> - 2019-03-22 13:15 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 14:31 +0100
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-21 22:55 -0700
Re: C wish list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-22 07:17 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 16:16 +0100
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-22 12:06 -0700
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-23 16:59 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-23 21:36 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-24 16:16 +0000
Re: C wish list Bart <bc@freeuk.com> - 2019-03-24 20:25 +0000
Re: C wish list antispam@math.uni.wroc.pl - 2019-03-25 20:00 +0000
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-24 21:56 +0000
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-21 22:39 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-20 06:10 +0000
Re: C wish list Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-20 06:57 +0000
Re: C wish list Philipp Klaus Krause <pkk@spth.de> - 2019-03-20 11:06 +0100
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 09:24 -0700
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 13:15 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 15:38 +0100
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-21 09:17 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-21 09:58 -0700
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-03-21 17:22 +0000
Re: C wish list Robert Wessel <robertwessel2@yahoo.com> - 2019-03-21 23:44 -0500
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-21 12:43 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-20 16:53 +0100
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 09:30 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-20 22:58 +0100
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-20 15:41 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-20 20:12 -0400
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 16:00 +0100
Re: C wish list Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-21 08:10 -0700
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 22:35 +0100
Re: C wish list jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-22 10:32 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-22 12:25 +0100
Re: C wish list jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-22 18:15 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-24 15:29 +0100
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-24 22:03 +0000
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-21 10:43 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-21 15:09 -0400
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-21 12:45 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-21 10:53 -0700
Re: C wish list James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-21 15:18 -0400
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-21 12:55 -0700
Re: C wish list Spiros Bousbouras <spibou@gmail.com> - 2019-03-21 19:55 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-20 13:29 -0700
Re: C wish list scott@slp53.sl.home (Scott Lurndal) - 2019-03-20 21:12 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-20 23:02 +0100
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-20 20:32 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-20 23:08 +0100
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 00:25 +0000
Re: C wish list Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-21 07:12 +0000
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 16:13 +0100
Re: C wish list David Brown <david.brown@hesbynett.no> - 2019-03-21 16:11 +0100
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 17:04 +0000
Re: C wish list Keith Thompson <kst-u@mib.org> - 2019-03-21 13:02 -0700
Re: C wish list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 22:03 +0000
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 07:25 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-03-23 11:38 -0700
Re: C wish list Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-25 07:59 -0700
Re: C wish list Howard Chu <highlandsun@gmail.com> - 2019-04-16 11:13 -0700
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-25 00:44 +0000 |
| Message-ID | <878sx3pyue.fsf@bsb.me.uk> |
| In reply to | #142365 |
Bart <bc@freeuk.com> writes: <cut> > I gave a list in another post - it seems Java, D, Go and Rust wrap. In Rust integer arithmetic does not wrap, but it may do. If you need it, there is a type whose arithmetic /is/ defined to wrap. Go does not, technically, mandate wrapping either, but it near as damn does. It mandates that the result is "deterministically defined by the signed integer representation, the operation, and its operands". I take that to mean it wraps on 2's complement systems but might do something else (which I'd have to think about) with other representations. Other languages take a third route. For example in Haskell the usual integer arithmetic is defined to neither wrap not overflow. Wrapping fixed-width types are provided as modules. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 17:09 +0100 |
| Message-ID | <q78a3p$fin$1@dont-email.me> |
| In reply to | #142309 |
On 23/03/2019 20:41, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: <snip> > Note that said he was confused by the syntax you used, > "<some expression involving x, such as x>>8>". I parsed that as: <some expression involving x, such as x> >8> which I could not interpret. A bit of spacing or quotation marks would have helped.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-24 16:12 -0700 |
| Message-ID | <lnmuljdfzy.fsf@kst-u.example.com> |
| In reply to | #142354 |
David Brown <david.brown@hesbynett.no> writes:
> On 23/03/2019 20:41, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>> Note that said he was confused by the syntax you used,
>> "<some expression involving x, such as x>>8>".
>
> I parsed that as:
>
> <some expression involving x, such as x> >8>
>
> which I could not interpret.
>
> A bit of spacing or quotation marks would have helped.
So any conclusions Bart drew based on your response to that (which
constitute a large proportion of this thread) are unfounded.
I parsed it (and I'm reasonably sure Bart meant it -- Bart, please
correct me if I'm mistaken) as:
<
some expression involving x,
such as
x>>8
>
Bart moved the goalposts. You had been discussing code using left
shift, which may have undefined behavior. Bart presented (unclearly)
an example involving right shift, which never has undefined behavior
(unless the behavior was already defined for other reasons).
Again, if Bart wants to continue discussing this, he needs to present
clear examples without pseudocode and with any assumptions clearly
stated.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-23 13:47 +0100 |
| Message-ID | <q759ts$9bf$1@dont-email.me> |
| In reply to | #142244 |
On 22/03/2019 17:05, Bart wrote:
> On 22/03/2019 15:10, David Brown wrote:
>> On 22/03/2019 15:40, Bart wrote:
>
>>> So what language is? (I don't count HLAs here.)
>>
>> What is the next language sideways from Lisp?
>>
>> It's a meaningless question.
>
> Is C higher or lower level than Python? That's easy to answer. In that
> case it shouldn't be hard to find a language X which is higher level
> than ASM, and lower level than X, and that is portable.
C is lower level than Python - few would argue about that. That tells
us /nothing/ about whether there is a language between C and assembly.
Perhaps you imagine there is a way of generating a single number for a
language, it's "level". In your mind, assembly has level 1, C has level
3, Python has level 20, and your own language has level 8 (picking
numbers out the air here). You think therefore that we could allocate
such numbers to all languages, put them all on a nice, neat ordered
list, and then see what language X is.
That is, of course, total nonsense. There is no such "level number".
There are features of languages that can be considered "higher level" or
"lower level", and different languages have wildly different mixtures of
such features. There are things that are used in "lower level"
programming, and things that are used in "higher level" programming -
but the levels and comparisons are all highly subjective.
Your question is as meaningless as asking for the next step on the way
from pizza to steak and chips.
(I've seen people struggle with such concepts in many areas. People
like to be able to place things in a nice, clean, ordered line - but it
is rarely realistic.)
>
> But if X is elusive, then it might well be that C is the X I'm looking
> for. In other words, the next one up from ASM. The one you said 'Nope'
> too (and which made thing think, you seeming so certain, that you knew
> of one for which you'd say 'Yep').)
>
>
>>>> The example he gave was:
>>>>
>>>> int x = 1 << 31;
>>>> int y = x / 5;
>
>> The point is, you are not loading a 32-bit signed int value -0x80000000
>> into a 64-bit register. You are loading a 32-bit signed int value 1
>> into the 64-bit register, then shifting it 31 bits left, then dividing
>> it by 5.
>>
>> At no point does C require an intermediary value of -0x80000000.
>
> I don't believe this. Or it is you not understanding how C has to work.
I think we can agree quite solidly that we have /different/
understandings of how C works. We merely disagree on which is the
correct understanding, and who is wrong.
I am correct - you are wrong. I have the C standards on my side, you do
not.
>
> You are saying that here:
>
> int32_t x = f();
> int32_t y = <some expression involving x, such as x>>8>
>
> it is acceptable to use a 64-bit version of x, even though x is only 32
> bits, because it's using a value left over in a 64-bit register from
> some immediately prior calculation of x.
Ignoring your somewhat jumbled syntax (I can't figure out if it is
supposed to be a smiley, or what it is), then yes.
There are two general principles here, and I think you fail to
appreciate either of them.
First, with fully defined code, the compiler can do whatever it wants as
long as the final "observable behaviour" matches what you would get on
the "C abstract machine". Intermediary calculations can do anything, in
any way, using any sizes or instructions, as long as the results are
correct.
Secondly, when there is undefined behaviour, the compiler can do
anything it wants. /Anything/.
Generally, assuming a sane compiler, what this means is the compiler
will take the shortest path - it will give the fastest, smallest, most
efficient code it can while ignoring the possibility that undefined
behaviour could occur.
If you write:
int foo(int x, int y) {
int a = x * x + 1;
int b = a << y;
if (b > 0) return 1;
if (b < 0) return -1;
return 0;
}
the compiler can assume first that "x * x" does not overflow, so the
result is non-negative. Adding 1 cannot overflow, so "a" is strictly
positive. "a << y" cannot overflow, so "b" is strictly positive. Thus
the whole function reduces to "return 1;".
At no point need it calculate any intermediary results.
And in a case like this, the fact that choosing 32-bit or 64-bit
registers and operations only makes a difference when there is undefined
behaviour, means that the compiler can choose whichever sizes it wants
for code speed and efficiency. If a cpu can do the 64-bit operations
faster or with smaller code, then that is the code the compiler should
generate.
>
> If that is actually what C allows, then it is even crazier than I'd
> already thought, and that is saying something.
>
> If you are saying that that is only allowed because of UB, then that
> does little to change my opinion. It is certainly more crazy stuff that
> the OP is complaining about.
You have been told repeatedly that C is not the language you think, and
does not work the way you think. I believe that if you learned to read
and think, and appreciate that other people are trying to help you
understand C, then you could get a handle on it. Whether you then like
or dislike C as it really is, is a different matter - but at least you
have a chance to learn to like it, or learn to use it properly. As long
as you keep trying to force your misconceptions on it, you will not like
the language, you will hate the tools, and you will get things wrong.
>
>> Tell me, what results did you get when you tried this on a DEC Alpha?
>> Or when you say, "all the C compilers I've tried", do you mean a few
>> mainstream C x86 compilers, and a few x86
>> toy/experimental/limited/partial C compilers ?
>
> I tried some C and C++ compilers on rextester.com. I don't know what
> hardware they ran on, but they all gave the same results as on my PC.
It is a dotnet online compiler - it runs on x86-64. That took all of 3
seconds to find out.
>
> I also tried it on my new language which is all 64-bit, uses 64-bit
> registers, and promotes narrower types to 64-bits (my current one
> doesn't promote).
What bit of "x86" do you find hard to comprehend?
And why would you possibly consider a test on /your/ tools to be
relevant? They are written by someone who doesn't understand C, for a
different language, on a processor where it is more efficient to
generate code that does the calculations as 32-bit.
Your tests don't strengthen your argument - they strengthen the image
that you don't know what you are talking about.
>
> It still gave the same results, because the x in 'x/5' MUST be a 32-bit
> quantity, since x has a 32-bit type. However, if I define y like this:
>
> int32 y:=(1<<31)/5
>
> then it will give the other result (a positive value), because (1<<31)
> is representable as 64 bits, and calculations are done as 64 bits.
>
> So, you say the C compiler on DEC Alpha will give a nonsensical result?
$DIETY only knows what results you would get for /your/ language. But
for C, a compiler can happily use 64-bit calculations in this case - and
I /think/ that on a DEC Alpha, that would give more efficient code.
A compiler is only required to generate sensible results from sensible
inputs - if your inputs are not in the ranges defined by the language,
then there is /no/ sensible output, and the compiler can do what it
wants. "Garbage in, garbage out" has been established principle since
Babbage's day.
"""
On two occasions I have been asked, "pray, Mr. Babbage, if you put into
the machine wrong figures, will the right answers come out? I am not
able rightly to apprehend the kind of confusion of ideas that could
provoke such a question.
"""
> That's something to stay clear of then, rather than it putting forward
> as some sort of bizarre argument for C being superior because of its UB.
> All I see is a bug.
>
That's because you are looking in the mirror.
No one is asking you to /like/ the way C handles integer overflow and
other kinds of undefined behaviour. I am merely asking you to
/understand/ it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-23 14:24 +0000 |
| Message-ID | <877ecpu0sd.fsf@bsb.me.uk> |
| In reply to | #142278 |
David Brown <david.brown@hesbynett.no> writes: > On 22/03/2019 17:05, Bart wrote: >> On 22/03/2019 15:10, David Brown wrote: >>> On 22/03/2019 15:40, Bart wrote: >> >>>> So what language is? (I don't count HLAs here.) >>> >>> What is the next language sideways from Lisp? >>> >>> It's a meaningless question. >> >> Is C higher or lower level than Python? That's easy to answer. In >> that case it shouldn't be hard to find a language X which is higher >> level than ASM, and lower level than X, and that is portable. BCPL? > C is lower level than Python - few would argue about that. That tells > us /nothing/ about whether there is a language between C and assembly. True, but he's asking if there is one. If you think not, you might as well say so. Given what you say here: > Perhaps you imagine there is a way of generating a single number for a > language, it's "level". In your mind, assembly has level 1, C has > level 3, Python has level 20, and your own language has level 8 > (picking numbers out the air here). You think therefore that we could > allocate such numbers to all languages, put them all on a nice, neat > ordered list, and then see what language X is. > > That is, of course, total nonsense. There is no such "level > number". There are features of languages that can be considered > "higher level" or "lower level", and different languages have wildly > different mixtures of such features. There are things that are used > in "lower level" programming, and things that are used in "higher > level" programming - but the levels and comparisons are all highly > subjective. > > Your question is as meaningless as asking for the next step on the way > from pizza to steak and chips. it seems that you simply reject the whole idea. Are you really one of the few who would reject the claim that C is lower level than Python or maybe even Haskell? I agree that it's all a bit subjective and vague, and certainly not always linear, but would you really /not/ be prepared to say that BCPL is lower-level than C? Would you really /not/ be prepared to say that a relatively portable language like BCPL is higher-level than assembler? I'd stand by both statements if I had to. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-23 17:18 +0100 |
| Message-ID | <q75m7r$fk2$1@dont-email.me> |
| In reply to | #142283 |
On 23/03/2019 15:24, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 22/03/2019 17:05, Bart wrote: >>> On 22/03/2019 15:10, David Brown wrote: >>>> On 22/03/2019 15:40, Bart wrote: >>> >>>>> So what language is? (I don't count HLAs here.) >>>> >>>> What is the next language sideways from Lisp? >>>> >>>> It's a meaningless question. >>> >>> Is C higher or lower level than Python? That's easy to answer. In >>> that case it shouldn't be hard to find a language X which is higher >>> level than ASM, and lower level than X, and that is portable. > > BCPL? > >> C is lower level than Python - few would argue about that. That tells >> us /nothing/ about whether there is a language between C and assembly. > > True, but he's asking if there is one. If you think not, you might as > well say so. Given what you say here: Do I think there is a language between assembly and C in some vague "level" sense? As I have said, I think the question is meaningless, but even if I attempt to answer it, I still don't know. In some ways, Forth might be a candidate, and is certainly used for low-level systems. Ada is used for bare-metal and low-level programming, and can get very close to the machine - but it also supports much higher level programming. There are some older languages, like BCPL, that are viewed as low level. Even Java is used for low-level work sometimes (and it has defined behaviour for integer overflow). Newer languages like Rust can be used. And there are plenty of specialist tools and languages that are somewhat like assembly with a "nicer" syntax and some higher level features. (You can often get to a "higher level" just with a good macro assembler.) Certainly the answer to the question "what language is most used for low level programming, excluding assembly?" is C. If that were the question, then there is no language X. But that was not the question. > >> Perhaps you imagine there is a way of generating a single number for a >> language, it's "level". In your mind, assembly has level 1, C has >> level 3, Python has level 20, and your own language has level 8 >> (picking numbers out the air here). You think therefore that we could >> allocate such numbers to all languages, put them all on a nice, neat >> ordered list, and then see what language X is. >> >> That is, of course, total nonsense. There is no such "level >> number". There are features of languages that can be considered >> "higher level" or "lower level", and different languages have wildly >> different mixtures of such features. There are things that are used >> in "lower level" programming, and things that are used in "higher >> level" programming - but the levels and comparisons are all highly >> subjective. >> >> Your question is as meaningless as asking for the next step on the way >> from pizza to steak and chips. > > it seems that you simply reject the whole idea. Are you really one of > the few who would reject the claim that C is lower level than Python or > maybe even Haskell? > > I agree that it's all a bit subjective and vague, and certainly not > always linear, but would you really /not/ be prepared to say that BCPL > is lower-level than C? Would you really /not/ be prepared to say that a > relatively portable language like BCPL is higher-level than assembler? > I'd stand by both statements if I had to. > I don't know BCPL except vaguely as an ancestor of C, so I can't comment on it. I am happy to say that Python and Haskell are higher level languages than C. But how would you compare Prolog and Haskell? C# and Java? Occam and Go? How would you make a "language level" scale that let you compare VHDL and Javascript? The issue is not just a "bit" subjective and vague, it is /totally/ subjective and vague, and depends entirely on how you use the languages and what you use them for. We can agree that the great majority of programmers would - subjectively - rate Python as far higher level than C. That gives us grounds for saying that /objectively/ it is a higher level language. We can also pick certain features - such as automatic memory handling or language support for lists and hash-maps, and call these "high level features". A language with more high level features gets a higher score. Again, this gives us an objective method of getting a partial rating (though the feature choices, and their weightings, are still subjective). And again, there is no doubt about a comparison for Python verses C. But it all breaks down when you try to compare closer languages. These subjective methods are no longer good enough for nuances. And it breaks down for languages that span a wide range of uses, like C++. That is why I say it is meaningless to talk about a language that is lower level than C but higher level than assembly. Assembly itself is different, of course - being defined in terms of the hardware, rather than by language specifications and an abstract execution system, it stands out as clearly lower than other languages where you have the abstraction.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-23 17:53 +0000 |
| Message-ID | <87pnqhscjc.fsf@bsb.me.uk> |
| In reply to | #142292 |
David Brown <david.brown@hesbynett.no> writes: > On 23/03/2019 15:24, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 22/03/2019 17:05, Bart wrote: >>>> On 22/03/2019 15:10, David Brown wrote: >>>>> On 22/03/2019 15:40, Bart wrote: >>>> >>>>>> So what language is? (I don't count HLAs here.) >>>>> >>>>> What is the next language sideways from Lisp? >>>>> >>>>> It's a meaningless question. >>>> >>>> Is C higher or lower level than Python? That's easy to answer. In >>>> that case it shouldn't be hard to find a language X which is higher >>>> level than ASM, and lower level than X, and that is portable. >> >> BCPL? (I'm assuming the X was a typo.) >>> C is lower level than Python - few would argue about that. That tells >>> us /nothing/ about whether there is a language between C and assembly. >> >> True, but he's asking if there is one. If you think not, you might as >> well say so. Given what you say here: > > Do I think there is a language between assembly and C in some vague > "level" sense? > > As I have said, I think the question is meaningless, but even if I > attempt to answer it, I still don't know. I don't really get how the question is meaningless yet you will entertain some examples of related questions. Is it specifically to do with C and these as yet unknown candidate languages that the question is meaningless? > In some ways, Forth might be a candidate, and is certainly used for > low-level systems. Why would you not say that it fits the bill? Do you think a case can be made that Forth is as high-level a language as C? I don't think I could make that case, though there may be a "modern Forth" that is way more capable than the Forth I remember from the 80s. <cut> > I don't know BCPL except vaguely as an ancestor of C, so I can't > comment on it. I am happy to say that Python and Haskell are higher > level languages than C. I submit that BCPL is an answer to Bart's question. > But how would you compare Prolog and Haskell? C# and Java? Occam and > Go? I'd say that Haskell is higher-level than Prolog, that C# and Java are on about the same level, and that Go is higher-level than Occam. Obviously you'd probably like to know why, but that might be too off-topic for here. > How would you make a "language level" scale that let you compare VHDL > and Javascript? I wouldn't. Relations like "is higher-level than" need not be total. > The issue is not just a "bit" subjective and vague, it is /totally/ > subjective and vague, and depends entirely on how you use the > languages and what you use them for. > > We can agree that the great majority of programmers would - > subjectively - rate Python as far higher level than C. That gives us > grounds for saying that /objectively/ it is a higher level language. > > We can also pick certain features - such as automatic memory handling > or language support for lists and hash-maps, and call these "high > level features". A language with more high level features gets a > higher score. Again, this gives us an objective method of getting a > partial rating (though the feature choices, and their weightings, are > still subjective). And again, there is no doubt about a comparison > for Python verses C. > > But it all breaks down when you try to compare closer languages. > These subjective methods are no longer good enough for nuances. And > it breaks down for languages that span a wide range of uses, like C++. > That is why I say it is meaningless to talk about a language that is > lower level than C but higher level than assembly. I don't think BCPL and C are in either the "too close to call" category nor the "too different to compare" category. > Assembly itself is different, of course - being defined in terms of > the hardware, rather than by language specifications and an abstract > execution system, it stands out as clearly lower than other languages > where you have the abstraction. Just about. Some assemblers do have mechanisms for building abstractions though so even that's a bit grey, but I doubt even the most sophisticated assembler can be said to have abstractions as high as some of the very lowest-level languages. So, yes, I agree here. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-24 00:23 +0000 |
| Subject | On "high-levelness" of languages (was "C wish list") |
| Message-ID | <AdfBdz5pbHcBscNMHR0FFjXOarp0b@bongo-ra.co> |
| In reply to | #142301 |
On Sat, 23 Mar 2019 17:53:11 +0000 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > David Brown <david.brown@hesbynett.no> writes: > > > On 23/03/2019 15:24, Ben Bacarisse wrote: > >> David Brown <david.brown@hesbynett.no> writes: > >> > >>> On 22/03/2019 17:05, Bart wrote: > >>>> On 22/03/2019 15:10, David Brown wrote: > >>>>> On 22/03/2019 15:40, Bart wrote: > >>>> > >>>>>> So what language is? (I don't count HLAs here.) > >>>>> > >>>>> What is the next language sideways from Lisp? > >>>>> > >>>>> It's a meaningless question. > >>>> > >>>> Is C higher or lower level than Python? That's easy to answer. In > >>>> that case it shouldn't be hard to find a language X which is higher > >>>> level than ASM, and lower level than X, and that is portable. > >> > >> BCPL? > > (I'm assuming the X was a typo.) It doesn't seem like a typo to me. [...] > I don't really get how the question is meaningless yet you will > entertain some examples of related questions. Is it specifically to do > with C and these as yet unknown candidate languages that the question is > meaningless? Some questions are hopelessly meaningless whereas with others one feels that with enough effort one might arrive at a precise meaning. To me the "high-levelness" of languages belongs in the latter category. But I don't see any point in expending the time and effort to arrive at a precise meaning because I've never seen the concept being used for anything other than bragging rights online. > I'd say that Haskell is higher-level than Prolog, that C# and Java are > on about the same level, and that Go is higher-level than Occam. > Obviously you'd probably like to know why, but that might be too > off-topic for here. It would be less off-topic on comp.programming and it would be good not having the troll's posts dominate that newsgroup.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 18:37 -0700 |
| Subject | Re: On "high-levelness" of languages (was "C wish list") |
| Message-ID | <lnr2axcash.fsf@kst-u.example.com> |
| In reply to | #142327 |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Sat, 23 Mar 2019 17:53:11 +0000
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> > On 23/03/2019 15:24, Ben Bacarisse wrote:
>> >> David Brown <david.brown@hesbynett.no> writes:
>> >>> On 22/03/2019 17:05, Bart wrote:
[...]
>> >>>> Is C higher or lower level than Python? That's easy to answer. In
>> >>>> that case it shouldn't be hard to find a language X which is higher
>> >>>> level than ASM, and lower level than X, and that is portable.
>> >>
>> >> BCPL?
>>
>> (I'm assuming the X was a typo.)
>
> It doesn't seem like a typo to me.
"... and lower level than X" should have been "... and lower level
than C".
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 22:22 +0100 |
| Subject | Re: On "high-levelness" of languages (was "C wish list") |
| Message-ID | <q78sdv$58i$2@dont-email.me> |
| In reply to | #142329 |
On 24/03/2019 02:37, Keith Thompson wrote: > Spiros Bousbouras <spibou@gmail.com> writes: >> On Sat, 23 Mar 2019 17:53:11 +0000 >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 23/03/2019 15:24, Ben Bacarisse wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> On 22/03/2019 17:05, Bart wrote: > [...] >>>>>>> Is C higher or lower level than Python? That's easy to answer. In >>>>>>> that case it shouldn't be hard to find a language X which is higher >>>>>>> level than ASM, and lower level than X, and that is portable. >>>>> >>>>> BCPL? >>> >>> (I'm assuming the X was a typo.) >> >> It doesn't seem like a typo to me. > > "... and lower level than X" should have been "... and lower level > than C". > Yes. The first X was not a typo, but the second one was.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 21:58 +0100 |
| Message-ID | <q78r20$t6f$1@dont-email.me> |
| In reply to | #142301 |
On 23/03/2019 18:53, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 23/03/2019 15:24, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 22/03/2019 17:05, Bart wrote: >>>>> On 22/03/2019 15:10, David Brown wrote: >>>>>> On 22/03/2019 15:40, Bart wrote: >>>>> >>>>>>> So what language is? (I don't count HLAs here.) >>>>>> >>>>>> What is the next language sideways from Lisp? >>>>>> >>>>>> It's a meaningless question. >>>>> >>>>> Is C higher or lower level than Python? That's easy to answer. In >>>>> that case it shouldn't be hard to find a language X which is higher >>>>> level than ASM, and lower level than X, and that is portable. >>> >>> BCPL? > > (I'm assuming the X was a typo.) Yes. > >>>> C is lower level than Python - few would argue about that. That tells >>>> us /nothing/ about whether there is a language between C and assembly. >>> >>> True, but he's asking if there is one. If you think not, you might as >>> well say so. Given what you say here: >> >> Do I think there is a language between assembly and C in some vague >> "level" sense? >> >> As I have said, I think the question is meaningless, but even if I >> attempt to answer it, I still don't know. > > I don't really get how the question is meaningless yet you will > entertain some examples of related questions. Is it specifically to do > with C and these as yet unknown candidate languages that the question is > meaningless? I just don't think you can rank languages in a scale like this. It is no more complicated than that. > >> In some ways, Forth might be a candidate, and is certainly used for >> low-level systems. > > Why would you not say that it fits the bill? Do you think a case can be > made that Forth is as high-level a language as C? I don't think I could > make that case, though there may be a "modern Forth" that is way more > capable than the Forth I remember from the 80s. Forth is certainly very low level, and used for low level tasks. But it is defined in terms of a virtual machine, and in many cases /run/ on a virtual machine, which I think changes things a bit. > > <cut> >> I don't know BCPL except vaguely as an ancestor of C, so I can't >> comment on it. I am happy to say that Python and Haskell are higher >> level languages than C. > > I submit that BCPL is an answer to Bart's question. Fair enough. It is, however, a dead language - that may mean it is not what Bart is looking for. > >> But how would you compare Prolog and Haskell? C# and Java? Occam and >> Go? > > I'd say that Haskell is higher-level than Prolog, that C# and Java are > on about the same level, and that Go is higher-level than Occam. > Obviously you'd probably like to know why, but that might be too > off-topic for here. It would be getting side-tracked, yes. But can you at least see what I mean about it being difficult in many cases to give a reasonable ordering? And would you agree that there is nothing to say that there aren't other languages around, making it unreasonable to say that /this/ particular language is /the/ language that fits between these other two languages? > >> How would you make a "language level" scale that let you compare VHDL >> and Javascript? > > I wouldn't. Relations like "is higher-level than" need not be total. Agreed. I think I would go further and say it is so far from total that it is not helpful when comparing languages that are reasonably close. > >> The issue is not just a "bit" subjective and vague, it is /totally/ >> subjective and vague, and depends entirely on how you use the >> languages and what you use them for. >> >> We can agree that the great majority of programmers would - >> subjectively - rate Python as far higher level than C. That gives us >> grounds for saying that /objectively/ it is a higher level language. >> >> We can also pick certain features - such as automatic memory handling >> or language support for lists and hash-maps, and call these "high >> level features". A language with more high level features gets a >> higher score. Again, this gives us an objective method of getting a >> partial rating (though the feature choices, and their weightings, are >> still subjective). And again, there is no doubt about a comparison >> for Python verses C. >> >> But it all breaks down when you try to compare closer languages. >> These subjective methods are no longer good enough for nuances. And >> it breaks down for languages that span a wide range of uses, like C++. >> That is why I say it is meaningless to talk about a language that is >> lower level than C but higher level than assembly. > > I don't think BCPL and C are in either the "too close to call" category > nor the "too different to compare" category. Again, I don't know BCPL, so I can't comment. > >> Assembly itself is different, of course - being defined in terms of >> the hardware, rather than by language specifications and an abstract >> execution system, it stands out as clearly lower than other languages >> where you have the abstraction. > > Just about. Some assemblers do have mechanisms for building > abstractions though so even that's a bit grey, but I doubt even the most > sophisticated assembler can be said to have abstractions as high as some > of the very lowest-level languages. So, yes, I agree here. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-25 01:12 +0000 |
| Message-ID | <8736nbpxju.fsf@bsb.me.uk> |
| In reply to | #142372 |
David Brown <david.brown@hesbynett.no> writes: > On 23/03/2019 18:53, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 23/03/2019 15:24, Ben Bacarisse wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> On 22/03/2019 17:05, Bart wrote: >>>>>> On 22/03/2019 15:10, David Brown wrote: >>>>>>> On 22/03/2019 15:40, Bart wrote: >>>>>> >>>>>>>> So what language is? (I don't count HLAs here.) >>>>>>> >>>>>>> What is the next language sideways from Lisp? >>>>>>> >>>>>>> It's a meaningless question. >>>>>> >>>>>> Is C higher or lower level than Python? That's easy to answer. In >>>>>> that case it shouldn't be hard to find a language X which is higher >>>>>> level than ASM, and lower level than X, and that is portable. >>>> >>>> BCPL? >> >> (I'm assuming the X was a typo.) > > Yes. > >> >>>>> C is lower level than Python - few would argue about that. That tells >>>>> us /nothing/ about whether there is a language between C and assembly. >>>> >>>> True, but he's asking if there is one. If you think not, you might as >>>> well say so. Given what you say here: >>> >>> Do I think there is a language between assembly and C in some vague >>> "level" sense? >>> >>> As I have said, I think the question is meaningless, but even if I >>> attempt to answer it, I still don't know. >> >> I don't really get how the question is meaningless yet you will >> entertain some examples of related questions. Is it specifically to do >> with C and these as yet unknown candidate languages that the question is >> meaningless? > > I just don't think you can rank languages in a scale like this. It is > no more complicated than that. Yes, I get that. The bit I don't get is your willingness to rank languages like this when you say you can't. >>> In some ways, Forth might be a candidate, and is certainly used for >>> low-level systems. >> >> Why would you not say that it fits the bill? Do you think a case can be >> made that Forth is as high-level a language as C? I don't think I could >> make that case, though there may be a "modern Forth" that is way more >> capable than the Forth I remember from the 80s. > > Forth is certainly very low level, and used for low level tasks. But > it is defined in terms of a virtual machine, and in many cases /run/ > on a virtual machine, which I think changes things a bit. I was hoping you'd say one way or the other. <cut> > ... can you at least see what I mean about it being difficult in many > cases to give a reasonable ordering? Sure. I thought I'd made that clear, but obviously not. > And would you agree that there > is nothing to say that there aren't other languages around, making it > unreasonable to say that /this/ particular language is /the/ language > that fits between these other two languages? Yes. I was responding to a later paragraph that was just about finding /a/ language "between" C and ASM. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-25 09:48 +0100 |
| Message-ID | <q7a4la$u41$1@dont-email.me> |
| In reply to | #142388 |
On 25/03/2019 02:12, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 23/03/2019 18:53, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 23/03/2019 15:24, Ben Bacarisse wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> >>>>>> On 22/03/2019 17:05, Bart wrote: >>>>>>> On 22/03/2019 15:10, David Brown wrote: >>>>>>>> On 22/03/2019 15:40, Bart wrote: >>>>>>> >>>>>>>>> So what language is? (I don't count HLAs here.) >>>>>>>> >>>>>>>> What is the next language sideways from Lisp? >>>>>>>> >>>>>>>> It's a meaningless question. >>>>>>> >>>>>>> Is C higher or lower level than Python? That's easy to answer. In >>>>>>> that case it shouldn't be hard to find a language X which is higher >>>>>>> level than ASM, and lower level than X, and that is portable. >>>>> >>>>> BCPL? >>> >>> (I'm assuming the X was a typo.) >> >> Yes. >> >>> >>>>>> C is lower level than Python - few would argue about that. That tells >>>>>> us /nothing/ about whether there is a language between C and assembly. >>>>> >>>>> True, but he's asking if there is one. If you think not, you might as >>>>> well say so. Given what you say here: >>>> >>>> Do I think there is a language between assembly and C in some vague >>>> "level" sense? >>>> >>>> As I have said, I think the question is meaningless, but even if I >>>> attempt to answer it, I still don't know. >>> >>> I don't really get how the question is meaningless yet you will >>> entertain some examples of related questions. Is it specifically to do >>> with C and these as yet unknown candidate languages that the question is >>> meaningless? >> >> I just don't think you can rank languages in a scale like this. It is >> no more complicated than that. > > Yes, I get that. The bit I don't get is your willingness to rank > languages like this when you say you can't. > I was not willing to rank or compare languages, except where the consensus of subjective opinion is very clear. (This is the case in all sorts of things in life where there is no clear, precise ranking.) So I am willing to rate Python as higher level than C, but I would be a lot less willing to rate Python against PHP, or Forth against C, or cases where the languages are completely different (like VHDL against JavaScript). >>>> In some ways, Forth might be a candidate, and is certainly used for >>>> low-level systems. >>> >>> Why would you not say that it fits the bill? Do you think a case can be >>> made that Forth is as high-level a language as C? I don't think I could >>> make that case, though there may be a "modern Forth" that is way more >>> capable than the Forth I remember from the 80s. >> >> Forth is certainly very low level, and used for low level tasks. But >> it is defined in terms of a virtual machine, and in many cases /run/ >> on a virtual machine, which I think changes things a bit. > > I was hoping you'd say one way or the other. Sorry, no. > > <cut> >> ... can you at least see what I mean about it being difficult in many >> cases to give a reasonable ordering? > > Sure. I thought I'd made that clear, but obviously not. I think we are actually saying much the same thing, but possibly have different thoughts on /how/ difficult such orderings are, or how meaningful. Since the concepts are very vague and ill-defined, there is no way to quantify this. > >> And would you agree that there >> is nothing to say that there aren't other languages around, making it >> unreasonable to say that /this/ particular language is /the/ language >> that fits between these other two languages? > > Yes. I was responding to a later paragraph that was just about finding > /a/ language "between" C and ASM. > OK. This whole branch of discussion has been a bit unclear, with details changing along the way. (No doubt I am at least partly to blame for that.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 14:25 +0000 |
| Message-ID | <ilrlE.841911$Xct1.512300@fx12.am4> |
| In reply to | #142278 |
On 23/03/2019 12:47, David Brown wrote:
> On 22/03/2019 17:05, Bart wrote:
>> Is C higher or lower level than Python? That's easy to answer. In that
>> case it shouldn't be hard to find a language X which is higher level
>> than ASM, and lower level than [C], and that is portable.
> Your question is as meaningless as asking for the next step on the way
> from pizza to steak and chips.
>
> (I've seen people struggle with such concepts in many areas. People
> like to be able to place things in a nice, clean, ordered line - but it
> is rarely realistic.)
Yet, when I remarked that C is the next level up from ASM, you
confidently said 'Nope', in a way that suggested to me that you knew of
one that was closer to ASM.
So for a concept so badly defined, you seemed pretty sure of C's place!
Let me phrase it differently: if someone is doing low-level work and is
currently using assembly, what would you recommend they switch to, if
anything?
> You have been told repeatedly that C is not the language you think, and
> does not work the way you think. I believe that if you learned to read
> and think, and appreciate that other people are trying to help you
> understand C, then you could get a handle on it. Whether you then like
> or dislike C as it really is, is a different matter
I've been programming since 1976. I think I have a pretty good idea of
what I expect from a language, for the fairly low level work I do.
C was a crude attempt at a systems programming language, and yes it was
often used as the next step up from using assembly. Disregarding its
syntax, primitive origins, and many quirks, it was capable of filling
that role.
But now its people like you who want to make it something it's not.
- but at least you
> have a chance to learn to like it, or learn to use it properly. As long
> as you keep trying to force your misconceptions on it, you will not like
> the language, you will hate the tools, and you will get things wrong.
I design languages and write tools for them. I've done /that/ since
1981. I'm the wrong audience for your advice which seems to be for
people who are not allowed to have their own opinions or use their own
experience.
>> I also tried it on my new language which is all 64-bit, uses 64-bit
>> registers, and promotes narrower types to 64-bits (my current one
>> doesn't promote).
>
> What bit of "x86" do you find hard to comprehend?
What do you mean by that, and how is it relevent?
> And why would you possibly consider a test on /your/ tools to be
> relevant? They are written by someone who doesn't understand C, for a
> different language,
Because this is what the thread is about! All languages are using the
same processors (mainly x64 and ARM from what I can see), and yet it's
only C that appears to have a hangup about shifts on signed numbers.
The OP is suggesting some of those UBs ought to be relaxed. Your stance
(of many here actually) seems to be that of a religious zealot, for whom
only what is written in some revered Text is what counts, and admits of
no other view.
> Your tests don't strengthen your argument - they strengthen the image
> that you don't know what you are talking about.
Yet my language gets it right. Your DEC Alpha, by your accounts, either
gets it wrong, or you don't actually know.
> $DIETY only knows what results you would get for /your/ language.
In this example:
int32_t x=f();
int32_t y=x>>8;
It will use the 32-bit value of x here expanded cleanly to 64 bits. it
will NOT use a 32-bit value of x converted to 64 bits but with garbage
bits in the top half, as you said the DEC Alpha /might/ do.
So it is C where only God knows what it will do.
> No one is asking you to /like/ the way C handles integer overflow and
> other kinds of undefined behaviour. I am merely asking you to
> /understand/ it.
The OP is saying it ought to be relaxed, so that we can get all the
benefits.
One of those being that we don't get a situation where 15 C compilers
give the expected, common-sense result, but we still have to worry about
a 16th smart-alec compiler that does what the hell it likes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-23 18:06 +0100 |
| Message-ID | <q75p20$vna$1@dont-email.me> |
| In reply to | #142285 |
On 23/03/2019 15:25, Bart wrote: > On 23/03/2019 12:47, David Brown wrote: >> On 22/03/2019 17:05, Bart wrote: > >>> Is C higher or lower level than Python? That's easy to answer. In >>> that case it shouldn't be hard to find a language X which is higher >>> level than ASM, and lower level than [C], and that is portable. > >> Your question is as meaningless as asking for the next step on the way >> from pizza to steak and chips. >> >> (I've seen people struggle with such concepts in many areas. People >> like to be able to place things in a nice, clean, ordered line - but >> it is rarely realistic.) > > Yet, when I remarked that C is the next level up from ASM, you > confidently said 'Nope', in a way that suggested to me that you knew of > one that was closer to ASM. > You have made an invalid inference. There are (IMHO) no such steps or definable levels, so it does not make sense to treat C as the "next level up from assembly". It is even worse if you make the mistake - as you do - of thinking that this means C is defined in terms of the underlying machine and its behaviour. It would be equally reasonable to consider Forth to be such as "step up" from assembly. > So for a concept so badly defined, you seemed pretty sure of C's place! > > Let me phrase it differently: if someone is doing low-level work and is > currently using assembly, what would you recommend they switch to, if > anything? Oh, that's easy. C is the obvious answer in most cases. Depending on the programmer's experience, knowledge, and ambitions, perhaps C++. (While Forth is a low level language, I won't normally recommend it.) > >> You have been told repeatedly that C is not the language you think, >> and does not work the way you think. I believe that if you learned to >> read and think, and appreciate that other people are trying to help >> you understand C, then you could get a handle on it. Whether you then >> like or dislike C as it really is, is a different matter > > I've been programming since 1976. I think I have a pretty good idea of > what I expect from a language, for the fairly low level work I do. > > C was a crude attempt at a systems programming language, and yes it was > often used as the next step up from using assembly. Disregarding its > syntax, primitive origins, and many quirks, it was capable of filling > that role. > > But now its people like you who want to make it something it's not. What, people like me - including the C standards committee over the past several decades, and the people implementing mainstream C compilers? Regardless of how crude, quirky or primitive you think C is, it has always been a high level programming language that is useable for low level programming tasks. It follows the rules laid out in the standards - if you step outside those rules, the compiler has no responsibility for what happens. You don't get to make up your own ideas of what nonsensical code and nonsensical values mean, even if those ideas come from the target hardware. > > - but at least you >> have a chance to learn to like it, or learn to use it properly. As >> long as you keep trying to force your misconceptions on it, you will >> not like the language, you will hate the tools, and you will get >> things wrong. > > I design languages and write tools for them. I've done /that/ since > 1981. I'm the wrong audience for your advice which seems to be for > people who are not allowed to have their own opinions or use their own > experience. You misunderstand me. (You do that a great deal.) I am not talking about opinions - I am not asking you to approve of the way C works. I am asking you to /accept/ the /facts/ of how C is defined. I think you would have a better chance of liking the language if you learned how it works instead of fighting it all the time, but that bit is up to you. > > >>> I also tried it on my new language which is all 64-bit, uses 64-bit >>> registers, and promotes narrower types to 64-bits (my current one >>> doesn't promote). >> >> What bit of "x86" do you find hard to comprehend? > > What do you mean by that, and how is it relevent? I pointed out that on the x86, using 32-bit operations here would be the efficient way to implement the operations in question, thus there is little doubt of the results (real compilers don't go out of their way to cause confusion). So any tests you do with any x86 (32-bit or 64-bit) compilers is likely to give you the same results. > >> And why would you possibly consider a test on /your/ tools to be >> relevant? They are written by someone who doesn't understand C, for a >> different language, > Because this is what the thread is about! All languages are using the > same processors (mainly x64 and ARM from what I can see), and yet it's > only C that appears to have a hangup about shifts on signed numbers. > No, that is not what the thread was about. The problem is /your/ hangups about undefined behaviour in C. Nor are you correct about "all languages" (again, that concept does not even make sense. By the time you had tried to check corresponding features on all the programming languages you found, there would be new languages to test). Lots of programming languages make signed integer overflow undefined behaviour. Nor are you correct that all languages use the same processors, even though x86 and ARM (in all their many, significantly different varieties) are massively popular. > The OP is suggesting some of those UBs ought to be relaxed. Your stance > (of many here actually) seems to be that of a religious zealot, for whom > only what is written in some revered Text is what counts, and admits of > no other view. "Religious zealots" don't tend to explain their positions from rational argument, as I have done. The OP's main suggestion - restricting C to two's complement as the only conforming signed integer representation - seems like a reasonable one to me. Using that step to turn certain kinds of implementation defined behaviour into fully defined behaviour would also be logical. I don't think either of these would make a very big difference to C programming for most people, but it could simplify some portable code, and help make the standards clearer. I don't want signed integer overflow to be defined behaviour - because that would be worse for the language, worse for the tools, and worse for developers. I would actually prefer that unsigned integer overflow were undefined too, to give more efficient code and better error checking. But we'd need to add a way to get wrapping on the few occasions when it is needed - and of course I am not in favour of making a language change that is incompatible with existing code. > >> Your tests don't strengthen your argument - they strengthen the image >> that you don't know what you are talking about. > > Yet my language gets it right. Your DEC Alpha, by your accounts, either > gets it wrong, or you don't actually know. One would hope that your language gets things right for the way your language defines such operations. For C, there is no right answer to 32-bit signed 1 << 31, so any behaviour is equally valid. > >> $DIETY only knows what results you would get for /your/ language. > > In this example: > > int32_t x=f(); > int32_t y=x>>8; > > It will use the 32-bit value of x here expanded cleanly to 64 bits. it > will NOT use a 32-bit value of x converted to 64 bits but with garbage > bits in the top half, as you said the DEC Alpha /might/ do. > > So it is C where only God knows what it will do. Listen carefully. No one actually gives a *beep* what your language does here. That is not under discussion. No one cares what /you/ think 1 << 31 should be, or how /you/ think it should be defined, or how /you/ think it should be calculated. In C, for 32-bit int, 1 << 31 is undefined. It does not have a meaningful value. It is garbage in, garbage out. Asking for its value is meaningless. A program that tries to calculate it does not make sense. There is no correct answer, so /any/ answer is equally valid. In C, the compiler assumes the programmer knows what he/she is doing, and how to use the language. Since doing something with undefined behaviour is meaningless and nonsensical, the compiler assumes the programmer would never do that - because the programmer is responsible for writing correct code. Thus the compiler can assume that undefined behaviour does not occur. The compiler is responsible for generating code that gives the correct results for the correct inputs - it does not matter what the code does when the inputs are invalid. > >> No one is asking you to /like/ the way C handles integer overflow and >> other kinds of undefined behaviour. I am merely asking you to >> /understand/ it. > > The OP is saying it ought to be relaxed, so that we can get all the > benefits. > The OP is incorrect in thinking it would be beneficial. I have explained why. Of course, "beneficial" is somewhat a matter of opinion. That is why some compilers offer options to let people change the semantics of the language to defined integer overflow. > One of those being that we don't get a situation where 15 C compilers > give the expected, common-sense result, but we still have to worry about > a 16th smart-alec compiler that does what the hell it likes. > We don't have that situation.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-03-23 17:59 +0000 |
| Message-ID | <juulE.42523$n34.36885@fx11.iad> |
| In reply to | #142278 |
David Brown <david.brown@hesbynett.no> writes:
>On 22/03/2019 17:05, Bart wrote:
>> On 22/03/2019 15:10, David Brown wrote:
>>> On 22/03/2019 15:40, Bart wrote:
>>
>>>> So what language is? (I don't count HLAs here.)
>>>
>>> What is the next language sideways from Lisp?
>>>
>>> It's a meaningless question.
>>
>> Is C higher or lower level than Python? That's easy to answer. In that
>> case it shouldn't be hard to find a language X which is higher level
>> than ASM, and lower level than X, and that is portable.
>
>C is lower level than Python - few would argue about that. That tells
>us /nothing/ about whether there is a language between C and assembly.
Most of which will likely never be "portable".
For example, Burroughs Programming Language (BPL) is closer to the
hardware than C. But definitely not portable in any modern sense.
I suspect the HP-3000 System Programming Language (SPL) would also
be considered to be closer to the hardware than C; and in fact,
like the Burroughs systems, there was no assembler on the
HP-3000 - SPL was it; somewhat algol-like.
(TOS -> Top Of Stack - HP-3000 was a stack machine, no general purpose registers;
on the left hand side it's a "push", on the right hand side, it's a "pop" operation).
LOGICAL PROCEDURE DSTLEN(DSTN,LEN);
VALUE DSTN;
INTEGER DSTN,LEN;
BEGIN
INTEGER
PN := 00000, << PROCEDURE NUMBER>>
VN := 00000; << VERSION NUMBER >>
INTEGER ARRAY
BUF(0:3);
INTRINSIC
GETPRIVMODE,
GETUSERMODE;
<< CODE >>
PUSH(STATUS); << Push STATUS register on stack >>
TOS := TOS LAND %157777; << TURN OFF ARITH TRAPS >>
SET(STATUS); << POP STATUS register from stack >>
GETUSERMODE;
DSTLEN := FALSE;
GETPRIVMODE; << DANGER DANGER DANGER >>
TOS := @BUF; << BUFFER BASE ADDRESS >>
TOS := 2; << DST # of DST TABLE >>
TOS := 0; << OFFSET INTO DST TABLE >>
TOS := 4; << NUMBER OF WORDS >>
DSTMOVE; << GETWORDS FROM MPE DST TABLE >>
LEN := BUF(0).(3:13)*4; << CALC DST LEN >>
FINISHPROC:
GETUSERMODE;
END;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-22 11:46 -0700 |
| Message-ID | <lnftreg31d.fsf@kst-u.example.com> |
| In reply to | #142241 |
Bart <bc@freeuk.com> writes:
> On 22/03/2019 13:26, David Brown wrote:
>> On 22/03/2019 12:39, Bart wrote:
>> It is absolutely fine to have an operation whose result is sensible and
>> defined when interpreted as one type, and not sensible, valid or defined
>> when interpreted as another type.
>
> At what point would it generate nasal daemons?
(Demons, not daemons.)
In real life, never, because there's no such thing. The point is that
the standard does not say that the program must not generate nasal
demons. It's an exaggerated way of describing undefined behavior.
(Surely you know this.)
1 << 31 (given 32-bit int) has undefined behavior. An implementation in
which a program that evaluates 1 << 31 generates literal nasal demons
would probably violate the laws of physics, but it would not violate the
C standard.
>>> So it's the next step up from assembly language.
>>
>> Nope.
>
> So what language is? (I don't count HLAs here.)
Here's the difference. An assembly language program specifies
a sequence of CPU instructions. The behavior of the resulting
sequence is specified by the CPU, not by the assembler. A C program
specifies behavior.
C is lower level than many other languages, and higher level
assembly language. I suppose you could, by stretching the point,
say that C is "one level up" from assembly language. But there is a
tremendous gulf between languages that specify CPU instructions and
languages that specify behavior, and it's clear which side C is on.
[snip]
--
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 | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-22 19:59 +0000 |
| Message-ID | <4xbuzOOAlvYkI6HsQ2v8jUO7sTDOP@bongo-ra.co> |
| In reply to | #142253 |
On Fri, 22 Mar 2019 11:46:54 -0700 Keith Thompson <kst-u@mib.org> wrote: > Bart <bc@freeuk.com> writes: > > On 22/03/2019 13:26, David Brown wrote: > >> On 22/03/2019 12:39, Bart wrote: > >> It is absolutely fine to have an operation whose result is sensible and > >> defined when interpreted as one type, and not sensible, valid or defined > >> when interpreted as another type. > > > > At what point would it generate nasal daemons? > > (Demons, not daemons.) The distinction between "demons" and "daemons" is implementation defined ; if it's undefined behavio(u)r , it could be demons or daemons or some hybrid d(a)emonic creature. Personally , I like better the example that it might turn the computer into a frog.
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-22 20:30 -0700 |
| Message-ID | <3ffba386-9189-4c35-8bf2-76cb9d311439@googlegroups.com> |
| In reply to | #142253 |
On Friday, March 22, 2019 at 6:47:03 PM UTC, Keith Thompson wrote: > >>> So it's the next step up from assembly language. > >> > >> Nope. > > > > So what language is? (I don't count HLAs here.) > > Here's the difference. An assembly language program specifies > a sequence of CPU instructions. The behavior of the resulting > sequence is specified by the CPU, not by the assembler. A C program > specifies behavior. > > C is lower level than many other languages, and higher level > assembly language. I suppose you could, by stretching the point, > say that C is "one level up" from assembly language. But there is a > tremendous gulf between languages that specify CPU instructions and > languages that specify behavior, and it's clear which side C is on. Worth remembering where it came from though. https://www.bell-labs.com/usr/dmr/www/chist.html > Whence Success? > C has become successful to an extent far surpassing any early expectations. What qualities contributed to its widespread use? > Doubtless the success of Unix itself was the most important factor; it made the language available to hundreds of thousands of people. Conversely, of course, Unix's use of C and its consequent portability to a wide variety of machines was important in the system's success. But the language's invasion of other environments suggests more fundamental merits. > Despite some aspects mysterious to the beginner and occasionally even to the adept, C remains a simple and small language, translatable with simple and small compilers. Its types and operations are well-grounded in those provided by real machines, and for people used to how computers work, learning the idioms for generating time- and space-efficient programs is not difficult. At the same time the language is sufficiently abstracted from machine details that program portability can be achieved. > Equally important, C and its central library support always remained in touch with a real environment. It was not designed in isolation to prove a point, or to serve as an example, but as a tool to write programs that did useful things; it was always meant to interact with a larger operating system, and was regarded as a tool to build larger tools. A parsimonious, pragmatic approach influenced the things that went into C: it covers the essential needs of many programmers, but does not try to supply too much. > Finally, despite the changes that it has undergone since its first published description, which was admittedly informal and incomplete, the actual C language as seen by millions of users using many different compilers has remained remarkably stable and unified compared to those of similarly widespread currency, for example Pascal and Fortran. There are differing dialects of C—most noticeably, those described by the older K&R and the newer Standard C—but on the whole, C has remained freer of proprietary extensions than other languages. Perhaps the most significant extensions are the `far' and `near' pointer qualifications intended to deal with peculiarities of some Intel processors. Although C was not originally designed with portability as a prime goal, it succeeded in expressing programs, even including operating systems, on machines ranging from the smallest personal computers through the mightiest supercomputers. > C is quirky, flawed, and an enormous success. While accidents of history surely helped, it evidently satisfied a need for a system implementation language efficient enough to displace assembly language, yet sufficiently abstract and fluent to describe algorithms and interactions in a wide variety of environments. C is a system programming language, intended to be as powerful as assembly language. Ignoring the relation to assembly language is really missing the point.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-25 22:33 +0000 |
| Message-ID | <slrnq9ilqb.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #142272 |
On Sat, 2019-03-23, Howard Chu wrote: ... > C is a system programming language, intended to be as powerful as > assembly language. Ignoring the relation to assembly language is > really missing the point. Like others upthread, I don't agree at all. But: assembly is highly relevant anyway. When you have to debug, or when you have to decide if a bug is exploitable. As a programmer in C (or C++ or any other language with a slim runtime) you have to deal with that. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web