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 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 12:41 -0700 |
| Message-ID | <ed41fbc9-2060-48a5-af42-a77d1318af9a@googlegroups.com> |
| In reply to | #142121 |
On Wednesday, March 20, 2019 at 7:31:37 PM UTC, James Kuyper wrote:
> 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.
Indeed, this isn't that use case. I'd agree that the use case you chose to illustrate with is a poor one.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 14:34 -0700 |
| Message-ID | <b9d077e8-a213-4d9b-8633-166f38f02040@googlegroups.com> |
| In reply to | #142122 |
On Wednesday, March 20, 2019 at 3:41:38 PM UTC-4, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 7:31:37 PM UTC, James Kuyper wrote:
> > 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"?
...
> > > 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.
>
> Indeed, this isn't that use case. I'd agree that the use case you chose to illustrate with is a poor one.
It's a perfectly good use case for illustrating the issue that needs to
be addressed, it's just simplified to the point of meaninglessness. If
you don't like it, replace it with any other example you do like, of
code accessing an array outside of it's length. But keep in mind - the
definition cannot be specific to the particular example you chose - if
the behavior is to be always implementation-defined, that definition
must apply to all cases, not just to ones carefully selected to satisfy
your preferences.
Since you claim that such access should have implementation-defined
behavior, please identify how it should be defined by an implementation
in a way that is more useful than simply calling it "undefined
behavior".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 13:52 -0700 |
| Message-ID | <lnzhppgter.fsf@kst-u.example.com> |
| In reply to | #142119 |
Howard Chu <highlandsun@gmail.com> writes:
> 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:
[...]
>> > 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.
Silently deleting code is not behavior.
Compilers routinely "delete" code (more accurately: don't generate code)
for statements that can never be executed, such as statements following
a return statement.
> 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.
I believe it would be far more difficult to specify that (without
seriously inhibiting optimization) than you think it would be.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 11:04 -0700 |
| Message-ID | <bfae81bf-bd0a-4641-8094-049438de3347@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.
I just realized a couple of points that I should have made in my first
response. The documentation would need to explain what the behavior is
of writing (and reading) past the end, and before the beginning, of ANY
array, whether the storage duration is static, thread, automatic, or
allocated. Your description only applies to things with automatic
storage duration.
Secondly, the documentation for an implementation will NOT be explaining
the behavior of just one particular program - they don't write up fresh
versions of the documentation for each program. Therefore, the
following has no place in the answer I was looking for:
> 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.
In the general case (which an implementation's documentation would be
required to address) which includes subscripting before the beginning
of an array, there might be a great many things at risk of being
overwritten by out-of-bound indexing, not just the return address for
the current function call.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 13:43 -0700 |
| Message-ID | <ln8sx9i8e8.fsf@kst-u.example.com> |
| In reply to | #142114 |
Howard Chu <highlandsun@gmail.com> writes:
> 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:
[...]
>> > > 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.
That doesn't address my question.
>> 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.
Overwriting the contents of the stack is not "behavior". What are
the observable consequences of overwriting the stack? As James
Kuyper says downthread, there's no particular reason those
consequences couldn't include nasal demons.
You said you wanted to replace *all* undefined behavior by
implementation-defined behavior. Replace rand() by a call
to a function that can return a positive or negative value,
where the compiler has no knowledge of what it will return.
Now `array[rand()] = 42` could clobber *anything* in memory.
Assume, for example, that the call is not in main(), and that
the compiler has no idea what the status of the stack is when the
assignment is evaluated.
> 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.
But in general, no implementation-specific description of the
behavior is really an improvement over the current status, where
the behavior is undefined.
--
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 | fir is a sexy shemale <cdalten@gmail.com> |
|---|---|
| Date | 2019-03-19 16:57 -0700 |
| Message-ID | <225fcf0a-b16b-4fbe-b773-8685cfe000fc@googlegroups.com> |
| In reply to | #142080 |
Somewhere a Christian Church is missing its Central Limit Theorem.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-20 05:45 +0000 |
| Message-ID | <yDpYuPXgbPvO0TB2QttltgH9QFlBQ@bongo-ra.co> |
| In reply to | #142080 |
On Tue, 19 Mar 2019 14:58:43 -0700 (PDT)
Howard Chu <highlandsun@gmail.com> wrote:
> 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.
You can put near the beginning of your code
int main ( ...... ) {
......
if ((-1 & 3) != 3) {
fprintf(stderr , "This programme only works with two's complement "
"integer representation\n") ;
return EXIT_FAILURE ;
}
......
}
No change to the standard needed.
> On that topic, it would be nice to see a compiler mode that makes all undefined behaviors implementation defined,
At best unreasonably onerous on compiler writers and likely impossible. To
make the discussion more concrete you should at least pick 2-3 examples of
undefined behaviour in the standard and show us what definition you would
like.
> lets the underlying hardware do whatever it's going to do with them,
I don't know what this means and I suspect it doesn't mean anything. My best
guess is that you assume that for every C construct and every architecture
there is a corresponding sequence of assembly instructions and you're
suggesting that in that compiler mode the compiler should simply emit that
obvious sequence of assembly instructions.
First , I doubt that there is such a correspondence. Perhaps you can think of
one is some cases , like if you have i++ (and even for this there are
complications. Should the value be in a register or is it also ok if it's in
memory ? If it's in memory then it also depends on what addressing modes the
architecture supports) , but in all cases ? I doubt it.
Second , even if there was , it would be useless. With this compiler mode you
suggest , you would need to know , for every C construct and every architecture
your code may run on , what the corresponding sequence of assembly
instructions is and how the processor behaves with that sequence (note that
some sequences of assembly instructions may also have undefined behaviour)
and how that is going to interact with the other constructs in your C code.
This would be way harder than writing the code directly in assembly.
> and most importantly, stops abusing them in the optimizer. E.g., quit allowing compilers to delete NULL-pointer checks
> https://lwn.net/Articles/342420/
Again , it's not clear to me what this means. It's clear what it means in the
specific example of the article but for arbitrary C constructs no.
> 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.
You can declare all your C objects as volatile .This would give you an
approximation to what you want. I doubt you would like the result but you
can try.
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 09:22 -0700 |
| Message-ID | <11b51bdf-7847-40fc-bdf5-b3777f41b4da@googlegroups.com> |
| In reply to | #142087 |
On Wednesday, March 20, 2019 at 5:45:41 AM UTC, Spiros Bousbouras wrote:
> On Tue, 19 Mar 2019 14:58:43 -0700 (PDT)
> Howard Chu <highlandsun@gmail.com> wrote:
> > 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.
>
> You can put near the beginning of your code
>
> int main ( ...... ) {
> ......
> if ((-1 & 3) != 3) {
> fprintf(stderr , "This programme only works with two's complement "
> "integer representation\n") ;
> return EXIT_FAILURE ;
> }
> ......
> }
>
> No change to the standard needed.
Currently,
int32_t i = 1 << 31;
is undefined. Even using uint32_t. But it has a clear meaning: set the high bit of this word. Any CPU in use today would have no trouble performing the expressed operation, the resulting bit pattern is unambiguous. If the language spec declared that all integers are two's complement there would be no reason for this to be undefined.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 14:02 -0700 |
| Message-ID | <lnva0dgsyz.fsf@kst-u.example.com> |
| In reply to | #142108 |
Howard Chu <highlandsun@gmail.com> writes:
[...]
> Currently,
>
> int32_t i = 1 << 31;
>
> is undefined. Even using uint32_t. But it has a clear meaning: set the
> high bit of this word. Any CPU in use today would have no trouble
> performing the expressed operation, the resulting bit pattern is
> unambiguous. If the language spec declared that all integers are two's
> complement there would be no reason for this to be undefined.
A quibble: The expression `1 << 31` would still have undefined behavior
(or at least would overflow) if int is 16 bits. But let's assume you
meant:
int32_t i = INT32_C(1) << 31;
or
int32_t i = 1L << 31;
If the language were changed to require two's-complement, that
would not directly imply anything about the behavior of `1L << 31`.
Making that well defined would have to be an explicit and distinct
change. The C++ proposal does include that change, but it seems to
be controversial. (I haven't read the entire proposal, and I don't
understand the "SF F N A SA" abbreviations used in the poll results.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-20 22:55 +0100 |
| Message-ID | <q6ucrp$sc1$2@dont-email.me> |
| In reply to | #142131 |
On 20/03/2019 22:02, Keith Thompson wrote: > Howard Chu <highlandsun@gmail.com> writes: > [...] >> Currently, >> >> int32_t i = 1 << 31; >> >> is undefined. Even using uint32_t. But it has a clear meaning: set the >> high bit of this word. Any CPU in use today would have no trouble >> performing the expressed operation, the resulting bit pattern is >> unambiguous. If the language spec declared that all integers are two's >> complement there would be no reason for this to be undefined. > > A quibble: The expression `1 << 31` would still have undefined behavior > (or at least would overflow) if int is 16 bits. But let's assume you > meant: > int32_t i = INT32_C(1) << 31; > or > int32_t i = 1L << 31; > > If the language were changed to require two's-complement, that > would not directly imply anything about the behavior of `1L << 31`. > Making that well defined would have to be an explicit and distinct > change. The C++ proposal does include that change, but it seems to > be controversial. (I haven't read the entire proposal, and I don't > understand the "SF F N A SA" abbreviations used in the poll results.) > "Strongly for", "for", "neutral", "against", "strongly against".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 15:15 -0700 |
| Message-ID | <lnr2b1gpll.fsf@kst-u.example.com> |
| In reply to | #142138 |
David Brown <david.brown@hesbynett.no> writes:
> On 20/03/2019 22:02, Keith Thompson wrote:
>> Howard Chu <highlandsun@gmail.com> writes:
>> [...]
>>> Currently,
>>>
>>> int32_t i = 1 << 31;
>>>
>>> is undefined. Even using uint32_t. But it has a clear meaning: set the
>>> high bit of this word. Any CPU in use today would have no trouble
>>> performing the expressed operation, the resulting bit pattern is
>>> unambiguous. If the language spec declared that all integers are two's
>>> complement there would be no reason for this to be undefined.
>>
>> A quibble: The expression `1 << 31` would still have undefined behavior
>> (or at least would overflow) if int is 16 bits. But let's assume you
>> meant:
>> int32_t i = INT32_C(1) << 31;
>> or
>> int32_t i = 1L << 31;
>>
>> If the language were changed to require two's-complement, that
>> would not directly imply anything about the behavior of `1L << 31`.
>> Making that well defined would have to be an explicit and distinct
>> change. The C++ proposal does include that change, but it seems to
>> be controversial. (I haven't read the entire proposal, and I don't
>> understand the "SF F N A SA" abbreviations used in the poll results.)
>>
>
> "Strongly for", "for", "neutral", "against", "strongly against".
Thanks.
The relevant poll in the C++ proposal is:
Left shift should be the same for signed and unsigned (overrides
previous poll).
which presumably means that 1<<31 would be well defined for 32-bit
two's-complement int (it would yield -2**31). The voting was:
Strongly for: 6
For: 5
Neutral: 5
Against: 0
Strongly against: 1
So it's not as controversial as I thought it was.
The proposed wording is:
The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated
bits are zero-filled. The value of the result is E1×2^E2, reduced
modulo 2^N, where N is the number of value bits in the result type.
(^, of course denotes a superscript/exponentiation.)
One advantage of requiring two's-complement is that it makes some things
possible to describe more briefly in the standard.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html
--
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-20 23:56 +0000 |
| Message-ID | <87bm25yub0.fsf@bsb.me.uk> |
| In reply to | #142144 |
Keith Thompson <kst-u@mib.org> writes: <cut> > The relevant poll in the C++ proposal is: > > Left shift should be the same for signed and unsigned (overrides > previous poll). > > which presumably means that 1<<31 would be well defined for 32-bit > two's-complement int (it would yield -2**31). The voting was: > > Strongly for: 6 > For: 5 > Neutral: 5 > Against: 0 > Strongly against: 1 > > So it's not as controversial as I thought it was. > > The proposed wording is: > > The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are zero-filled. The value of the result is E1×2^E2, reduced > modulo 2^N, where N is the number of value bits in the result > type. Doesn't that make 1 << 31 yield 0 for 32-bit signed int? The results would also be rather "unexpected" for smaller shifts of negative numbers (e.g. -1 << 0 would be 2147483647 AKA 0x7fffffff). <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 17:52 -0700 |
| Message-ID | <lnmulpgiby.fsf@kst-u.example.com> |
| In reply to | #142155 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> The proposed wording is:
>>
>> The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated
>> bits are zero-filled. The value of the result is E1×2^E2, reduced
>> modulo 2^N, where N is the number of value bits in the result
>> type.
>
> Doesn't that make 1 << 31 yield 0 for 32-bit signed int? The results
> would also be rather "unexpected" for smaller shifts of negative numbers
> (e.g. -1 << 0 would be 2147483647 AKA 0x7fffffff).
>
> <cut>
Yes, it does. I made some lazy and incorrect assumptions.
I think the intent is that the << operator should operate on bits in the
same way for signed and unsigned types. For 32-bit unsigned int, 1U<<31
yields 2147483648. That bit pattern represents -2147483648 in 32-bit
signed int, but the wording I quoted would reduce that modulo
2147483648, yielding 0.
Using gcc on my system, 1<<31 yields -2147483648 (though the behavior is
undefined).
Either the proposal is inconsistent (perhaps just in this case?) or I'm
misreading it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 11:08 +0100 |
| Message-ID | <q6vnqf$khh$1@dont-email.me> |
| In reply to | #142144 |
On 20/03/2019 23:15, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 20/03/2019 22:02, Keith Thompson wrote: >>> Howard Chu <highlandsun@gmail.com> writes: >>> [...] >>>> Currently, >>>> >>>> int32_t i = 1 << 31; >>>> >>>> is undefined. Even using uint32_t. But it has a clear meaning: set the >>>> high bit of this word. Any CPU in use today would have no trouble >>>> performing the expressed operation, the resulting bit pattern is >>>> unambiguous. If the language spec declared that all integers are two's >>>> complement there would be no reason for this to be undefined. >>> >>> A quibble: The expression `1 << 31` would still have undefined behavior >>> (or at least would overflow) if int is 16 bits. But let's assume you >>> meant: >>> int32_t i = INT32_C(1) << 31; >>> or >>> int32_t i = 1L << 31; >>> >>> If the language were changed to require two's-complement, that >>> would not directly imply anything about the behavior of `1L << 31`. >>> Making that well defined would have to be an explicit and distinct >>> change. The C++ proposal does include that change, but it seems to >>> be controversial. (I haven't read the entire proposal, and I don't >>> understand the "SF F N A SA" abbreviations used in the poll results.) >>> >> >> "Strongly for", "for", "neutral", "against", "strongly against". > > Thanks. > > The relevant poll in the C++ proposal is: > > Left shift should be the same for signed and unsigned (overrides > previous poll). > > which presumably means that 1<<31 would be well defined for 32-bit > two's-complement int (it would yield -2**31). The voting was: > > Strongly for: 6 > For: 5 > Neutral: 5 > Against: 0 > Strongly against: 1 > > So it's not as controversial as I thought it was. > > The proposed wording is: > > The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated > bits are zero-filled. The value of the result is E1×2^E2, reduced > modulo 2^N, where N is the number of value bits in the result type. > > (^, of course denotes a superscript/exponentiation.) > > One advantage of requiring two's-complement is that it makes some things > possible to describe more briefly in the standard. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html > I think there polls reflect a common pattern here. First, there are always one or two people who fight for the status quo, or who fight for the "little people" - the Unisys programmers, the 14-bit char DSP's, the hypothetical future processors. When it comes to implementation-defined behaviours, the guiding points seem to be - Is there an overwhelming consensus amongst existing implementations about how this is handled? Is there an assumption amongst programmers about this behaviour? Is a fully defined behaviour potentially useful? Can it be clearly and simple defined? When the answers here are yes, there is favour for the change. That would apply here to shifts of signed integers - define signed shifts to give the same result as if you had converted to unsigned, done the shift, and converted back to signed. (This of course requires a fixed definition for conversion from unsigned to signed.) For undefined behaviours, the guiding points are similar but have some extra issues - Is there an efficiency or optimisation advantage in keeping the behaviour undefined? Is there an analysis and error-checking advantage in keeping it undefined? Would defining the behaviour give a result that would be "correct" according to likely programmer intentions? So here, defining behaviour for signed integer overflow clearly fails. More controversial questions might include the behaviour of (x << 32), assuming 32-bit ints. It is currently undefined - but it would be simple and useful to define the result as 0. However, on some targets that would mean existing code would be less efficient.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-20 22:54 +0100 |
| Message-ID | <q6ucr8$sc1$1@dont-email.me> |
| In reply to | #142108 |
On 20/03/2019 17:22, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 5:45:41 AM UTC, Spiros Bousbouras wrote:
>> On Tue, 19 Mar 2019 14:58:43 -0700 (PDT)
>> Howard Chu <highlandsun@gmail.com> wrote:
>>> 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.
>>
>> You can put near the beginning of your code
>>
>> int main ( ...... ) {
>> ......
>> if ((-1 & 3) != 3) {
>> fprintf(stderr , "This programme only works with two's complement "
>> "integer representation\n") ;
>> return EXIT_FAILURE ;
>> }
>> ......
>> }
>>
>> No change to the standard needed.
>
> Currently,
>
> int32_t i = 1 << 31;
>
> is undefined. Even using uint32_t. But it has a clear meaning: set
> the high bit of this word.
In C, it does not have a clear meaning - it has no meaning (unless "int"
is greater than 32 bits). The thing about programming, is that you have
to understand the language and follow its rules. A program is a
contract between the programmer and the compiler - the programmer
promises to follow the rules of the language, and the compiler promises
to deliver object code that implements the program given. If you write
something that is undefined (meaning it is undefined by the C standard
and not defined by the particular compiler implementation you are
using), then you have broken your side of the agreement. All bets are off.
When you read that code, you may personally form a clear meaning of what
you think the programmer wanted to achieve, but it is not what the
programmer wrote.
When I read the code, I interpret it as indicating that the programmer
doesn't understand the details of the language, so I should be wary of
the code.
> Any CPU in use today would have no trouble
> performing the expressed operation, the resulting bit pattern is
> unambiguous. If the language spec declared that all integers are
> two's complement there would be no reason for this to be undefined.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-20 22:22 +0000 |
| Message-ID | <Q2zkE.172267$1p7.137601@fx05.am4> |
| In reply to | #142137 |
On 20/03/2019 21:54, David Brown wrote: > On 20/03/2019 17:22, Howard Chu wrote: >> Currently, >> >> int32_t i = 1 << 31; >> >> is undefined. Even using uint32_t. But it has a clear meaning: set >> the high bit of this word. > > In C, it does not have a clear meaning - it has no meaning (unless "int" > is greater than 32 bits). This is the problem. Both signed and unsigned shifts tend to use the same shift instruction, so will give the same results (namely, the bit pattern 0x80000000, when ints are at least 32 bits). But C has decreed that the signed version is undefined. Why? Probably because some machines might use some weird representation where such a shift may give a non-meaningful result. Machines that most people have never seen, and never will. Using an 32-bit signed int as though it was just a bit pattern is a little naughty, but so what? In this case it should work. The thing about programming, is that you have > to understand the language and follow its rules. A silly rule in this case. Even if the C program was never going to run on anything other than 32-bit twos complement hardware, you have to keep in mind that an unhelpful compiler might decide you don't mean to write that code because C says it's undefined, and do something completely unexpected.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 15:29 +0100 |
| Message-ID | <q7074k$9v8$1@dont-email.me> |
| In reply to | #142148 |
On 20/03/2019 23:22, Bart wrote: > On 20/03/2019 21:54, David Brown wrote: >> On 20/03/2019 17:22, Howard Chu wrote: > >>> Currently, >>> >>> int32_t i = 1 << 31; >>> >>> is undefined. Even using uint32_t. But it has a clear meaning: set >>> the high bit of this word. >> >> In C, it does not have a clear meaning - it has no meaning (unless >> "int" is greater than 32 bits). > > This is the problem. Both signed and unsigned shifts tend to use the > same shift instruction, so will give the same results (namely, the bit > pattern 0x80000000, when ints are at least 32 bits). > > But C has decreed that the signed version is undefined. You misunderstand. C has decreed that the standards don't define a meaning here - they are not hindering anyone else from making a definition. > > Why? Probably because some machines might use some weird representation > where such a shift may give a non-meaningful result. Machines that most > people have never seen, and never will. There are many reasons for leaving behaviour undefined. The "some machines might do it differently" is not one of them - that is a reason for having implementation-defined behaviour, not undefined behaviour. You /know/ this - it has been explained to you countless times. Why do you persist in spreading this kind of misinformation and misunderstanding? In normal mathematics, if you have a positive integer and multiply it by a power of 2, you cannot get a negative result. In standard C, the same thing applies - precisely because says results that don't fit in an int (or whatever type is appropriate) are meaningless, and are ignored by the language. Many cases of undefined behaviour in C are like this. It has /nothing/ to do with any physical computers for implementing C, but /everything/ to do with the definitions of the operations and types, and the mathematics. So behaviours are "undefined" in C in the same sense, and for the same basic reason, as "1 / 0" is "undefined" in mathematics. > > Using an 32-bit signed int as though it was just a bit pattern is a > little naughty, but so what? In this case it should work. > > > The thing about programming, is that you have >> to understand the language and follow its rules. > > A silly rule in this case. Even if the C program was never going to run > on anything other than 32-bit twos complement hardware, you have to keep > in mind that an unhelpful compiler might decide you don't mean to write > that code because C says it's undefined, and do something completely > unexpected. > Two's complement has absolutely /nothing/ to do with whether or not 1 << 31 is defined.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-21 14:47 +0000 |
| Message-ID | <StNkE.656620$OGY.514303@fx08.am4> |
| In reply to | #142175 |
On 21/03/2019 14:29, David Brown wrote: > On 20/03/2019 23:22, Bart wrote: >> On 20/03/2019 21:54, David Brown wrote: >>> On 20/03/2019 17:22, Howard Chu wrote: >> >>>> Currently, >>>> >>>> int32_t i = 1 << 31; >>>> >>>> is undefined. Even using uint32_t. But it has a clear meaning: set > Two's complement has absolutely /nothing/ to do with whether or not 1 << > 31 is defined. So why is it undefined, assuming the OP was correct?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 22:26 +0100 |
| Message-ID | <q70vhk$7ja$1@dont-email.me> |
| In reply to | #142177 |
On 21/03/2019 15:47, Bart wrote: > On 21/03/2019 14:29, David Brown wrote: >> On 20/03/2019 23:22, Bart wrote: >>> On 20/03/2019 21:54, David Brown wrote: >>>> On 20/03/2019 17:22, Howard Chu wrote: >>> >>>>> Currently, >>>>> >>>>> int32_t i = 1 << 31; >>>>> >>>>> is undefined. Even using uint32_t. But it has a clear meaning: set > >> Two's complement has absolutely /nothing/ to do with whether or not 1 << >> 31 is defined. > > So why is it undefined, assuming the OP was correct? > Didn't you read my post?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-21 22:18 +0000 |
| Message-ID | <65UkE.658777$OGY.651902@fx08.am4> |
| In reply to | #142204 |
On 21/03/2019 21:26, David Brown wrote: > On 21/03/2019 15:47, Bart wrote: >> On 21/03/2019 14:29, David Brown wrote: >>> On 20/03/2019 23:22, Bart wrote: >>>> On 20/03/2019 21:54, David Brown wrote: >>>>> On 20/03/2019 17:22, Howard Chu wrote: >>>> >>>>>> Currently, >>>>>> >>>>>> int32_t i = 1 << 31; >>>>>> >>>>>> is undefined. Even using uint32_t. But it has a clear meaning: set >> >>> Two's complement has absolutely /nothing/ to do with whether or not 1 << >>> 31 is defined. >> >> So why is it undefined, assuming the OP was correct? >> > > Didn't you read my post? I read it. Which bit of it is supposed to answer my question? If it's anything to do with the fact that twos complement only gives you 31 precision bits for positive numbers, which is not enough to represent the mathematically correct result of 1<<31, then it's not clear why it is 'absolutely nothing' to do with it.
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web