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 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-23 16:51 +0100 |
| Message-ID | <q75kmv$6kv$1@dont-email.me> |
| In reply to | #142281 |
On 23/03/2019 14:33, Bart wrote: > On 22/03/2019 20:54, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 22/03/2019 19:29, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >> [...] >>>>> Take my example, and say f() returns 0xFFFFFFFF_00000000 in 64-bit >>>>> register R0. The bottom half is stored to x, so x contains 0. >>>>> >>>>> The next line is: >>>>> >>>>> int32_t y = x>>8; >>>>> >>>>> because R0 could still contain 0xFFFFFFFF_00000000, David Brown is >>>>> suggesting that a compiler might make use of that existing value, and >>>>> because this processor only has 64-bit ops, it will right shift all 64 >>>>> bits to end up with 0x00FFFFFF_FF000000. >>>> >>>> I don't remember what David suggested. >>> >>> Read his posts today (Mar-22) at 13:26 and 15:10 GMT. He was trying to >>> explain why a machine with only 64-bit registers and operations (so >>> that intermediate calculations, even for int32, are necessarily >>> 64-bits) might give different results. >> >> David was discussing this example: >> >> int x = 1 << 31; >> int y = x / 5; >> > > This is from the man himself: > > BC (me): > >> You [DB] are saying that here: > >> > >> int32_t x = f(); > >> int32_t y = <some expression involving x, such as x>>8> > >> > >> it is acceptable to use a 64-bit version of x, even though x is only > >> 32 bits, because it's using a value left over in a 64-bit register > >> from some immediately prior calculation of x. > Yes, when you have undefined behaviour! Once you have written "int x = 1 << 31;", then /anything/ afterwards is allowed. /Anything/. The compiler can do whatever it wants. As I have explained, the compiler can take advantage of this leeway to generate better code. So following "int x = a << b;", the compiler can assume that "a" was a non-negative integer, that "b" is between 0 at 30 or that "a" is 0 and "b" is 31, and that "a << b" does not overflow the signed int. So if a cpu loads "a" into a 64-bit register, using sign extension or zero extension, and executes a 64-bit left shift instruction, then it will have 0 in the upper half of the register. The compiler knows this for a fact - because anything else would have been undefined behaviour. Dividing by 5, or shifting right by 8, can thus be done as a 64-bit operation using the full 64-bit register, if that is what is most efficient. You will get the correct answer out if you put valid numbers in at the start. If you put in rubbish, you can expect rubbish out. > DB: > > Ignoring your somewhat jumbled syntax (I can't figure out if it is > > supposed to be a smiley, or what it is), then yes. > > KT again: > > which has undefined behavior (again, assuming 32-bit int). Your example > > does not have undefined behavior. > > Imagine that the f(x) in my example returned the value of 1<<31 as an > int32_t type. However, I can see that it would make much difference. The value 1 << 31 does not exist. That is the crux of your problem. > > Could a compiler really be so sloppy as to disallow garbage from an > unused parts of a register to affect calculations, but not be bothered > when it thinks it's undefined behaviour? It is not "sloppy" - it is about efficiency. A compiler will be very careful about garbage that might be in a register if that would affect valid calculations - and can happily ignore it if it cannot affect valid calculations. > > In any case I disagree that 1<<31 should be undefined, It's fine if you disagree that 1 << 31 should be undefined behaviour. What is important is that you understand that it /is/ undefined behaviour, even if you disagree with that decision. (It would be nice if you could also understand /why/ it is undefined - that would greatly help your understanding of C.) > and I think this > is the point of the thread. I think that post of yours about C++ suggest > many feel the same. The fact that so many C compilers deal with that as > expected (except maybe David Brown's DEC Alpha, although we have no > actual evidence) also supports that. > Many compilers define additional behaviour of shifts, beyond the requirements of C. And of course, even when behaviour is undefined, the code generated by a compiler might happen to give results consistent with a particular definition. For example, gcc makes additional guarantees about shifting negative numbers (though the documentation is rather weak on saying what those guarantees are!). I'd slightly prefer it left these undefined, but I'm not particularly fussy. I'm not a fan of writing code that gives meaningless results, even if they happen to be defined by the standards or by the implementation, so I don't write such code anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 18:34 +0000 |
| Message-ID | <7%ulE.738560$RBa.493918@fx15.am4> |
| In reply to | #142291 |
On 23/03/2019 15:51, David Brown wrote: >> >> int32_t x = f(); >> >> int32_t y = <some expression involving x, such as x>>8> >> >> >> >> it is acceptable to use a 64-bit version of x, even though x is only >> >> 32 bits, because it's using a value left over in a 64-bit register >> >> from some immediately prior calculation of x. >> > > Yes, when you have undefined behaviour! Once you have written "int x = > 1 << 31;", then /anything/ afterwards is allowed. /Anything/. The > compiler can do whatever it wants. No. Suppose that those two lines are compiled today, and the function f() is external, which might be compiled tomorrow. There is no evidence of UB, so there should be no reason for the 64-bit version of 'x' in 'x>>8' to be anything other than its cleanly sign-extended. When f() is finally compiled, /that/ might have UB, perhaps in a form detectable by the compiler. But that is too late to influence the first lot of code. > As I have explained, the compiler can take advantage of this leeway to > generate better code. So following "int x = a << b;", the compiler can > assume that "a" was a non-negative integer, that "b" is between 0 at 30 > or that "a" is 0 and "b" is 31, and that "a << b" does not overflow the > signed int. > > So if a cpu loads "a" into a 64-bit register, using sign extension or > zero extension, and executes a 64-bit left shift instruction, then it > will have 0 in the upper half of the register. The compiler knows this > for a fact - because anything else would have been undefined behaviour. I thought it was C that determines whether something is undefined behaviour. And C cannot know what sizes of registers are to be used.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 16:48 +0100 |
| Message-ID | <q788ru$86g$1@dont-email.me> |
| In reply to | #142305 |
On 23/03/2019 19:34, Bart wrote: > On 23/03/2019 15:51, David Brown wrote: > >>> >> int32_t x = f(); >>> >> int32_t y = <some expression involving x, such as x>>8> >>> >> >>> >> it is acceptable to use a 64-bit version of x, even though x is only >>> >> 32 bits, because it's using a value left over in a 64-bit register >>> >> from some immediately prior calculation of x. >>> >> >> Yes, when you have undefined behaviour! Once you have written "int x >> = 1 << 31;", then /anything/ afterwards is allowed. /Anything/. The >> compiler can do whatever it wants. > > No. Suppose that those two lines are compiled today, and the function > f() is external, which might be compiled tomorrow. There is no evidence > of UB, so there should be no reason for the 64-bit version of 'x' in > 'x>>8' to be anything other than its cleanly sign-extended. > Obviously if the compiler does not know about the undefined behaviour, it can't make use of it for optimisation. The same applies to all sorts of information in functions. If the compiler knows that "f" only returns values between 0 and 3, it might be able to make use of that for better code later on. If it does not know this, then it can't use that fact. > When f() is finally compiled, /that/ might have UB, perhaps in a form > detectable by the compiler. But that is too late to influence the first > lot of code. See above. > >> As I have explained, the compiler can take advantage of this leeway to >> generate better code. So following "int x = a << b;", the compiler >> can assume that "a" was a non-negative integer, that "b" is between 0 >> at 30 or that "a" is 0 and "b" is 31, and that "a << b" does not >> overflow the signed int. >> >> So if a cpu loads "a" into a 64-bit register, using sign extension or >> zero extension, and executes a 64-bit left shift instruction, then it >> will have 0 in the upper half of the register. The compiler knows >> this for a fact - because anything else would have been undefined >> behaviour. > > I thought it was C that determines whether something is undefined > behaviour. And C cannot know what sizes of registers are to be used. > C (the standards, then the implementation) define the behaviour of the language on a given implementation. The compiler's job is to generate code so that if you give valid input, the results are valid according to those definitions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 13:51 -0700 |
| Message-ID | <lnh8bte2lb.fsf@kst-u.example.com> |
| In reply to | #142291 |
David Brown <david.brown@hesbynett.no> writes:
> On 23/03/2019 14:33, Bart wrote:
[...]
>> BC (me):
>> >> You [DB] are saying that here:
>> >>
>> >> int32_t x = f();
>> >> int32_t y = <some expression involving x, such as x>>8>
>> >>
>> >> it is acceptable to use a 64-bit version of x, even though x is only
>> >> 32 bits, because it's using a value left over in a 64-bit register
>> >> from some immediately prior calculation of x.
>
> Yes, when you have undefined behaviour! Once you have written "int x
> = 1 << 31;", then /anything/ afterwards is allowed. /Anything/. The
> compiler can do whatever it wants.
David, I think you may have fallen into a trap (not necessarily
a deliberate one), and Bart has seized on it. Bart's example,
reduced to actual code, is:
int32_t x = f();
int32_t y = x >> 8;
does *not* have undefined behavior (assuming f() is well defined).
It cannot produce a result that depends on, for example, the upper
half of some 64-bit register.
I think Bart is incorrectly assuming that it doesn't matter much
whether the code has undefined behavior or not.
I suggest waiting for Bart to post a clear example (with no
pseudo-code) that we can discuss meaningfully.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 17:05 +0100 |
| Message-ID | <q789t0$e66$1@dont-email.me> |
| In reply to | #142314 |
On 23/03/2019 21:51, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 23/03/2019 14:33, Bart wrote: > [...] >>> BC (me): >>> >> You [DB] are saying that here: >>> >> >>> >> int32_t x = f(); >>> >> int32_t y = <some expression involving x, such as x>>8> >>> >> >>> >> it is acceptable to use a 64-bit version of x, even though x is only >>> >> 32 bits, because it's using a value left over in a 64-bit register >>> >> from some immediately prior calculation of x. >> >> Yes, when you have undefined behaviour! Once you have written "int x >> = 1 << 31;", then /anything/ afterwards is allowed. /Anything/. The >> compiler can do whatever it wants. > > David, I think you may have fallen into a trap (not necessarily > a deliberate one), and Bart has seized on it. Bart's example, > reduced to actual code, is: > > int32_t x = f(); > int32_t y = x >> 8; > > does *not* have undefined behavior (assuming f() is well defined). > It cannot produce a result that depends on, for example, the upper > half of some 64-bit register. > I don't think there is a trap, but there may have been a mixup here as things have changed from particular code examples with undefined behaviour, to "f" referring to those examples, to a general "f". Let us assume that on the target in question, a function returning an 32-bit "int" actually returns it in a 64-bit register, with sign extension, and assume that right-shift of negative numbers is by sign extension. (These things are all determined by the target and ABI, but I don't think they are unrealistic.) In that case, it would be fine for the compiler to call f(), returning the result in a 64-bit register, and immediately apply a 64-bit sign-preserving right shift instruction. As long as "f" is doing its job correctly, this code will give the required results. But if "f" is broken in some way, then you will get incorrect results. You can even get apparently impossible or inconsistent results - such as "x" appearing to have the value 0x1000 (with garbage in the higher half of the register), and "y" getting 0xff000010 after the shift. That is because "f" is broken - it is executing undefined behaviour or otherwise breaking the rules assumed by the C implementation. > I think Bart is incorrectly assuming that it doesn't matter much > whether the code has undefined behavior or not. Yes. Bart seems to think that even if "f" has undefined behaviour, the rest of the code should run correctly. > > I suggest waiting for Bart to post a clear example (with no > pseudo-code) that we can discuss meaningfully. > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 12:41 -0700 |
| Message-ID | <lnpnqhe5v6.fsf@kst-u.example.com> |
| In reply to | #142281 |
Bart <bc@freeuk.com> writes:
> On 22/03/2019 20:54, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/03/2019 19:29, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> Take my example, and say f() returns 0xFFFFFFFF_00000000 in 64-bit
>>>>> register R0. The bottom half is stored to x, so x contains 0.
>>>>>
>>>>> The next line is:
>>>>>
>>>>> int32_t y = x>>8;
>>>>>
>>>>> because R0 could still contain 0xFFFFFFFF_00000000, David Brown is
>>>>> suggesting that a compiler might make use of that existing value, and
>>>>> because this processor only has 64-bit ops, it will right shift all 64
>>>>> bits to end up with 0x00FFFFFF_FF000000.
>>>>
>>>> I don't remember what David suggested.
>>>
>>> Read his posts today (Mar-22) at 13:26 and 15:10 GMT. He was trying to
>>> explain why a machine with only 64-bit registers and operations (so
>>> that intermediate calculations, even for int32, are necessarily
>>> 64-bits) might give different results.
>>
>> David was discussing this example:
>>
>> int x = 1 << 31;
>> int y = x / 5;
>>
>
> This is from the man himself:
>
> BC (me):
> >> You [DB] are saying that here:
> >>
> >> int32_t x = f();
> >> int32_t y = <some expression involving x, such as x>>8>
> >>
> >> it is acceptable to use a 64-bit version of x, even though x is only
> >> 32 bits, because it's using a value left over in a 64-bit register
> >> from some immediately prior calculation of x.
>
> DB:
> > Ignoring your somewhat jumbled syntax (I can't figure out if it is
> > supposed to be a smiley, or what it is), then yes.
>
> KT again:
> > which has undefined behavior (again, assuming 32-bit int). Your example
> > does not have undefined behavior.
You introduced the example with x>>8. David originally was talking
about an example that clearly had undefined behavior, which x<<8 does
not.
> Imagine that the f(x) in my example returned the value of 1<<31 as an
> int32_t type. However, I can see that it would make much difference.
Did you mean "can't"?
If the call to f() has undefined behavior, then the entire chunk of code
has undefined behavior. I was assuming that it didn't, and that af
function was being used only to avoid letting the compiler know what the
value of x might be.
So, without reference to what David may or may not have said, given this
code fragment:
int32_t x = f();
int32_t y = x >> 8;
and assuming that int is 32 bits (so x is not promoted) and
that f() has defined behavior, if x is negative then y gets
an implementation-defined value, and if x is non-negative
then y gets the truncated value of x/256. I believe that the
implementation-defined value in the negative case can depend only
on the value of x, not on, for example, any garbage that might be in
the upper half of a 64-bit register. There is no undefined behavior.
Getting back to what David wrote (quoted above), I believe he was
mistaken, probably because he didn't bother to analyze the code that you
introduced, which differed significantly from the code he was orginally
talking about. Note that said he was confused by the syntax you used,
"<some expression involving x, such as x>>8>".
> Could a compiler really be so sloppy as to disallow garbage from an
> unused parts of a register to affect calculations, but not be bothered
> when it thinks it's undefined behaviour?
If a compiler were that "sloppy", it would not violate the C standard.
In real life, though, compilers are not "sloppy" in the way
you describe. They assume, because they are permitted to do so,
that the code they're processing has defined behavior (including
unspecified or implementation-defined). If the code violates
that assumption, they compiler might generate code that violates
your expectations -- though strictly speaking if you write code
whose behavior is undefined, you shouldn't have any expectations.
One entirely possible consequence of that is that garbage bits from
the upper half of a 64-bit register might unexpectedly be introduced
into a 32-bit result. Again, this could happen in the presence of
undefined behavior.
I don't believe most, or probably any, compilers observe that a given
chunk of C source code has undefined behavior and then deliberately
do something unexpected. Rather they peform optimizations that
are intended to improve the generated code for input C code with
*defined* behavior, and that can produce surprising results for
input C code that violates that assumption.
> In any case I disagree that 1<<31 should be undefined, and I think this
> is the point of the thread. I think that post of yours about C++ suggest
> many feel the same. The fact that so many C compilers deal with that as
> expected (except maybe David Brown's DEC Alpha, although we have no
> actual evidence) also supports that.
I don't know what you're disagreeing with. I've never said
whether 1<<31 *should* be undefined. I've simply said that it *is*
undefined, and explored the consequences of that fact. There are
proposals to change the next edition of the C standard so that
1<<31 would be defined. I'm undecided about whether that would be a
good idea, but if such a change were made I would accept it.
You tend to complain about what the C standard says without first
making the effort to understand what it says.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 22:55 +0000 |
| Message-ID | <VPylE.543550$uD1.407887@fx33.am4> |
| In reply to | #142309 |
On 23/03/2019 19:41, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > In real life, though, compilers are not "sloppy" in the way > you describe. They assume, because they are permitted to do so, > that the code they're processing has defined behavior (including > unspecified or implementation-defined). If the code violates > that assumption, they compiler might generate code that violates > your expectations -- though strictly speaking if you write code > whose behavior is undefined, Again, this is C's definition of undefined behaviour. I might take the same generic algorithm, and port to a half a dozen languages including C. Only in C is integer overflow considered such a big deal, that it causes undefined behaviour. And only in C, would code that overflows be assumed to never happen, allowing compilers to do unpredictable things. (If there are languages, other than C++, which don't routinely do runtime overflow checks, and where integer overflow also is considered UB, then I'm sure people will tell me. I've only briefly checked Java, Go, Rust and Fortran. All mine of course allow integer overflow for primitive types.) The point is, I am just writing code, not necessarily C code, but it is only when expressing it as C does this come up. Integer overflow in a program may well be unintentional, and could signify a bug (as could unsigned overflow actually), one that sometimes just simply needs a wider type, and C assuming that's never going to happen, and using that fact to take liberties with my program, really isn't helpful. > One entirely possible consequence of that is that garbage bits from > the upper half of a 64-bit register might unexpectedly be introduced > into a 32-bit result. Again, this could happen in the presence of > undefined behavior. That would never happen in any of my compilers. If it does, then it's a bug. It certainly would never be intentional.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 16:20 -0700 |
| Message-ID | <ln4l7tdvos.fsf@kst-u.example.com> |
| In reply to | #142319 |
Bart <bc@freeuk.com> writes:
> On 23/03/2019 19:41, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> In real life, though, compilers are not "sloppy" in the way
>> you describe. They assume, because they are permitted to do so,
>> that the code they're processing has defined behavior (including
>> unspecified or implementation-defined). If the code violates
>> that assumption, they compiler might generate code that violates
>> your expectations -- though strictly speaking if you write code
>> whose behavior is undefined,
>
> Again, this is C's definition of undefined behaviour.
Yes, it is. And this is comp.lang.c, so that's the relevant definition.
Do you accept the fact that the C standard says what it says?
> I might take the same generic algorithm, and port to a half a dozen
> languages including C.
>
> Only in C is integer overflow considered such a big deal, that it causes
> undefined behaviour. And only in C, would code that overflows be assumed
> to never happen, allowing compilers to do unpredictable things.
Yes, we all know that you don't like a lot of things about C.
When you make incorrect statements about what C says, we try to
correct them. When you express opinions about C, some of us don't
bother to reply, because there's really not much to say about it
(and some of us might even agree with you on some points).
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 23:40 +0000 |
| Message-ID | <stzlE.378101$iV1.74132@fx25.am4> |
| In reply to | #142322 |
On 23/03/2019 23:20, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 23/03/2019 19:41, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> In real life, though, compilers are not "sloppy" in the way >>> you describe. They assume, because they are permitted to do so, >>> that the code they're processing has defined behavior (including >>> unspecified or implementation-defined). If the code violates >>> that assumption, they compiler might generate code that violates >>> your expectations -- though strictly speaking if you write code >>> whose behavior is undefined, >> >> Again, this is C's definition of undefined behaviour. > > Yes, it is. And this is comp.lang.c, so that's the relevant definition. Well, so what? Don't C programs run on the same hardware as other languages? If they don't see the need to make integer overflow UB, then why does C? You're taking a very narrow view here. C's UB, especially in cases such as integer overflow that can be well-defined in hardware, can be a right PITA.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 18:35 -0700 |
| Message-ID | <lnva09cawr.fsf@kst-u.example.com> |
| In reply to | #142325 |
Bart <bc@freeuk.com> writes:
> On 23/03/2019 23:20, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 23/03/2019 19:41, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> In real life, though, compilers are not "sloppy" in the way
>>>> you describe. They assume, because they are permitted to do so,
>>>> that the code they're processing has defined behavior (including
>>>> unspecified or implementation-defined). If the code violates
>>>> that assumption, they compiler might generate code that violates
>>>> your expectations -- though strictly speaking if you write code
>>>> whose behavior is undefined,
>>>
>>> Again, this is C's definition of undefined behaviour.
>>
>> Yes, it is. And this is comp.lang.c, so that's the relevant definition.
>
> Well, so what? Don't C programs run on the same hardware as other
> languages? If they don't see the need to make integer overflow UB, then
> why does C?
Languages that don't make signed integer overflow undefined behavior
either run only on CPUs on which signed integer operations behave
consistently, or they impose extra overhead with run-time checks.
If you have a counterexample, please cite it.
And if I describe to you what the C standard says, please don't
take it as a personal affront.
> You're taking a very narrow view here. C's UB, especially in cases such
> as integer overflow that can be well-defined in hardware, can be a right
> PITA.
It can be well-defined on *some* hardware. And maybe -- *maybe*
-- it would be reasonable to consider narrowing C's semantics in a
future edition of the standard. Maybe all target systems are able
to perform signed integer addition, subtraction, multiplication,
and division and produce results that are consistent across all
of them. I don't think either of us knows enough about real-world
CPU architectures to know whether that's true or not. (I believe
Java defines the semantics of signed arithmetic as the common
2's-complement wraparound, but Java isn't implemented for as many
target systems as C is.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-23 20:19 -0400 |
| Message-ID | <32AlE.453865$UO4.70438@fx38.iad> |
| In reply to | #142319 |
On 3/23/19 6:55 PM, Bart wrote: > On 23/03/2019 19:41, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >> In real life, though, compilers are not "sloppy" in the way >> you describe. They assume, because they are permitted to do so, >> that the code they're processing has defined behavior (including >> unspecified or implementation-defined). If the code violates >> that assumption, they compiler might generate code that violates >> your expectations -- though strictly speaking if you write code >> whose behavior is undefined, > > Again, this is C's definition of undefined behaviour. > > I might take the same generic algorithm, and port to a half a dozen > languages including C. > > Only in C is integer overflow considered such a big deal, that it causes > undefined behaviour. And only in C, would code that overflows be assumed > to never happen, allowing compilers to do unpredictable things. > > (If there are languages, other than C++, which don't routinely do > runtime overflow checks, and where integer overflow also is considered > UB, then I'm sure people will tell me. I've only briefly checked Java, > Go, Rust and Fortran. All mine of course allow integer overflow for > primitive types.) One of the goals in the design of the C language was to allow (but not require) the generation of very efficient code. Much of what is left as undefined behavior is due to the fact that forcing a given behavior might be too costly for some machine that wants to implement the C language. Adding overflow test WILL slow do the code on most machines. Yes, on many machines you can perhaps hand wave that overflow just causes a wrapping of values, but as this example has pointed out, even that definition will cause some efficiency lost in some cases, as the compiler will need to emit zero or sign extension instruction at times. > > The point is, I am just writing code, not necessarily C code, but it is > only when expressing it as C does this come up. > > Integer overflow in a program may well be unintentional, and could > signify a bug (as could unsigned overflow actually), one that sometimes > just simply needs a wider type, and C assuming that's never going to > happen, and using that fact to take liberties with my program, really > isn't helpful. > Programming in C can be looked at in analogy to using a very sharp knife. It is a very useful tool, and can do some very useful things, but it does demand a level of care for the user. If you use the tool right, you can achieve great results, use it wrong and you can hurt yourself. There may be other tools that are safer, but there are times when the tool that needs skill does a much better job. >> One entirely possible consequence of that is that garbage bits from >> the upper half of a 64-bit register might unexpectedly be introduced >> into a 32-bit result. Again, this could happen in the presence of >> undefined behavior. > > That would never happen in any of my compilers. If it does, then it's a > bug. It certainly would never be intentional. > Then you compilers must generate less efficient code than what a compiler that does use C definition of Undefined Behavior could. It may be good enough for you, but it still will be less than it could be.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 12:06 +0000 |
| Message-ID | <gpKlE.746835$RBa.269619@fx15.am4> |
| In reply to | #142326 |
On 24/03/2019 00:19, Richard Damon wrote: > On 3/23/19 6:55 PM, Bart wrote: >> That would never happen in any of my compilers. If it does, then it's a >> bug. It certainly would never be intentional. >> > > Then you compilers must generate less efficient code than what a > compiler that does use C definition of Undefined Behavior could. It may > be good enough for you, but it still will be less than it could be. My compilers, when applied to actual applications, might compare to gcc-O3 as follows: 20-30% slower (my compiler application) 40% slower (C compiler app) 50% slower (my interpreter app) 100% slower (Lua interpreter app) But note: * These test programs are all computationally intensive (little i/o or time spent in external libraries). But execution is distributed throughout the program compared to the programs below. * My compilers do NO OPTIMISATIONS AT ALL (ie. no special optimise pass). And some of the code is truly terrible. * It took at least 50 times longer to run gcc-O3 so as to get those timings, as it took my own compilers * In the case of the compiler apps, the difference in terms of elapsed time might be tens of milliseconds. When applied to benchmarks, or very tight, localised computational code where there is one obvious bottleneck, then the differences might be much greater (eg. 400% slower to calculate pi-digits). I've no idea how much of this is due to gcc making use of UB; I would suggest most of the difference is due to my own crass code. From the examples posted to do with integer overflow, it seems some issues are to do with the mismatching of 32-bit int types, constants etc with the 64-bit machines which are now predominately used for consumer equipment. I've already suggested that a 64-bit 'int' type for such machines could be a way to go; you can get more efficient code, without needing to rely on UB.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 17:41 +0100 |
| Message-ID | <q78bvl$pso$1@dont-email.me> |
| In reply to | #142326 |
On 24/03/2019 01:19, Richard Damon wrote: > On 3/23/19 6:55 PM, Bart wrote: >> On 23/03/2019 19:41, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >> >>> In real life, though, compilers are not "sloppy" in the way >>> you describe. They assume, because they are permitted to do so, >>> that the code they're processing has defined behavior (including >>> unspecified or implementation-defined). If the code violates >>> that assumption, they compiler might generate code that violates >>> your expectations -- though strictly speaking if you write code >>> whose behavior is undefined, >> >> Again, this is C's definition of undefined behaviour. >> >> I might take the same generic algorithm, and port to a half a dozen >> languages including C. >> >> Only in C is integer overflow considered such a big deal, that it causes >> undefined behaviour. And only in C, would code that overflows be assumed >> to never happen, allowing compilers to do unpredictable things. >> >> (If there are languages, other than C++, which don't routinely do >> runtime overflow checks, and where integer overflow also is considered >> UB, then I'm sure people will tell me. I've only briefly checked Java, >> Go, Rust and Fortran. All mine of course allow integer overflow for >> primitive types.) > > One of the goals in the design of the C language was to allow (but not > require) the generation of very efficient code. Much of what is left as > undefined behavior is due to the fact that forcing a given behavior > might be too costly for some machine that wants to implement the C > language. Adding overflow test WILL slow do the code on most machines. > Yes, on many machines you can perhaps hand wave that overflow just > causes a wrapping of values, but as this example has pointed out, even > that definition will cause some efficiency lost in some cases, as the > compiler will need to emit zero or sign extension instruction at times. > I am of the opinion that making signed integer overflow undefined behaviour is a useful thing for development, because it increases the possibilities of finding bugs in your code. Make it defined behaviour hides the bugs. I don't know if that is a reason that was considered in the design of the C language, but it is definitely an advantage of the language now. The efficiency benefit is obvious, and compilers can generate more efficient code knowing that integer overflow does not occur. The other commonly cited reason for undefined behaviour on overflow, that it would vary between machines, is less convincing to me. If that were a major point, I think the standards would say that integer overflow gives either an implementation-defined result or raises an implementation-defined signal - that would cover pretty much any system.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-24 22:42 -0400 |
| Message-ID | <MeXlE.159950$C55.14908@fx33.iad> |
| In reply to | #142358 |
On 3/24/19 12:41 PM, David Brown wrote: > I am of the opinion that making signed integer overflow undefined > behaviour is a useful thing for development, because it increases the > possibilities of finding bugs in your code. Make it defined behaviour > hides the bugs. > > I don't know if that is a reason that was considered in the design of > the C language, but it is definitely an advantage of the language now. > > The efficiency benefit is obvious, and compilers can generate more > efficient code knowing that integer overflow does not occur. > > The other commonly cited reason for undefined behaviour on overflow, > that it would vary between machines, is less convincing to me. If that > were a major point, I think the standards would say that integer > overflow gives either an implementation-defined result or raises an > implementation-defined signal - that would cover pretty much any system. > My understanding was that the committee didn't use that phrase in the initial standard, behavior had a fairly simple hierarchy: Defined Behavior: the Standard spelled out exact what should happen. Implementation Defined Behavior: The Standard provides a (normally) explicit set of options which the implementation documents which is chosen. Unspecified Behavior: The Standard provieds a (normally) explicit set of options of which the implementation can choose between, but doesn't need to be consistent about or document. (Like the order the parts of an expression are evaluated, absent defined sequence points) Undefined Behavior: The Standard provides NO definition of what will happen. I also think some machines that were around may have had natural behavior that couldn't quite fit that model, I seem to remember some that trapped in a way that didn't lead to calling a signal handler. Given the current definition, some implementations have developed optimizations that also don't map into that model, which they use to speed up well behaved code. One such optimization would be that the value of x + a > x + b is the same as a > b, and the expression x doesn't need to be computed at all (as long as any side effects are performed). This does not hold in the presence of overflow. A lot of C++ code (and many C implementations share a code base with a C++ implemention) can generate a lot of these sort of things through things like templates.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-24 20:21 -0700 |
| Message-ID | <lnzhpjbpwi.fsf@kst-u.example.com> |
| In reply to | #142390 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 3/24/19 12:41 PM, David Brown wrote:
[...]
>> The other commonly cited reason for undefined behaviour on overflow,
>> that it would vary between machines, is less convincing to me. If that
>> were a major point, I think the standards would say that integer
>> overflow gives either an implementation-defined result or raises an
>> implementation-defined signal - that would cover pretty much any system.
>
> My understanding was that the committee didn't use that phrase in the
> initial standard, behavior had a fairly simple hierarchy:
>
> Defined Behavior: the Standard spelled out exact what should happen.
>
> Implementation Defined Behavior: The Standard provides a (normally)
> explicit set of options which the implementation documents which is chosen.
>
> Unspecified Behavior: The Standard provieds a (normally) explicit set of
> options of which the implementation can choose between, but doesn't need
> to be consistent about or document. (Like the order the parts of an
> expression are evaluated, absent defined sequence points)
>
> Undefined Behavior: The Standard provides NO definition of what will happen.
That's pretty much what the standard has always said.
> I also think some machines that were around may have had natural
> behavior that couldn't quite fit that model, I seem to remember some
> that trapped in a way that didn't lead to calling a signal handler.
>
> Given the current definition, some implementations have developed
> optimizations that also don't map into that model, which they use to
> speed up well behaved code. One such optimization would be that the
> value of x + a > x + b is the same as a > b, and the expression x
> doesn't need to be computed at all (as long as any side effects are
> performed). This does not hold in the presence of overflow.
How does that not fit into that model?
If neither x+a nor x+b overflows, then x+a > x+b is equivalent to a > b.
If either x+a or x+b overflows (assuming signed addition), then the
behavior is undefined, and treating it as equivalent to a > b is
perfectly legitimate.
(The part about raising an implementation-defined signal applies only to
conversion to a signed type, and was added in C99. The rules for
conversion differ from the rules for arithmetic operations.)
[...]
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-25 07:53 -0400 |
| Message-ID | <yi3mE.327183$tS5.37996@fx48.iad> |
| In reply to | #142391 |
On 3/24/19 11:21 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 3/24/19 12:41 PM, David Brown wrote: > [...] >>> The other commonly cited reason for undefined behaviour on overflow, >>> that it would vary between machines, is less convincing to me. If that >>> were a major point, I think the standards would say that integer >>> overflow gives either an implementation-defined result or raises an >>> implementation-defined signal - that would cover pretty much any system. >> >> My understanding was that the committee didn't use that phrase in the >> initial standard, behavior had a fairly simple hierarchy: >> >> Defined Behavior: the Standard spelled out exact what should happen. >> >> Implementation Defined Behavior: The Standard provides a (normally) >> explicit set of options which the implementation documents which is chosen. >> >> Unspecified Behavior: The Standard provieds a (normally) explicit set of >> options of which the implementation can choose between, but doesn't need >> to be consistent about or document. (Like the order the parts of an >> expression are evaluated, absent defined sequence points) >> >> Undefined Behavior: The Standard provides NO definition of what will happen. > > That's pretty much what the standard has always said. But since one of the enumerated possibilities wasn't of the complexity of "an implemented-defined result or raise an implementation-defined signal", the option of implementation-defined wasn't available for signed overflow. > >> I also think some machines that were around may have had natural >> behavior that couldn't quite fit that model, I seem to remember some >> that trapped in a way that didn't lead to calling a signal handler. >> >> Given the current definition, some implementations have developed >> optimizations that also don't map into that model, which they use to >> speed up well behaved code. One such optimization would be that the >> value of x + a > x + b is the same as a > b, and the expression x >> doesn't need to be computed at all (as long as any side effects are >> performed). This does not hold in the presence of overflow. > > How does that not fit into that model? > > If neither x+a nor x+b overflows, then x+a > x+b is equivalent to a > b. > > If either x+a or x+b overflows (assuming signed addition), then the > behavior is undefined, and treating it as equivalent to a > b is > perfectly legitimate. > > (The part about raising an implementation-defined signal applies only to > conversion to a signed type, and was added in C99. The rules for > conversion differ from the rules for arithmetic operations.) > > [...] > The issue I was pointing out was the IF we wanted to make signed overflow be implementation defined, then the reduction presented can not be done. x + a > x + b no longer has the same value as a > b, as in the presence of signed overflow can break that transformation, and thus the expression reduction can't be done. Simplest example is x+1 > x, but the reduction it is always true, but if x = INT_MAX, then there is no implementation defined value that can be assigned to x+1 to keep it true. It is my understanding that GCC and other compilers have a number of optimizations that work similarly to this, applying mathematical identities (that only are true if we assume no signed overflow) to simplify the program. And it isn't that the optimization is specifically looking for overflow and saying we can change behavior in its presence (and thus could warn about the condition too), but that the analysis just begins with the assumption of no overflow and proceeds to optimize the expression, and it doesn't really know if it needed to use the assumption of no overflow, so can't even generate a warning. My guess is that the developers of these optimizations are resisting the idea of mandating implementation defined behavior on overflow (even though the provide it as an option) as they feel that enough people benefit from those optimizations when they have made sure they avoid overflow, that it is worth it to keep them.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-25 11:22 -0700 |
| Message-ID | <d1ca3040-f59f-4424-92e9-e5931815425f@googlegroups.com> |
| In reply to | #142402 |
On Monday, March 25, 2019 at 7:53:10 AM UTC-4, Richard Damon wrote: > On 3/24/19 11:21 PM, Keith Thompson wrote: > > Richard Damon <Richard@Damon-Family.org> writes: > >> On 3/24/19 12:41 PM, David Brown wrote: > > [...] > >>> The other commonly cited reason for undefined behaviour on overflow, > >>> that it would vary between machines, is less convincing to me. If that > >>> were a major point, I think the standards would say that integer > >>> overflow gives either an implementation-defined result or raises an > >>> implementation-defined signal - that would cover pretty much any system. > >> > >> My understanding was that the committee didn't use that phrase in the > >> initial standard, behavior had a fairly simple hierarchy: > >> > >> Defined Behavior: the Standard spelled out exact what should happen. > >> > >> Implementation Defined Behavior: The Standard provides a (normally) > >> explicit set of options which the implementation documents which is chosen. The set is often implicit, and often very large, in some cases infinite in size. I've seen both of those facts cause a bit of confusion. > >> Unspecified Behavior: The Standard provieds a (normally) explicit set of > >> options of which the implementation can choose between, but doesn't need > >> to be consistent about or document. (Like the order the parts of an > >> expression are evaluated, absent defined sequence points) Your wording could give the impression that you're describing 4 distinct categories. implementation-defined behavior is defined as "unspecified behavior where each implementation documents how the choice is made" (3.4.1p1), and is therefore a subset of unspecified behavior. > >> Undefined Behavior: The Standard provides NO definition of what will happen. > > > > That's pretty much what the standard has always said. > > But since one of the enumerated possibilities wasn't of the complexity > of "an implemented-defined result or raise an implementation-defined > signal", the option of implementation-defined wasn't available for > signed overflow. I'm not sure I understand that comment. Signed overflow during conversion does have implementation-defined behavior. There's a choice of options, and a requirement to document which choice is made. The fact that the options permitted by the standard can be organized into two groups, and it's convenient to describe each of those groups separately, doesn't change the fact that this matches the definition for "implementation-defined behavior".
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-26 23:28 -0400 |
| Message-ID | <R5CmE.28259$434.19472@fx29.iad> |
| In reply to | #142420 |
On 3/25/19 2:22 PM, James Kuyper wrote: > On Monday, March 25, 2019 at 7:53:10 AM UTC-4, Richard Damon wrote: >> On 3/24/19 11:21 PM, Keith Thompson wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: >>>> On 3/24/19 12:41 PM, David Brown wrote: >>> [...] >>>>> The other commonly cited reason for undefined behaviour on overflow, >>>>> that it would vary between machines, is less convincing to me. If that >>>>> were a major point, I think the standards would say that integer >>>>> overflow gives either an implementation-defined result or raises an >>>>> implementation-defined signal - that would cover pretty much any system. >>>> >>>> My understanding was that the committee didn't use that phrase in the >>>> initial standard, behavior had a fairly simple hierarchy: >>>> >>>> Defined Behavior: the Standard spelled out exact what should happen. >>>> >>>> Implementation Defined Behavior: The Standard provides a (normally) >>>> explicit set of options which the implementation documents which is chosen. > > The set is often implicit, and often very large, in some cases infinite in size. I've seen both of those facts cause a bit of confusion. > Some things that need to be 'Implementation Defined' (like representations) indeed can have a large space of possibilities, but that isn't 'behavior'. Most cases of actual behavior the options are relatively few options (perhaps making reference to an implementation defined representation). For behaviors the biggest set I can think of is the implementation defined value for assigning a larger value into a smaller signed value, which technically is the choice of a mapping of every possible larger value into a listing of the chosen smaller value, but even in that form it is finite, and generally actually described as a simple formula. >>>> Unspecified Behavior: The Standard provieds a (normally) explicit set of >>>> options of which the implementation can choose between, but doesn't need >>>> to be consistent about or document. (Like the order the parts of an >>>> expression are evaluated, absent defined sequence points) > > Your wording could give the impression that you're describing 4 distinct categories. implementation-defined behavior is defined as "unspecified behavior where each implementation documents how the choice is made" (3.4.1p1), and is therefore a subset of unspecified behavior. I do consider it a distinct category, maybe not a unique as between Defined and Undefined, but with Implementation Defined behavior, I can code based on that documentation an KNOW what will happen, and know that it will be consistently that way. With unspecified behavior that is impossible. Now, without access to that documentation, I can't really utilize that advantage, so you can't write 'portable' code that takes advantage of the behavior being implementation defined, but you can write implementation dependent code that does. (One limitation is you may or may not be able to put something in the code to confirm that you are running on an implementation that matches the documentation you depended on). > > >>>> Undefined Behavior: The Standard provides NO definition of what will happen. >>> >>> That's pretty much what the standard has always said. >> >> But since one of the enumerated possibilities wasn't of the complexity >> of "an implemented-defined result or raise an implementation-defined >> signal", the option of implementation-defined wasn't available for >> signed overflow. > > I'm not sure I understand that comment. Signed overflow during conversion does have implementation-defined behavior. There's a choice of options, and a requirement to document which choice is made. The fact that the options permitted by the standard can be organized into two groups, and it's convenient to describe each of those groups separately, doesn't change the fact that this matches the definition for "implementation-defined behavior". > Since the Standards committee hadn't thought of that wording, and since some machines did trap on some values they couldn't specify an implementation defined result, as that didn't fit, so rather than force some machines to not be able to have efficient C implementations, they left the result as simply undefined.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-27 07:49 -0400 |
| Message-ID | <q7fo14$1au$1@dont-email.me> |
| In reply to | #142506 |
On 3/26/19 23:28, Richard Damon wrote: > On 3/25/19 2:22 PM, James Kuyper wrote: >> On Monday, March 25, 2019 at 7:53:10 AM UTC-4, Richard Damon wrote: >>> On 3/24/19 11:21 PM, Keith Thompson wrote: >>>> Richard Damon <Richard@Damon-Family.org> writes: >>>>> On 3/24/19 12:41 PM, David Brown wrote: >>>> [...] >>>>>> The other commonly cited reason for undefined behaviour on overflow, >>>>>> that it would vary between machines, is less convincing to me. If that >>>>>> were a major point, I think the standards would say that integer >>>>>> overflow gives either an implementation-defined result or raises an >>>>>> implementation-defined signal - that would cover pretty much any system. >>>>> >>>>> My understanding was that the committee didn't use that phrase in the >>>>> initial standard, behavior had a fairly simple hierarchy: >>>>> >>>>> Defined Behavior: the Standard spelled out exact what should happen. >>>>> >>>>> Implementation Defined Behavior: The Standard provides a (normally) >>>>> explicit set of options which the implementation documents which is chosen. >> >> The set is often implicit, and often very large, in some cases infinite in size. I've seen both of those facts cause a bit of confusion. >> > > Some things that need to be 'Implementation Defined' (like > representations) indeed can have a large space of possibilities, but > that isn't 'behavior'. Most cases of actual behavior the options are > relatively few options (perhaps making reference to an implementation > defined representation). For behaviors the biggest set I can think of is > the implementation defined value for assigning a larger value into a > smaller signed value, which technically is the choice of a mapping of > every possible larger value into a listing of the chosen smaller value, > but even in that form it is finite, and generally actually described as > a simple formula. Every unspecified value that has a lower bound but no upper bound offers a technically infinite range of possibilities, though for most of the best examples, the actual range of plausible values is quite small. Examples: CHAR_BIT, sizeof(long double _Complex), DBL_MAX. Other cases are more difficult. Would you care to give me the size of a finite set of possibilities permitted for any of the following unspecified behaviors: > — The manner and timing of static initialization (5.1.2). > — The termination status returned to the hosted environment if the return type of main > is not compatible with int (5.1.2.2.3). > — The values of objects that are neither lock-free atomic objects nor of type volatile > sig_atomic_t and the state of the floating-point environment, when the > processing of the abstract machine is interrupted by receipt of a signal (5.1.2.3). > — The behavior of the display device if a printing character is written when the active > position is at the final position of a line (5.2.2). That's just the first four items listed in Appendix J.1; there's lots more where they came from. The absolute topper is #pragma: > A preprocessing directive of the form > # pragma pp-tokens opt new-line > where the preprocessing token STDC does not immediately follow pragma in the > directive (prior to any macro replacement) 174) causes the implementation to behave in an > implementation-defined manner. The behavior might cause translation to fail or cause the > translator or the resulting program to behave in a non-conforming manner. Is there any behavior NOT allowed by that description )so long as it's correctly documented)? But I only said that the set of permitted behaviors was infinite in some cases. As I've already said, in most cases it's finite, and in many cases it's quite small. >>>>> Unspecified Behavior: The Standard provieds a (normally) explicit set of >>>>> options of which the implementation can choose between, but doesn't need >>>>> to be consistent about or document. (Like the order the parts of an >>>>> expression are evaluated, absent defined sequence points) >> >> Your wording could give the impression that you're describing 4 distinct categories. implementation-defined behavior is defined as "unspecified behavior where each implementation documents how the choice is made" (3.4.1p1), and is therefore a subset of unspecified behavior. > > I do consider it a distinct category, maybe not a unique as between > Defined and Undefined, but with Implementation Defined behavior, I can > code based on that documentation an KNOW what will happen, and know that > it will be consistently that way. With unspecified behavior that is > impossible. Now, without access to that documentation, I can't really > utilize that advantage, so you can't write 'portable' code that takes > advantage of the behavior being implementation defined, but you can > write implementation dependent code that does. (One limitation is you > may or may not be able to put something in the code to confirm that you > are running on an implementation that matches the documentation you > depended on). You're free to think of two different categories, but the standard doesn't name one of them. The proper way to describe those categories using standard C terminology is 1. Unspecified behavior for which no documentation is required. 2. Unspecified behavior for which documentation is required == implementation-defined behavior. As far at the standard is concerned, those are just two subsets of unspecified behavior. It's incorrect to use the unqualified term "unspecified behavior" to describe only the first category. It's a nit-pick, to be sure - but clearly stating what you're talking about greatly improves communication. ... >>> But since one of the enumerated possibilities wasn't of the complexity >>> of "an implemented-defined result or raise an implementation-defined >>> signal", the option of implementation-defined wasn't available for >>> signed overflow. >> >> I'm not sure I understand that comment. Signed overflow during conversion does have implementation-defined behavior. There's a choice of options, and a requirement to document which choice is made. The fact that the options permitted by the standard can be organized into two groups, and it's convenient to describe each of those groups separately, doesn't change the fact that this matches the definition for "implementation-defined behavior". >> > > Since the Standards committee hadn't thought of that wording, and since > some machines did trap on some values they couldn't specify an > implementation defined result, as that didn't fit, so rather than force > some machines to not be able to have efficient C implementations, they > left the result as simply undefined. No, in C89, the result was an implementation-defined value (3.2.1.2). Adding the raising of an implementation-defined signal was added in C99 (6.3.1.3p3), and that is still the status today. At no point since the language was standardized has the behavior of conversion of an integer to a signed integer ever been undefined. K&R C never uses the terms "undefined behavior" or "the behavior is undefined". It uses "undefined value", but most of the other uses of "undefined" in K&R C refer to things that are now described as "unspecified". Many things in K&R C could be described in modern terms as "undefined by omission of any explicit definition" (4p2), but "undefined behavior" just wasn't a concept used in that version of the language.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-04-10 08:35 -0700 |
| Message-ID | <86zhoxj2ky.fsf@mailhub.linuxsc.com> |
| In reply to | #142508 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > It's a nit-pick, to be sure - but clearly stating what you're > talking about greatly improves communication. I see. When I do it, it's splitting hairs, but when you do it, it's greatly improving communication.
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web