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 1 of 14 [1] 2 3 … 14 Next page →
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-19 14:58 -0700 |
| Subject | C wish list |
| Message-ID | <de7f6c95-d2a8-4f26-9416-f72305578c3b@googlegroups.com> |
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 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. 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.
[toc] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-19 15:58 -0700 |
| Message-ID | <lntvfyii8m.fsf@kst-u.example.com> |
| In reply to | #142080 |
Howard Chu <highlandsun@gmail.com> writes:
[...]
> 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.
Here's an example:
#include <stdlib.h>
int main(void) {
int array[10];
array[rand()] = 42;
}
How could an implementation reasonably define the behavior of
that program? In the absence of run-time bounds checking (which
I don't think we want to require), it could clobber either some
user-defined object, or some arbitrary system-specific data, with
arbitrarily bad consequences.
--
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 | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-03-20 08:27 +0200 |
| Message-ID | <d339mf-f0i.ln1@gangtai.home.grep.be> |
| In reply to | #142082 |
On 20/03/2019 00:58, Keith Thompson wrote:
> Howard Chu <highlandsun@gmail.com> writes:
> [...]
>> 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.
>
> Here's an example:
>
> #include <stdlib.h>
> int main(void) {
> int array[10];
> array[rand()] = 42;
> }
>
> How could an implementation reasonably define the behavior of
> that program? In the absence of run-time bounds checking (which
> I don't think we want to require), it could clobber either some
> user-defined object, or some arbitrary system-specific data, with
> arbitrarily bad consequences.
I don't think you need to look at it from that angle.
int main(void) {
int array[10];
array[100] = 42;
}
can be reasonably easily implementation defined. It will have the same
behaviour all the time.
The same will be true for any two values on the second line of the
function body.
Assuming that, the replacement of 100 with a call to a function
returning a random number will have the same implementation-defined
result for whatever number that function returns.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-20 06:54 +0000 |
| Message-ID | <gvTB2QttltgH9QFlBQ@bongo-ra.co> |
| In reply to | #142090 |
On Wed, 20 Mar 2019 08:27:25 +0200
Wouter Verhelst <w@uter.be> wrote:
> On 20/03/2019 00:58, Keith Thompson wrote:
> > Here's an example:
> >
> > #include <stdlib.h>
> > int main(void) {
> > int array[10];
> > array[rand()] = 42;
> > }
> >
> > How could an implementation reasonably define the behavior of
> > that program? In the absence of run-time bounds checking (which
> > I don't think we want to require), it could clobber either some
> > user-defined object, or some arbitrary system-specific data, with
> > arbitrarily bad consequences.
>
> I don't think you need to look at it from that angle.
>
> int main(void) {
> int array[10];
> array[100] = 42;
> }
>
> can be reasonably easily implementation defined. It will have the same
> behaviour all the time.
For example the compiler exiting with
Compilation failed: out of bounds array accessed detected.
and not producing an executable.
> The same will be true for any two values on the second line of the
> function body.
You lost me here. Surely you're not saying that
array[5] = 42;
should behave the same as
array[100] = 42;
It can of course , is this what you're saying ?
> Assuming that, the replacement of 100 with a call to a function
> returning a random number will have the same implementation-defined
> result for whatever number that function returns.
I don't think that with code like
int main(void) {
int array[10];
array[rand()] = 42;
}
the compiler exiting with
Compilation failed: out of bounds array accessed detected.
and not producing an executable would be conforming whereas it is conforming
with array[100] = 42;
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-20 07:00 +0000 |
| Message-ID | <gvTB2Qttltg9HQFlBQ@bongo-ra.co> |
| In reply to | #142091 |
On Wed, 20 Mar 2019 06:54:57 GMT
Spiros Bousbouras <spibou@gmail.com> wrote:
> I don't think that with code like
> int main(void) {
> int array[10];
> array[rand()] = 42;
> }
>
> the compiler exiting with
> Compilation failed: out of bounds array accessed detected.
> and not producing an executable would be conforming
On second thought , it could be conforming if the compiler uses internal
information regarding how rand() behaves. But from an outsider's point
of view , it's not clearly conforming.
> whereas it is conforming
> with array[100] = 42;
Even from an outsider's point of view.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-03-20 13:26 +0200 |
| Message-ID | <njk9mf-4ja.ln1@gangtai.home.grep.be> |
| In reply to | #142091 |
On 20/03/2019 08:54, Spiros Bousbouras wrote:
> On Wed, 20 Mar 2019 08:27:25 +0200
> Wouter Verhelst <w@uter.be> wrote:
>> On 20/03/2019 00:58, Keith Thompson wrote:
>>> Here's an example:
>>>
>>> #include <stdlib.h>
>>> int main(void) {
>>> int array[10];
>>> array[rand()] = 42;
>>> }
>>>
>>> How could an implementation reasonably define the behavior of
>>> that program? In the absence of run-time bounds checking (which
>>> I don't think we want to require), it could clobber either some
>>> user-defined object, or some arbitrary system-specific data, with
>>> arbitrarily bad consequences.
>>
>> I don't think you need to look at it from that angle.
>>
>> int main(void) {
>> int array[10];
>> array[100] = 42;
>> }
>>
>> can be reasonably easily implementation defined. It will have the same
>> behaviour all the time.
>
> For example the compiler exiting with
> Compilation failed: out of bounds array accessed detected.
> and not producing an executable.
I believe Howard's proposal implies that that would not be a valid thing
for a compiler to do.
>> The same will be true for any two values on the second line of the
>> function body.
>
> You lost me here. Surely you're not saying that
> array[5] = 42;
> should behave the same as
> array[100] = 42;
>
> It can of course , is this what you're saying ?
No. The statement
array[5] = 42;
will have a particular behaviour, which will always be the same as long
as the two numbers do not change (in casu, the sixth element of the
array will be set to 42). Similarly, the statement
array[100] = 42;
will also have a particular behaviour when compiled and ran, which will
always be the same as long as the two numbers do not change (although
the exact behaviour will depend on the implementation). It might cause a
segfault, or it might change things in ways that it should not, but
there will be some behaviour.
That behaviour, however, will be *exactly* the same when called as
array[rand()] = 42;
if and when the return value of the rand() function is "100".
>> Assuming that, the replacement of 100 with a call to a function
>> returning a random number will have the same implementation-defined
>> result for whatever number that function returns.
>
> I don't think that with code like
> int main(void) {
> int array[10];
> array[rand()] = 42;
> }
>
> the compiler exiting with
> Compilation failed: out of bounds array accessed detected.
> and not producing an executable would be conforming whereas it is conforming
> with array[100] = 42;
True, but that is not what I meant.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 08:17 -0400 |
| Message-ID | <q6tb0j$780$1@dont-email.me> |
| In reply to | #142101 |
On 3/20/19 07:26, Wouter Verhelst wrote:
> On 20/03/2019 08:54, Spiros Bousbouras wrote:
>> On Wed, 20 Mar 2019 08:27:25 +0200
>> Wouter Verhelst <w@uter.be> wrote:
...
>>> int main(void) {
>>> int array[10];
>>> array[100] = 42;
>>> }
>>>
>>> can be reasonably easily implementation defined. It will have the same
>>> behaviour all the time.
...
> array will be set to 42). Similarly, the statement
>
> array[100] = 42;
>
> will also have a particular behaviour when compiled and ran, which will
> always be the same as long as the two numbers do not change (although
> the exact behaviour will depend on the implementation). It might cause a
> segfault, or it might change things in ways that it should not, but
> there will be some behaviour.
But implementation-defined means an implementation would be required to
document what that behavior will be. How would you write the
corresponding documentation? Assume a fairly conventional implementation
of C, and give me what you think that implementation's documentation
should say about such things. Please provide the exact words, not just a
vague description of what the words would be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 13:20 -0700 |
| Message-ID | <lnh8bxi9hg.fsf@kst-u.example.com> |
| In reply to | #142103 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 3/20/19 07:26, Wouter Verhelst wrote:
>> On 20/03/2019 08:54, Spiros Bousbouras wrote:
>>> On Wed, 20 Mar 2019 08:27:25 +0200
>>> Wouter Verhelst <w@uter.be> wrote:
> ...
>>>> int main(void) {
>>>> int array[10];
>>>> array[100] = 42;
>>>> }
>>>>
>>>> can be reasonably easily implementation defined. It will have the same
>>>> behaviour all the time.
> ...
>> array will be set to 42). Similarly, the statement
>>
>> array[100] = 42;
>>
>> will also have a particular behaviour when compiled and ran, which will
>> always be the same as long as the two numbers do not change (although
>> the exact behaviour will depend on the implementation). It might cause a
>> segfault, or it might change things in ways that it should not, but
>> there will be some behaviour.
>
> But implementation-defined means an implementation would be required to
> document what that behavior will be. How would you write the
> corresponding documentation? Assume a fairly conventional implementation
> of C, and give me what you think that implementation's documentation
> should say about such things. Please provide the exact words, not just a
> vague description of what the words would be.
That's pretty much what I would have said.
In almost any existing implementation, `array[100] = 42;` could
crash the program or corrupt arbitrary data. The latter could cause
the program to crash some time later or produce incorrect output.
I'm having trouble imagining how an implementation could define its
behavior in a way that usefully distinguishes it from undefined
behavior (unless the implementation adds potentially expensive
run-time checks).
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 01:43 -0700 |
| Message-ID | <lnpnqmhr5m.fsf@kst-u.example.com> |
| In reply to | #142090 |
Wouter Verhelst <w@uter.be> writes:
> On 20/03/2019 00:58, Keith Thompson wrote:
>> Howard Chu <highlandsun@gmail.com> writes:
>> [...]
>>> 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.
>>
>> Here's an example:
>>
>> #include <stdlib.h>
>> int main(void) {
>> int array[10];
>> array[rand()] = 42;
>> }
>>
>> How could an implementation reasonably define the behavior of
>> that program? In the absence of run-time bounds checking (which
>> I don't think we want to require), it could clobber either some
>> user-defined object, or some arbitrary system-specific data, with
>> arbitrarily bad consequences.
>
> I don't think you need to look at it from that angle.
>
> int main(void) {
> int array[10];
> array[100] = 42;
> }
That's what I wrote in an initial draft (before I posted it).
I decided to use rand() to avoid the issue of the error being
detectable at compile time.
> can be reasonably easily implementation defined. It will have the same
> behaviour all the time.
And what behavior is that?
> The same will be true for any two values on the second line of the
> function body.
>
> Assuming that, the replacement of 100 with a call to a function
> returning a random number will have the same implementation-defined
> result for whatever number that function returns.
An implementation *could* emit code to do run-time index checking,
and (for example) abort the program if the index is out of range --
but we can't require *all* C implementations to do that. (We can
have a language that requires safe array indexing, but it's not
reasonable to call that language "C".) In the absence of run-time
checking, either `array[rand()] = 42` or `array[100] = 42` is going
to clobber something, or trigger a system trap, or *something*.
Implementation-defined behavior requires the standard to provide
two or more possibilities, and the implementation to dcument which
one it chose.
--
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 13:11 +0000 |
| Message-ID | <UZqkE.134383$oz4.82434@fx04.iad> |
| In reply to | #142090 |
Wouter Verhelst <w@uter.be> writes:
>On 20/03/2019 00:58, Keith Thompson wrote:
>> Howard Chu <highlandsun@gmail.com> writes:
>> [...]
>>> 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.
>>
>> Here's an example:
>>
>> #include <stdlib.h>
>> int main(void) {
>> int array[10];
>> array[rand()] = 42;
>> }
>>
>> How could an implementation reasonably define the behavior of
>> that program? In the absence of run-time bounds checking (which
>> I don't think we want to require), it could clobber either some
>> user-defined object, or some arbitrary system-specific data, with
>> arbitrarily bad consequences.
>
>I don't think you need to look at it from that angle.
>
>int main(void) {
> int array[10];
> array[100] = 42;
>}
>
>can be reasonably easily implementation defined. It will have the same
>behaviour all the time.
Will it? Even in the presence of address space layout randomization
at exec() time?
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 09:17 -0700 |
| Message-ID | <ad667853-007a-48d1-b45e-0fb7bbcf3780@googlegroups.com> |
| In reply to | #142082 |
On Tuesday, March 19, 2019 at 10:58:57 PM UTC, Keith Thompson wrote:
> Howard Chu <highlandsun@gmail.com> writes:
> [...]
> > 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.
>
> Here's an example:
>
> #include <stdlib.h>
> int main(void) {
> int array[10];
> array[rand()] = 42;
> }
>
> How could an implementation reasonably define the behavior of
> that program? In the absence of run-time bounds checking (which
> I don't think we want to require), it could clobber either some
> user-defined object, or some arbitrary system-specific data, with
> arbitrarily bad consequences.
So what? It's not the *language spec's* job to prevent programmers from writing bad code.
Infinite loops may be bad in a lot of cases, but if the programmer wants one, the language shouldn't get in the way and stop it.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 09:34 -0700 |
| Message-ID | <6b987b94-3a9a-42d8-8542-eefb94a7e3d3@googlegroups.com> |
| In reply to | #142107 |
On Wednesday, March 20, 2019 at 12:17:32 PM UTC-4, Howard Chu wrote:
> On Tuesday, March 19, 2019 at 10:58:57 PM UTC, Keith Thompson wrote:
> > Howard Chu <highlandsun@gmail.com> writes:
> > [...]
> > > 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.
> >
> > Here's an example:
> >
> > #include <stdlib.h>
> > int main(void) {
> > int array[10];
> > array[rand()] = 42;
> > }
> >
> > How could an implementation reasonably define the behavior of
> > that program? In the absence of run-time bounds checking (which
> > I don't think we want to require), it could clobber either some
> > user-defined object, or some arbitrary system-specific data, with
> > arbitrarily bad consequences.
>
> So what? It's not the *language spec's* job to prevent programmers from writing bad code.
This isn't about preventing programmers from writing bad code.
You specified that you wanted the behavior to be implementation-defined.
That means that the implementation must document what the behavior will
be. So what would you want them to write down as the documentation that
covers this case? Please be specific - imagine whatever you would
consider a typical conventional implementation similar to whichever one
is most familiar to you, and write down what you think their
documentation should say about it.
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 10:06 -0700 |
| Message-ID | <449c19d2-2189-4741-bcd1-420102cf0db4@googlegroups.com> |
| In reply to | #142111 |
On Wednesday, March 20, 2019 at 4:35:02 PM UTC, James Kuyper wrote:
> On Wednesday, March 20, 2019 at 12:17:32 PM UTC-4, Howard Chu wrote:
> > On Tuesday, March 19, 2019 at 10:58:57 PM UTC, Keith Thompson wrote:
> > > Howard Chu <highlandsun@gmail.com> writes:
> > > [...]
> > > > 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.
> > >
> > > Here's an example:
> > >
> > > #include <stdlib.h>
> > > int main(void) {
> > > int array[10];
> > > array[rand()] = 42;
> > > }
> > >
> > > How could an implementation reasonably define the behavior of
> > > that program? In the absence of run-time bounds checking (which
> > > I don't think we want to require), it could clobber either some
> > > user-defined object, or some arbitrary system-specific data, with
> > > arbitrarily bad consequences.
> >
> > So what? It's not the *language spec's* job to prevent programmers from writing bad code.
>
> This isn't about preventing programmers from writing bad code.
>
> You specified that you wanted the behavior to be implementation-defined.
> That means that the implementation must document what the behavior will
> be. So what would you want them to write down as the documentation that
> covers this case? Please be specific - imagine whatever you would
> consider a typical conventional implementation similar to whichever one
> is most familiar to you, and write down what you think their
> documentation should say about it.
OK, for this particular example, assuming a 32 bit CPU and a typical address space split of lower 2GB for user space and upper 2GB for kernel space, and a stack that grows downward from top of user space - referencing past the bounds of this array may overwrite the contents of the stack, and if the reference goes past the bounds of the stack, it will trigger a SIGSEGV.
Again, for this particular example, since it's being invoked from main() with no parameters, the actual contents of the stack wouldn't be much more than a single return address to the C runtime startup library.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 10:47 -0700 |
| Message-ID | <c0ff3cc6-b8ad-4c98-bb07-98cc817e15f7@googlegroups.com> |
| In reply to | #142114 |
On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 4:35:02 PM UTC, James Kuyper wrote:
> > On Wednesday, March 20, 2019 at 12:17:32 PM UTC-4, Howard Chu wrote:
> > > On Tuesday, March 19, 2019 at 10:58:57 PM UTC, Keith Thompson wrote:
> > > > Howard Chu <highlandsun@gmail.com> writes:
> > > > [...]
> > > > > 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.
> > > >
> > > > Here's an example:
> > > >
> > > > #include <stdlib.h>
> > > > int main(void) {
> > > > int array[10];
> > > > array[rand()] = 42;
> > > > }
> > > >
> > > > How could an implementation reasonably define the behavior of
> > > > that program? In the absence of run-time bounds checking (which
> > > > I don't think we want to require), it could clobber either some
> > > > user-defined object, or some arbitrary system-specific data, with
> > > > arbitrarily bad consequences.
> > >
> > > So what? It's not the *language spec's* job to prevent programmers from writing bad code.
> >
> > This isn't about preventing programmers from writing bad code.
> >
> > You specified that you wanted the behavior to be implementation-defined.
> > That means that the implementation must document what the behavior will
> > be. So what would you want them to write down as the documentation that
> > covers this case? Please be specific - imagine whatever you would
> > consider a typical conventional implementation similar to whichever one
> > is most familiar to you, and write down what you think their
> > documentation should say about it.
>
> OK, for this particular example, assuming a 32 bit CPU and a typical address space split of lower 2GB for user space and upper 2GB for kernel space, and a stack that grows downward from top of user space - referencing past the bounds of this array may overwrite the contents of the stack, and if the reference goes past the bounds of the stack, it will trigger a SIGSEGV.
>
> Again, for this particular example, since it's being invoked from main() with no parameters, the actual contents of the stack wouldn't be much more than a single return address to the C runtime startup library.
OK - now how is that an improvement over saying "the behavior is undefined"?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-20 17:59 +0000 |
| Message-ID | <gcvkE.214509$DX5.38859@fx16.am4> |
| In reply to | #142115 |
On 20/03/2019 17:47, James Kuyper wrote: > On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote: >> OK, for this particular example, assuming a 32 bit CPU and a typical address space split of lower 2GB for user space and upper 2GB for kernel space, and a stack that grows downward from top of user space - referencing past the bounds of this array may overwrite the contents of the stack, and if the reference goes past the bounds of the stack, it will trigger a SIGSEGV. >> >> Again, for this particular example, since it's being invoked from main() with no parameters, the actual contents of the stack wouldn't be much more than a single return address to the C runtime startup library. > > OK - now how is that an improvement over saying "the behavior is undefined"? > It will rule out nasal daemons for a start. Alternatively, an implementation can ensure that such an out-of-bounds access will behave predictably and safely. What the OP has it mind might simply be for things like integer overflow to be well-defined and guaranteed to behave exactly as it already does on 99.99% of machines.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 11:12 -0700 |
| Message-ID | <506d0b65-da9c-4ea2-8208-44545a80fb12@googlegroups.com> |
| In reply to | #142116 |
On Wednesday, March 20, 2019 at 1:59:49 PM UTC-4, Bart wrote: > On 20/03/2019 17:47, James Kuyper wrote: > > On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote: > > >> OK, for this particular example, assuming a 32 bit CPU and a typical address space split of lower 2GB for user space and upper 2GB for kernel space, and a stack that grows downward from top of user space - referencing past the bounds of this array may overwrite the contents of the stack, and if the reference goes past the bounds of the stack, it will trigger a SIGSEGV. > >> > >> Again, for this particular example, since it's being invoked from main() with no parameters, the actual contents of the stack wouldn't be much more than a single return address to the C runtime startup library. > > > > OK - now how is that an improvement over saying "the behavior is undefined"? > > > > It will rule out nasal daemons for a start. He's documented that it could result in overwriting the the return address of the function. Therefore, when the function returns, it might cause a jump to the sumon_nasal_demons() function. So no, it does not rule out nasal demons. That's the whole point. There's virtually nothing that a computer program could be written to do that would be a prohibited result from passing control to an arbitrary address. So again, how does that meaningfully differ from "the behavior is undefined"? > Alternatively, an implementation can ensure that such an out-of-bounds > access will behave predictably and safely. Then the documentation needs to explain that predictable and safe behavior - and any such predictable and safe behavior would require run-time bounds checking, as Keith pointed out, which Howard denied.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 13:47 -0700 |
| Message-ID | <ln4l7xi887.fsf@kst-u.example.com> |
| In reply to | #142116 |
Bart <bc@freeuk.com> writes:
> On 20/03/2019 17:47, James Kuyper wrote:
>> On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote:
>
>>> OK, for this particular example, assuming a 32 bit CPU and a typical
>>> address space split of lower 2GB for user space and upper 2GB for
>>> kernel space, and a stack that grows downward from top of user space
>>> - referencing past the bounds of this array may overwrite the
>>> contents of the stack, and if the reference goes past the bounds of
>>> the stack, it will trigger a SIGSEGV.
>>>
>>> Again, for this particular example, since it's being invoked from
>>> main() with no parameters, the actual contents of the stack wouldn't
>>> be much more than a single return address to the C runtime startup
>>> library.
>>
>> OK - now how is that an improvement over saying "the behavior is undefined"?
>>
>
> It will rule out nasal daemons for a start.
No more than they're already ruled out.
> Alternatively, an implementation can ensure that such an out-of-bounds
> access will behave predictably and safely.
Sure, but nobody here is proposing that *all* C implementations should
be required to implement run-time bounds checking.
> What the OP has it mind might simply be for things like integer overflow
> to be well-defined and guaranteed to behave exactly as it already does
> on 99.99% of machines.
No, that's not what the OP said. Upthread, Howard Chu wrote:
On that topic, it would be nice to see a compiler mode that makes all
undefined behaviors implementation defined ...
If you just want to make signed integer overflow well defined
(presumably with two's-complement wraparound behavior), that's a much
more reasonable proposal.
--
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 | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 11:46 -0700 |
| Message-ID | <6052be2f-5f0e-446f-ad61-487a668d9abb@googlegroups.com> |
| In reply to | #142115 |
On Wednesday, March 20, 2019 at 5:47:58 PM UTC, James Kuyper wrote:
> On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote:
> > On Wednesday, March 20, 2019 at 4:35:02 PM UTC, James Kuyper wrote:
> > > On Wednesday, March 20, 2019 at 12:17:32 PM UTC-4, Howard Chu wrote:
> > > > On Tuesday, March 19, 2019 at 10:58:57 PM UTC, Keith Thompson wrote:
> > > > > Howard Chu <highlandsun@gmail.com> writes:
> > > > > [...]
> > > > > > 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.
> > > > >
> > > > > Here's an example:
> > > > >
> > > > > #include <stdlib.h>
> > > > > int main(void) {
> > > > > int array[10];
> > > > > array[rand()] = 42;
> > > > > }
> > > > >
> > > > > How could an implementation reasonably define the behavior of
> > > > > that program? In the absence of run-time bounds checking (which
> > > > > I don't think we want to require), it could clobber either some
> > > > > user-defined object, or some arbitrary system-specific data, with
> > > > > arbitrarily bad consequences.
> > > >
> > > > So what? It's not the *language spec's* job to prevent programmers from writing bad code.
> > >
> > > This isn't about preventing programmers from writing bad code.
> > >
> > > You specified that you wanted the behavior to be implementation-defined.
> > > That means that the implementation must document what the behavior will
> > > be. So what would you want them to write down as the documentation that
> > > covers this case? Please be specific - imagine whatever you would
> > > consider a typical conventional implementation similar to whichever one
> > > is most familiar to you, and write down what you think their
> > > documentation should say about it.
> >
> > OK, for this particular example, assuming a 32 bit CPU and a typical address space split of lower 2GB for user space and upper 2GB for kernel space, and a stack that grows downward from top of user space - referencing past the bounds of this array may overwrite the contents of the stack, and if the reference goes past the bounds of the stack, it will trigger a SIGSEGV.
> >
> > Again, for this particular example, since it's being invoked from main() with no parameters, the actual contents of the stack wouldn't be much more than a single return address to the C runtime startup library.
>
> OK - now how is that an improvement over saying "the behavior is undefined"?
The improvement is that a compiler can't just silently delete the code.
Note that overwriting the stack return address is a commonly used mechanism for implementing co-routines. The behavior is completely safe and deterministic in those use cases.
It may be simpler to rephrase this wish as: compilers must not silently delete code that triggers undefined behaviors; optimizers must not assume undefined behaviors cannot occur.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-20 19:21 +0000 |
| Message-ID | <cpwkE.636272$Apg.399076@fx36.am4> |
| In reply to | #142119 |
On 20/03/2019 18:46, Howard Chu wrote: > On Wednesday, March 20, 2019 at 5:47:58 PM UTC, James Kuyper wrote: >> OK - now how is that an improvement over saying "the behavior is undefined"? > > The improvement is that a compiler can't just silently delete the code. > > Note that overwriting the stack return address is a commonly used mechanism for implementing co-routines. The behavior is completely safe and deterministic in those use cases. > > It may be simpler to rephrase this wish as: compilers must not silently delete code that triggers undefined behaviors; optimizers must not assume undefined behaviors cannot occur. Agreed. I've sometimes deliberately read from out-of-bound arrays elements, on an implementation that I knew would give me access to the stack. And I can see a use for writing to such elements too (although perhaps not for writing to an random element that may also be outside the stack). That doesn't matter: a compiler shouldn't dismiss all such accesses that just starting doing what it likes.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 12:31 -0700 |
| Message-ID | <71e9ba81-898a-477f-8cbf-ce5a8257bdf8@googlegroups.com> |
| In reply to | #142119 |
On Wednesday, March 20, 2019 at 2:47:03 PM UTC-4, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 5:47:58 PM UTC, James Kuyper wrote:
> > On Wednesday, March 20, 2019 at 1:06:26 PM UTC-4, Howard Chu wrote:
> > > On Wednesday, March 20, 2019 at 4:35:02 PM UTC, James Kuyper wrote:
> > > > On Wednesday, March 20, 2019 at 12:17:32 PM UTC-4, Howard Chu wrote:
> > > > > On Tuesday, March 19, 2019 at 10:58:57 PM UTC, Keith Thompson wrote:
> > > > > > Howard Chu <highlandsun@gmail.com> writes:
> > > > > > [...]
> > > > > > > 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.
> > > > > >
> > > > > > Here's an example:
> > > > > >
> > > > > > #include <stdlib.h>
> > > > > > int main(void) {
> > > > > > int array[10];
> > > > > > array[rand()] = 42;
> > > > > > }
> > > > > >
> > > > > > How could an implementation reasonably define the behavior of
> > > > > > that program? In the absence of run-time bounds checking (which
> > > > > > I don't think we want to require), it could clobber either some
> > > > > > user-defined object, or some arbitrary system-specific data, with
> > > > > > arbitrarily bad consequences.
> > > > >
> > > > > So what? It's not the *language spec's* job to prevent programmers from writing bad code.
> > > >
> > > > This isn't about preventing programmers from writing bad code.
> > > >
> > > > You specified that you wanted the behavior to be implementation-defined.
> > > > That means that the implementation must document what the behavior will
> > > > be. So what would you want them to write down as the documentation that
> > > > covers this case? Please be specific - imagine whatever you would
> > > > consider a typical conventional implementation similar to whichever one
> > > > is most familiar to you, and write down what you think their
> > > > documentation should say about it.
> > >
> > > OK, for this particular example, assuming a 32 bit CPU and a typical address space split of lower 2GB for user space and upper 2GB for kernel space, and a stack that grows downward from top of user space - referencing past the bounds of this array may overwrite the contents of the stack, and if the reference goes past the bounds of the stack, it will trigger a SIGSEGV.
> > >
> > > Again, for this particular example, since it's being invoked from main() with no parameters, the actual contents of the stack wouldn't be much more than a single return address to the C runtime startup library.
> >
> > OK - now how is that an improvement over saying "the behavior is undefined"?
>
> The improvement is that a compiler can't just silently delete the code.
Why would that matter? The consequences of this "defined" behavior can
be arbitrarily bad, and in general there's no way the developer can
predict what they will be. One of the many possible consequences might
be that the code might end up having precisely the same effect as if
it had been deleted (that could happen, for instance, as a result of
randomly jumping to an address which happens to contain instructions
that undo what the code did). How is that an improvement?
> Note that overwriting the stack return address is a commonly used mechanism for implementing co-routines. The behavior is completely safe and deterministic in those use cases.
This isn't that use case - it's randomly and unreliably overwriting the
return address.
[toc] | [prev] | [next] | [standalone]
Page 1 of 14 [1] 2 3 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web