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 | 16 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 14 of 14 — ← Prev page 1 … 12 13 [14]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 13:29 -0700 |
| Message-ID | <lnd0mli925.fsf@kst-u.example.com> |
| In reply to | #142105 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I think it would be a good idea for future C standards to fix the signed
> representation as two's complement, remove all mentions of trapping
> values for integer types, remove the possibility of padding bits in
> these types (except perhaps for _Bool),
Agreed so far (unless there are relevant real-world implementations with
padding bits).
> enforce either big or little
> endian ordering,
Nope. There are existing implementations using both representations,
though little-endian has become more common. (I worked on big-endian
systems as recently as last year.) Emulating a "foreign" endianness
would be entirely too expensive.
Big-endian hardware might die out in the next few decades, as
non-two's-complement has. Once that happens, we can revisit this.
> and tighten up implementation defined behaviour when
> all current targets have the same behaviour.
Agreed, but that would have to be studied on a case by case basis.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-03-20 21:12 +0000 |
| Message-ID | <Q0ykE.115003$%45.96042@fx39.iad> |
| In reply to | #142125 |
Keith Thompson <kst-u@mib.org> writes: >David Brown <david.brown@hesbynett.no> writes: >[...] >> enforce either big or little >> endian ordering, > >Nope. There are existing implementations using both representations, >though little-endian has become more common. (I worked on big-endian >systems as recently as last year.) Emulating a "foreign" endianness >would be entirely too expensive. > >Big-endian hardware might die out in the next few decades, as >non-two's-complement has. Once that happens, we can revisit this. It probably won't happen until all the TCP and IP protocols are redesigned (or superceded) to use little-endian as network byte order. Most high end network appliances use big-endian (or bi-endian) CPUs specifically to be able to process network packets as fast as possible.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-20 23:02 +0100 |
| Message-ID | <q6ud8s$uv5$1@dont-email.me> |
| In reply to | #142125 |
On 20/03/2019 21:29, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> I think it would be a good idea for future C standards to fix the signed >> representation as two's complement, remove all mentions of trapping >> values for integer types, remove the possibility of padding bits in >> these types (except perhaps for _Bool), > > Agreed so far (unless there are relevant real-world implementations with > padding bits). > >> enforce either big or little >> endian ordering, > > Nope. There are existing implementations using both representations, > though little-endian has become more common. (I worked on big-endian > systems as recently as last year.) Emulating a "foreign" endianness > would be entirely too expensive. Sorry, I was unclear. I meant that the standards should allow little-endian encoding, /and/ big-endian encoding. But they should disallow mixed endian encodings. Implementations should be allowed to pick one or the other. > > Big-endian hardware might die out in the next few decades, as > non-two's-complement has. Once that happens, we can revisit this. > >> and tighten up implementation defined behaviour when >> all current targets have the same behaviour. > > Agreed, but that would have to be studied on a case by case basis. > Agreed. For example, I think it would be entirely reasonable to say that conversion from unsigned to signed types be handled by wrapping (i.e., on almost any system, it would be handled by doing nothing).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-20 20:32 +0000 |
| Message-ID | <87mulpz3qu.fsf@bsb.me.uk> |
| In reply to | #142105 |
David Brown <david.brown@hesbynett.no> writes: <cut> > I think it would be a good idea for future C standards to fix the signed > representation as two's complement, remove all mentions of trapping > values for integer types, remove the possibility of padding bits in > these types (except perhaps for _Bool), enforce either big or little > endian ordering, and tighten up implementation defined behaviour when > all current targets have the same behaviour. Why? What is the cost of leaving things as they are? <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-20 23:08 +0100 |
| Message-ID | <q6udka$1d0$1@dont-email.me> |
| In reply to | #142126 |
On 20/03/2019 21:32, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > <cut> >> I think it would be a good idea for future C standards to fix the signed >> representation as two's complement, remove all mentions of trapping >> values for integer types, remove the possibility of padding bits in >> these types (except perhaps for _Bool), enforce either big or little >> endian ordering, and tighten up implementation defined behaviour when >> all current targets have the same behaviour. > > Why? What is the cost of leaving things as they are? > It is not a big cost, but it would simplify the standards, and simplify some code that aims to be highly portable (it would also make code that now is "portable to all realistic systems" into code that is fully portable). It would make little practical difference to most programmers - after all, it would be codifying the implementation-defined behaviours found in most existing compilers. But who could object to simplifying the C standards a little?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-21 00:25 +0000 |
| Message-ID | <875zsdysxf.fsf@bsb.me.uk> |
| In reply to | #142143 |
David Brown <david.brown@hesbynett.no> writes: > On 20/03/2019 21:32, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> <cut> >>> I think it would be a good idea for future C standards to fix the signed >>> representation as two's complement, remove all mentions of trapping >>> values for integer types, remove the possibility of padding bits in >>> these types (except perhaps for _Bool), enforce either big or little >>> endian ordering, and tighten up implementation defined behaviour when >>> all current targets have the same behaviour. >> >> Why? What is the cost of leaving things as they are? >> > > It is not a big cost, but it would simplify the standards, and > simplify some code that aims to be highly portable (it would also make > code that now is "portable to all realistic systems" into code that is > fully portable). A few parts of the standard would be a bit simpler, but the wording is already there and I doubt it confuses anyone. Other parts are likely to get longer -- for example, there's no mention of byte order at present so you'd have to add that. The second advantage seems like sophistry to me. Yes, in some way, code that has to negotiate the possible of padding bits on some hardware would be simpler if these were not allowed but only at the expense of either not having a C implementation available on that hardware or having one that has to emulate integer types with no padding, presumably at great expense. <cut> > But who could object to simplifying the C standards a little? Well, for one, anyone who is not certain what hardware we'll be using in a few years time. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-21 07:12 +0000 |
| Message-ID | <slrnq96eas.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #142158 |
On Thu, 2019-03-21, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: ... >> But who could object to simplifying the C standards a little? > > Well, for one, anyone who is not certain what hardware we'll be using in > a few years time. Yeah. In another recent thread, people were complaining that C compatibility hinders progress in computer hardware. (Not that I think weird endianness would be part of such a progress.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 16:13 +0100 |
| Message-ID | <q709nn$pj2$2@dont-email.me> |
| In reply to | #142165 |
On 21/03/2019 08:12, Jorgen Grahn wrote: > On Thu, 2019-03-21, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: > ... >>> But who could object to simplifying the C standards a little? >> >> Well, for one, anyone who is not certain what hardware we'll be using in >> a few years time. > > Yeah. In another recent thread, people were complaining that C > compatibility hinders progress in computer hardware. (Not that I think > weird endianness would be part of such a progress.) > There is a reasonable argument for that, yes - general purpose processors are designed to handle C. But if future architectures are not C oriented (maybe they will be stack machines, neural networks, JVM processors, whatever) then they won't be targets for C, and therefore are not relevant to what might be nice in future C standards.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 16:11 +0100 |
| Message-ID | <q709j9$pj2$1@dont-email.me> |
| In reply to | #142158 |
On 21/03/2019 01:25, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 20/03/2019 21:32, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> <cut> >>>> I think it would be a good idea for future C standards to fix the signed >>>> representation as two's complement, remove all mentions of trapping >>>> values for integer types, remove the possibility of padding bits in >>>> these types (except perhaps for _Bool), enforce either big or little >>>> endian ordering, and tighten up implementation defined behaviour when >>>> all current targets have the same behaviour. >>> >>> Why? What is the cost of leaving things as they are? >>> >> >> It is not a big cost, but it would simplify the standards, and >> simplify some code that aims to be highly portable (it would also make >> code that now is "portable to all realistic systems" into code that is >> fully portable). > > A few parts of the standard would be a bit simpler, but the wording is > already there and I doubt it confuses anyone. Other parts are likely to > get longer -- for example, there's no mention of byte order at present > so you'd have to add that. > I think you might be surprised how much the wording in the C standards confuses people! It also greatly reduces the number of people who might read it. The standard has a great deal of scope for improvement in clarity and organisation, to make it easier as a reference document. Note that "simplifying" does not necessarily only mean "taking stuff out" - it means making it easier for people to look up things in the document and get the answers they want, without having to figure out what a "padding bit" might be, and without having to jump back and forth through a half-dozen sections to get a complete picture of an "int". > The second advantage seems like sophistry to me. Yes, in some way, code > that has to negotiate the possible of padding bits on some hardware > would be simpler if these were not allowed but only at the expense of > either not having a C implementation available on that hardware or > having one that has to emulate integer types with no padding, presumably > at great expense. > > <cut> >> But who could object to simplifying the C standards a little? > > Well, for one, anyone who is not certain what hardware we'll be using in > a few years time. > Anyone who uses hardware at the moment, and knows about the patterns of hardware for the last 20 years, can make some good guesses about features of the hardware for the next 20 years - at least for hardware that would be running C. I'll bet you a pizza that all mainstream architectures targeted by C2039 compilers in the year 2039 will have two's complement signed integers, byte ordering either pure little-endian or pure big-endian, and all but a tiny fraction of a percent will have 8-bit "char". And I'll bet extra cheese that "int" is 32-bit. That doesn't mean that there will not be other architectures around, but they won't be programmed in modern C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-21 17:04 +0000 |
| Message-ID | <87zhpow44c.fsf@bsb.me.uk> |
| In reply to | #142180 |
David Brown <david.brown@hesbynett.no> writes: > On 21/03/2019 01:25, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: <cut> >>> But who could object to simplifying the C standards a little? >> >> Well, for one, anyone who is not certain what hardware we'll be using in >> a few years time. > > Anyone who uses hardware at the moment, and knows about the patterns of > hardware for the last 20 years, can make some good guesses about > features of the hardware for the next 20 years - at least for hardware > that would be running C. I'll bet you a pizza that all mainstream > architectures targeted by C2039 compilers in the year 2039 will have > two's complement signed integers, byte ordering either pure > little-endian or pure big-endian, and all but a tiny fraction of a > percent will have 8-bit "char". And I'll bet extra cheese that "int" is > 32-bit. Interesting you left out the part I am least sure of -- padding bits. I can imagine a scenario where memory is cheap but access is slow unless streamlined with wide load/store operations. On such machines, an 8-bit char might have padding bits to make it cheap to access but convenient to program with. Anyway, C should not only be for mainstream architectures. In fact, with luck, C will only be for fringe architectures by 2039! > That doesn't mean that there will not be other architectures around, but > they won't be programmed in modern C. If you bake these assumptions in to the C standard, you are making a self-fulfilling prophesy! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-21 13:02 -0700 |
| Message-ID | <ln36nggfmf.fsf@kst-u.example.com> |
| In reply to | #142188 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Interesting you left out the part I am least sure of -- padding bits. I
> can imagine a scenario where memory is cheap but access is slow unless
> streamlined with wide load/store operations. On such machines, an 8-bit
> char might have padding bits to make it cheap to access but convenient
> to program with.
How would that work?
It would require dropping the current requirement that the char
types have no padding bits.
It also implies that CHAR_BIT > 8, that an array of char requires
more than 8 bits per character while still being able to represent
only 256 distinct values per byte, and that an object representation
can't be represented as an array of unsigned char.
It would also violate the POSIX requirement that CHAR_BIT==8.
I can imagine weird things in future architectures, but this is not a
likely one -- unless the designers give up on C support.
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-21 22:03 +0000 |
| Message-ID | <87d0mjx4v2.fsf@bsb.me.uk> |
| In reply to | #142202 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> Interesting you left out the part I am least sure of -- padding bits. I >> can imagine a scenario where memory is cheap but access is slow unless >> streamlined with wide load/store operations. On such machines, an 8-bit >> char might have padding bits to make it cheap to access but convenient >> to program with. > > How would that work? > > It would require dropping the current requirement that the char > types have no padding bits. Yes, I forgot that. Switch to short or int. The point being I am not 100% sure that accessing and storing larger units than you want to calculate with might not be desirable in the future. You can always just make short and int into, say, 64-bit types so there would be a non-padding bits way out, but maybe having fewer value bits would be useful. It is, by the very nature to the topic, rather up in the air (and I am not a hardware person). <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-23 07:25 -0700 |
| Message-ID | <86k1gpoegm.fsf@mailhub.linuxsc.com> |
| In reply to | #142080 |
Howard Chu <highlandsun@gmail.com> writes:
> There's a proposal to change the C++ spec to declare that all
> integers are two's complement.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html
Sigh. It's disappointing to see that this poorly thought out and
fundamentally misguided proposal is being taken seriously.
> Is there a corresponding proposed change for the C spec? It would
> certainly simplify life and could eliminate a number of undefined
> behaviors from the spec.
Sadly, yes (subsituting "similar" for "corresponding"). The
latest update I see is dated January 15, 2019 -
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2330.pdf
> On that topic, it would be nice to see a compiler mode that makes
> all undefined behaviors implementation defined, lets the underlying
> hardware do whatever it's going to do with them, and most
> importantly, stops abusing them in the optimizer. E.g., quit
> allowing compilers to delete NULL-pointer checks
> https://lwn.net/Articles/342420/
>
> I.e., a mode where there are no undefined behaviors, so that the
> optimizer is not allowed to assume "this never happens" and thus
> cannot ignore or gratuitously delete any of the source code being
> compiled.
I sympathize with what you want to accomplish, but it's hard to
find a good wording to express that. For starters, there is
nothing a compiler can do to change undefined behavior into
implementation-defined behavior, or vice versa. Even if an
implementation defines a particular undefined behavior (such as,
say, dividing by zero), /and documents what it does/, the
construct still has undefined behavior, as the Standard uses the
term. What I think you want is to "soften" constructs specified
as 'undefined behavior' in the Standard so that they can't do
anything too egregious (or at least have a way of telling the
compiler to follow that rule). I too would like to see some
movement in that direction (and also some members of WG14
although I don't have any specifics handy). One big problem:
the Standard specifies behavior in terms of an abstract machine,
but "softening" what is done with an "undefined behavior"
construct usually is talked about in terms of what happens in the
actual machine. There is an inherent impedance mismatch between
those two realms. How can that mismatch be reconciled? One idea
that I think is worth looking into is to treat undefined behavior
similarly to how 'volatile' is treated: the implementation is
not allowed to make any assumptions about what happens if an
'undefined behavior' condition occurs. In particular, an
implementation would NOT be allowed to assume that those
conditions do _not_ occur. "Let the machine do whatever it
normally would do when it encounters such cases", might be a way
to say it. Assuming that matches what you're looking for, the
next step is to try to express that in the type and style of
language that is used in the ISO C standard.
If that doesn't match what you're looking for, can you say a
bit more about what the differences are?
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-23 11:38 -0700 |
| Message-ID | <3d86512a-7a25-48f5-b7b6-eeadb9676bbd@googlegroups.com> |
| In reply to | #142284 |
On Saturday, March 23, 2019 at 2:25:23 PM UTC, Tim Rentsch wrote: > Howard Chu <highlandsun@gmail.com> writes: > > > There's a proposal to change the C++ spec to declare that all > > integers are two's complement. > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html > > Sigh. It's disappointing to see that this poorly thought out and > fundamentally misguided proposal is being taken seriously. > > > Is there a corresponding proposed change for the C spec? It would > > certainly simplify life and could eliminate a number of undefined > > behaviors from the spec. > > Sadly, yes (subsituting "similar" for "corresponding"). The > latest update I see is dated January 15, 2019 - > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2330.pdf > > > On that topic, it would be nice to see a compiler mode that makes > > all undefined behaviors implementation defined, lets the underlying > > hardware do whatever it's going to do with them, and most > > importantly, stops abusing them in the optimizer. E.g., quit > > allowing compilers to delete NULL-pointer checks > > https://lwn.net/Articles/342420/ > > > > I.e., a mode where there are no undefined behaviors, so that the > > optimizer is not allowed to assume "this never happens" and thus > > cannot ignore or gratuitously delete any of the source code being > > compiled. > > I sympathize with what you want to accomplish, but it's hard to > find a good wording to express that. For starters, there is > nothing a compiler can do to change undefined behavior into > implementation-defined behavior, or vice versa. Even if an > implementation defines a particular undefined behavior (such as, > say, dividing by zero), /and documents what it does/, the > construct still has undefined behavior, as the Standard uses the > term. What I think you want is to "soften" constructs specified > as 'undefined behavior' in the Standard so that they can't do > anything too egregious (or at least have a way of telling the > compiler to follow that rule). I too would like to see some > movement in that direction (and also some members of WG14 > although I don't have any specifics handy). One big problem: > the Standard specifies behavior in terms of an abstract machine, > but "softening" what is done with an "undefined behavior" > construct usually is talked about in terms of what happens in the > actual machine. There is an inherent impedance mismatch between > those two realms. How can that mismatch be reconciled? One idea > that I think is worth looking into is to treat undefined behavior > similarly to how 'volatile' is treated: the implementation is > not allowed to make any assumptions about what happens if an > 'undefined behavior' condition occurs. In particular, an > implementation would NOT be allowed to assume that those > conditions do _not_ occur. "Let the machine do whatever it > normally would do when it encounters such cases", might be a way > to say it. Assuming that matches what you're looking for, the > next step is to try to express that in the type and style of > language that is used in the ISO C standard. > > If that doesn't match what you're looking for, can you say a > bit more about what the differences are? Thanks for the detailed response. Yes, I think you've got the intent. As for wordsmithing, that's tougher. And the people participating in this thread who seem most intimately familiar with the spec language also seem to be the ones most opposed to changing it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-25 07:59 -0700 |
| Message-ID | <86pnqfm246.fsf@mailhub.linuxsc.com> |
| In reply to | #142306 |
Howard Chu <highlandsun@gmail.com> writes: > On Saturday, March 23, 2019 at 2:25:23 PM UTC, Tim Rentsch wrote: > >> [..response on "softening" undefined behavior"..] > > Thanks for the detailed response. Yes, I think you've got the intent. > As for wordsmithing, that's tougher. And the people participating in > this thread who seem most intimately familiar with the spec language > also seem to be the ones most opposed to changing it. I think part of the reactions you've been getting is a reaction to tone rather than to substance. If you wouldn't mind my making a suggestion, start first by getting people to agree in principle to the idea that (at least some) undefined behaviors should be reined in a bit. Start small by picking some of the easier constructions (dereferencing a null pointer might be a good example), breaking off a piece at a time rather than trying to do all the hundreds of undefined behaviors all at once. I agree that how to word it is tougher, but I think it's important to lead off with some text that _might_ go in the Standard, even while acknowledging that you are struggling to find the right wording, and ask for help finding it. The newsgroup being how it is, there will always be naysayers, but I think this approach has a good (or at least fair) chance of getting the ball rolling in a good direction. If you would mind my making a suggestion, I guess you should just ignore that part of my comments. :)
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-04-16 11:13 -0700 |
| Message-ID | <a8225aa1-1316-4bed-a87b-57f9deca32f1@googlegroups.com> |
| In reply to | #142411 |
On Monday, March 25, 2019 at 2:59:31 PM UTC, Tim Rentsch wrote: > Howard Chu <highlandsun@gmail.com> writes: > > > On Saturday, March 23, 2019 at 2:25:23 PM UTC, Tim Rentsch wrote: > > > >> [..response on "softening" undefined behavior"..] > > > > Thanks for the detailed response. Yes, I think you've got the intent. > > As for wordsmithing, that's tougher. And the people participating in > > this thread who seem most intimately familiar with the spec language > > also seem to be the ones most opposed to changing it. > > I think part of the reactions you've been getting is a reaction > to tone rather than to substance. If you wouldn't mind my making > a suggestion, start first by getting people to agree in principle > to the idea that (at least some) undefined behaviors should be > reined in a bit. Start small by picking some of the easier > constructions (dereferencing a null pointer might be a good > example), breaking off a piece at a time rather than trying to do > all the hundreds of undefined behaviors all at once. I agree > that how to word it is tougher, but I think it's important to > lead off with some text that _might_ go in the Standard, even > while acknowledging that you are struggling to find the right > wording, and ask for help finding it. The newsgroup being how > it is, there will always be naysayers, but I think this approach > has a good (or at least fair) chance of getting the ball rolling > in a good direction. > > If you would mind my making a suggestion, I guess you should just > ignore that part of my comments. :) As it turns out, better minds than mine have already addressed these issues, though with little impact on the standards committee. Here are some well written approaches to consider: http://www.yodaiken.com/2018/06/17/three-modest-proposals-for-the-c-standard-wg14/ Another analysis and proposed change is here http://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-c/ There are a number of good writeups on that blog detailing the problems with the spec, but these are the two that actually propose specific changes to the spec.
[toc] | [prev] | [standalone]
Page 14 of 14 — ← Prev page 1 … 12 13 [14]
Back to top | Article view | comp.lang.c
csiph-web