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 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 09:28 +0100 |
| Message-ID | <q726bv$rkk$1@dont-email.me> |
| In reply to | #142211 |
On 21/03/2019 23:18, Bart wrote: > 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? The bit where I gave some good reasons why 1 << 31 is undefined (for 32-bit ints). > > 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. 1 << 31 cannot be represented in 32-bits, with two's complement, ones' complement, or sign-magnitude representation (the three allowed representations in C). You could, I suppose, have a representation for 32-bit integers that run from -0x7fff_ffff up to +0x8000_0000 in a different language, but that would break several other requirements for int representations in C. It is the size of 32-bit that limits the range of int here, not the representation - that is irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-21 18:00 +0000 |
| Message-ID | <q70jg2$ec1$1@z-news.wcss.wroc.pl> |
| In reply to | #142148 |
Bart <bc@freeuk.com> 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.
>
> 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.
Hmm, consider 64-bit machine where ints in memeory have 32 bits.
Assume that compiler puts ints in 64-bit registers. I do not know
if with current C this would be legal, but several compilers for
other languages use such a tactic. Now look at:
int x = 1<<31;
int y = x / 5;
Clearly you get different results depending on register width.
My understanding is that currently _in this example_ C compiler
can use 64-bit registers. Defining shift as 32-bit 2-complement
whould force additional sign-extension.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-21 18:57 +0000 |
| Message-ID | <18RkE.296542$DH4.255445@fx24.am4> |
| In reply to | #142194 |
On 21/03/2019 18:00, antispam@math.uni.wroc.pl wrote: > Bart <bc@freeuk.com> wrote: >> 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. > > Hmm, consider 64-bit machine where ints in memeory have 32 bits. > Assume that compiler puts ints in 64-bit registers. I do not know > if with current C this would be legal, but several compilers for > other languages use such a tactic. Now look at: > > int x = 1<<31; > int y = x / 5; > > Clearly you get different results depending on register width. Why? If 'int' is 32 bit, then it will use 32-bit registers (the low halves of the 64-bit ones), and 32-bit operations. If you mean a machine which /only/ has 64-bit registers, then x and y may need to be widened to 64-bit, have 64-bit operations, but then be truncated back to 32 bits with the same results. > My understanding is that currently _in this example_ C compiler > can use 64-bit registers. Defining shift as 32-bit 2-complement > whould force additional sign-extension. Left-shift instructions are not signed; in both cases (signed or unsigned left operand) you are shifting in 0s from the right.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 22:32 +0100 |
| Message-ID | <q70vsp$avo$1@dont-email.me> |
| In reply to | #142195 |
On 21/03/2019 19:57, Bart wrote: > On 21/03/2019 18:00, antispam@math.uni.wroc.pl wrote: >> Bart <bc@freeuk.com> wrote: > >>> 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. >> >> Hmm, consider 64-bit machine where ints in memeory have 32 bits. >> Assume that compiler puts ints in 64-bit registers. I do not know >> if with current C this would be legal, but several compilers for >> other languages use such a tactic. Now look at: >> >> int x = 1<<31; >> int y = x / 5; >> >> Clearly you get different results depending on register width. > > Why? > > If 'int' is 32 bit, then it will use 32-bit registers (the low halves of > the 64-bit ones), and 32-bit operations. > > If you mean a machine which /only/ has 64-bit registers, then x and y > may need to be widened to 64-bit, have 64-bit operations, but then be > truncated back to 32 bits with the same results. > >> My understanding is that currently _in this example_ C compiler >> can use 64-bit registers. Defining shift as 32-bit 2-complement >> whould force additional sign-extension. > > Left-shift instructions are not signed; in both cases (signed or > unsigned left operand) you are shifting in 0s from the right. > C has a " << " operator. It does not have left-shift instructions. You appear to be mixing up C and assembly again. x << y has the result x * 2^y, reduced by modulo if x is unsigned. If the value of the result can't fit in the type - which is the case for signed 1 << 31 - then the result is undefined. C prefers to say it doesn't make sense and the language does not allow it, rather than pick an incorrect and meaningless value for it (regardless of any underlying implementation). So Auntie Spam here is correct. It is not (AFAIK) the main reason why 1 << 31 is not defined (for 32-bit int), but it is a convenient bonus.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-21 22:11 +0000 |
| Message-ID | <i_TkE.658776$OGY.405413@fx08.am4> |
| In reply to | #142206 |
On 21/03/2019 21:32, David Brown wrote: > On 21/03/2019 19:57, Bart wrote: >> Left-shift instructions are not signed; in both cases (signed or >> unsigned left operand) you are shifting in 0s from the right. >> > > C has a " << " operator. It does not have left-shift instructions. You > appear to be mixing up C and assembly again. And you appear to be talking nonsense: 6.5.7: Bitwise SHIFT operators. 6.5.7p4: The result of E1<<E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. K&R2 A7.8: The result of E1<<E2 is E1 (interpreted as a bit-pattern) left-shifted E2 bits. Clearly this was intended to be correlate closely with the bit-shift instructions to be found in most processors. And is equivalent to the way the way it works in all languages that have bit-level shifts. Why are trying to pretend this C knows nothing about bitwise shifts and only understands multiply and divide? Because bit-shifting sits uncomfortably in your ideal model of mathematics? C is just a trumped assembler with easier syntax and better portability. Bit-shifting starts to become harder with higher-level language features or more advanced types (it is badly defined with my decimal arbitrary precision library for example). But for machine-sized 32-bit binary values? > So Auntie Spam here is correct. It is not (AFAIK) the main reason why 1 > << 31 is not defined (for 32-bit int), but it is a convenient bonus. No, we don't know whether anti-spam is correct or, as we don't yet know his point about 64- vs 32-bit registers for 32-bit operations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 11:30 +0100 |
| Message-ID | <q72dfr$1c0$1@dont-email.me> |
| In reply to | #142209 |
On 21/03/2019 23:11, Bart wrote: > On 21/03/2019 21:32, David Brown wrote: >> On 21/03/2019 19:57, Bart wrote: > >>> Left-shift instructions are not signed; in both cases (signed or >>> unsigned left operand) you are shifting in 0s from the right. >>> >> >> C has a " << " operator. It does not have left-shift instructions. >> You appear to be mixing up C and assembly again. > > And you appear to be talking nonsense: > No, I am talking C. > 6.5.7: Bitwise SHIFT operators. > > 6.5.7p4: The result of E1<<E2 is E1 left-shifted E2 bit positions; > vacated bits are filled with zeros. > This is followed immediately by the details of the evaluation: """ If E1 has an unsigned type, the value of the result is E1 × 2 ^ E2 , reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 × 2 ^ E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined. """ The " << " operator acts as a left shift, filling in with zero bits, in the conditions for which it is valid. It is those conditions that concern us here. In particular, "1 << 31" is /not/ defined to left-shift signed int 1 by 31 bits. And no matter how you look at it, there is certainly no way you can claim C has a "left-shift instruction". C does not have "instructions" at all - that is an assembly concept. > K&R2 A7.8: The result of E1<<E2 is E1 (interpreted as a bit-pattern) > left-shifted E2 bits. > Since we are talking about C, not history, I was quoting from the C standards. (C11 to be precise - it has not changed in C17.) The C standards have given gradually more details about C and the behaviour of real compilers, compared to the sometimes vague information in K&R and older standards. > Clearly this was intended to be correlate closely with the bit-shift > instructions to be found in most processors. And is equivalent to the > way the way it works in all languages that have bit-level shifts. Oh, there is no doubt that the operation was designed to fit well with existing hardware - where it made sense. The same applies to many (or most) features of C. But you are making several fundamental mistakes here. First, you are thinking that C was intended to copy the behaviour of the hardware. It was not, and never has been. Second, you are thinking that the hardware was designed to give useful and correct results in all cases. It was not, and never has been. The hardware is designed to give correct and useful results for a useful set of inputs. It usually gives predictable results on other inputs - the choices here are based on whatever is simpler and cheaper in the hardware, or whatever can be reused for other purposes. No one /ever/ made a cpu "left shift signed integer" instruction that intentionally gave the result of -0x8000 when shifting +0x4000 by one bit. (I'm using 16-bit ranges here, because they are simpler numbers.) The reason that this is the usual behaviour, is that the same hardware, indeed the same instruction code, can be used for a /logical/ left shift. It is not because anyone thought it made sense to multiply a positive number by 2 and get a negative number. (The same applies to two's complement representation.) Third, you are incorrect to think other languages with shift operators work like you think. For signed integer overflow in general, few languages define the behaviour to be wrapping - most either check the result (giving an exception or error message of some sort), leave it as undefined, or have types that support larger values safely. Sometimes this is configurable by compiler switches (as it is for C, for many compilers). > > Why are trying to pretend this C knows nothing about bitwise shifts and > only understands multiply and divide? I am telling you what the standards say - the definition of the C language. It has bitwise shift operators, whose results are defined in terms of multiplication and division. > > Because bit-shifting sits uncomfortably in your ideal model of mathematics? > Not at all. > C is just a trumped assembler with easier syntax and better portability. It is harder to imagine a more incorrect description of C. And it is frustrating that you /still/ stick to that debunked myth. You are wrong. Totally, completely. This has been explained countless times in this group. It must take an extraordinary strength of will to remain so wrong, and so ignorant, over such a long time. > > Bit-shifting starts to become harder with higher-level language features > or more advanced types (it is badly defined with my decimal arbitrary > precision library for example). > > But for machine-sized 32-bit binary values? > > >> So Auntie Spam here is correct. It is not (AFAIK) the main reason why >> 1 << 31 is not defined (for 32-bit int), but it is a convenient bonus. > > No, we don't know whether anti-spam is correct or, as we don't yet know > his point about 64- vs 32-bit registers for 32-bit operations. Yes, we do - and he is right. I don't know whether real compilers for real targets actually use 64-bit operations when asked for a 32-bit shift. (I strongly suspect there are some that do, though it is unlikely for x86-64.) But he is right that this is a possibility.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-22 11:39 +0000 |
| Message-ID | <GP3lE.407767$%B.175266@fx03.am4> |
| In reply to | #142231 |
On 22/03/2019 10:30, David Brown wrote: > On 21/03/2019 23:11, Bart wrote: > First, you are thinking that C was intended to copy the behaviour of the > hardware. It was not, and never has been. Never? So why bother to introduce << and >>, and require a computer to be able to not only efficiently calculate powers of two, but also be capable of multiply and divide? I think you are talking nonsense again. It is almost certainly the case that << and >> are present because computers commonly had efficient shift instructions. > No one /ever/ made a cpu "left shift signed integer" instruction that > intentionally gave the result of -0x8000 when shifting +0x4000 by one > bit. It doesn't matter. Whether the resulting 0x8000 bit pattern is positive or negative depends on how the language interprets it. Suppose you could somehow take that result and simultaneously assign to both int16_t and uint16_t. You're saying the assignment to int16_t would be undefined (ie. UB), or the shift (sorry, multiply) operation itself? You see the paradox forming here if you were to go for the latter? > I am telling you what the standards say - the definition of the C > language. It has bitwise shift operators, whose results are defined in > terms of multiplication and division. And if the C standard defined multiplication and division in terms of binary shifts, adds and subtracts, you'd just accept that too? Remember it still calls them BITWISE shift operators, and still talks about bits and bit positions. >> C is just a trumped[-up] assembler with easier syntax and better portability. > > It is harder to imagine a more incorrect description of C. And it is > frustrating that you /still/ stick to that debunked myth. > > You are wrong. Totally, completely. Wikipedia: "By design, C provides constructs that map efficiently to typical machine instructions**, and it has therefore found lasting use in applications that were previously coded in assembly language." (**Obviously, apart from << and >>, according to David Brown) So it's the next step up from assembly language. What's frustrating for me is people trying to give it airs by pretending it's something it's not. >> No, we don't know whether anti-spam is correct or, as we don't yet know >> his point about 64- vs 32-bit registers for 32-bit operations. > > Yes, we do - and he is right. > > I don't know whether real compilers for real targets actually use 64-bit > operations when asked for a 32-bit shift. (I strongly suspect there are > some that do, though it is unlikely for x86-64.) But he is right that > this is a possibility. Since the result of the 32-bit shift that has been demanded has to be stored into a 32-bit destination, what possible difference can be it make whether the operation uses 64-bit registers or not?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 14:26 +0100 |
| Message-ID | <q72npb$qtv$1@dont-email.me> |
| In reply to | #142234 |
On 22/03/2019 12:39, Bart wrote: > On 22/03/2019 10:30, David Brown wrote: >> On 21/03/2019 23:11, Bart wrote: > >> First, you are thinking that C was intended to copy the behaviour of the >> hardware. It was not, and never has been. > > Never? So why bother to introduce << and >>, and require a computer to > be able to not only efficiently calculate powers of two, but also be > capable of multiply and divide? > It is for the convenience of the programmer. Sure, these may have been /inspired/ by hardware, but they are not /copies/ of the behaviour of any existing hardware. (I don't know the history well enough here - C was influenced and inspired by many things.) One of the aims of C was to replace the need to write in assembly - existing assemblies would have influenced the design of C, but C did not attempt to copy exact behaviours. > I think you are talking nonsense again. That is only because you have fixed but incorrect ideas about C. > > It is almost certainly the case that << and >> are present because > computers commonly had efficient shift instructions. Ask yourself why these operations are commonly available in hardware. Why would an assembler programmer use them? Probably much the same reasons would then apply to why a C programmer might want them. The C language does not have them because hardware has them - it has them because C programmers find them useful for some types of coding. > >> No one /ever/ made a cpu "left shift signed integer" instruction that >> intentionally gave the result of -0x8000 when shifting +0x4000 by one >> bit. > > It doesn't matter. Whether the resulting 0x8000 bit pattern is positive > or negative depends on how the language interprets it. > > Suppose you could somehow take that result and simultaneously assign to > both int16_t and uint16_t. You're saying the assignment to int16_t would > be undefined (ie. UB), or the shift (sorry, multiply) operation itself? > > You see the paradox forming here if you were to go for the latter? No paradox, no. It is absolutely fine to have an operation whose result is sensible and defined when interpreted as one type, and not sensible, valid or defined when interpreted as another type. > >> I am telling you what the standards say - the definition of the C >> language. It has bitwise shift operators, whose results are defined in >> terms of multiplication and division. > > And if the C standard defined multiplication and division in terms of > binary shifts, adds and subtracts, you'd just accept that too? > For C, yes. Why should that surprise you? The C standards do define a few things in odd, counter-intuitive or non-standard ways. (This is not such a case.) When talking about C, a "byte" is effectively an unsigned char, whatever size that might be on the target. That is different from how "byte" is normally defined, but it is the definition for C. Live with it, or use a different language. > Remember it still calls them BITWISE shift operators, and still talks > about bits and bit positions. I know that. But the definition of the results is based on multiplication and division by powers of two, and these are used to exclude certain possible input values to the operators. It is not rocket science - it is a couple of lines of clear, simple definition. > >>> C is just a trumped[-up] assembler with easier syntax and better >>> portability. >> >> It is harder to imagine a more incorrect description of C. And it is >> frustrating that you /still/ stick to that debunked myth. >> >> You are wrong. Totally, completely. > > Wikipedia: "By design, C provides constructs that map efficiently to > typical machine instructions**, and it has therefore found lasting use > in applications that were previously coded in assembly language." > > (**Obviously, apart from << and >>, according to David Brown) None of that contradicts anything I have said. You are wrong in your understanding of C, but cannot seem to accept it - thus you twist everything you read and everything others say to try to fit around the "facts" that you have fixated upon. > > So it's the next step up from assembly language. > Nope. > What's frustrating for me is people trying to give it airs by pretending > it's something it's not. Sorry, but it is /you/ that is pretending it is something it is not. C is a high level language, defined by behaviour of an abstract machine described in the C standards. The choice of types, operations, statements, etc., for this abstract machine was made with a view to generating efficient code on a wide variety of real hardware. It is not, and never has been, a kind of "portable assembly". C was designed partly so that a "portable assembly" would not be needed. > >>> No, we don't know whether anti-spam is correct or, as we don't yet know >>> his point about 64- vs 32-bit registers for 32-bit operations. >> >> Yes, we do - and he is right. >> >> I don't know whether real compilers for real targets actually use 64-bit >> operations when asked for a 32-bit shift. (I strongly suspect there are >> some that do, though it is unlikely for x86-64.) But he is right that >> this is a possibility. > > Since the result of the 32-bit shift that has been demanded has to be > stored into a 32-bit destination, what possible difference can be it > make whether the operation uses 64-bit registers or not? > If you do the shift as a 64-bit operation, there is no overflow. But there will be different results later depending on how it is used. The example he gave was: int x = 1 << 31; int y = x / 5; Let's assume the compiler treats this as "int x = 0x80000000;", and that conversion to signed int is done as modulo wrapping (the conversion is implementation defined, not undefined, and I would be surprised to find an implementation that does it any other way). When working as 32-bit, that means x is actually -0x80000000, so y gets the value -429496729. But when working with 64-bit registers and operations, x is +0x80000000 internally. y is thus calculated by the cpu as +429496729. The undefined nature of signed integer overflow - and 1 << 31 in particular - means that the compiler can do the operations like this. For a processor which does all its arithmetic as 64-bit (I think the DEC Alpha was like that, but I am not sure), getting the result /you/ want would require an extra step. After calculating 1 << 31 to get 0x80000000 in the the 64-bit register, the cpu would need a sign extension instruction to get -0x80000000 before doing the division.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-22 14:40 +0000 |
| Message-ID | <Yt6lE.304038$7F3.192949@fx30.am4> |
| In reply to | #142237 |
On 22/03/2019 13:26, David Brown wrote:
> On 22/03/2019 12:39, Bart wrote:
> It is absolutely fine to have an operation whose result is sensible and
> defined when interpreted as one type, and not sensible, valid or defined
> when interpreted as another type.
At what point would it generate nasal daemons?
>> So it's the next step up from assembly language.
>>
>
> Nope.
So what language is? (I don't count HLAs here.)
>> Since the result of the 32-bit shift that has been demanded has to be
>> stored into a 32-bit destination, what possible difference can be it
>> make whether the operation uses 64-bit registers or not?
>>
>
> If you do the shift as a 64-bit operation, there is no overflow. But
> there will be different results later depending on how it is used.
>
> The example he gave was:
>
> int x = 1 << 31;
> int y = x / 5;
>
> Let's assume the compiler treats this as "int x = 0x80000000;", and that
> conversion to signed int is done as modulo wrapping (the conversion is
> implementation defined, not undefined, and I would be surprised to find
> an implementation that does it any other way). When working as 32-bit,
> that means x is actually -0x80000000, so y gets the value -429496729.
>
> But when working with 64-bit registers and operations, x is +0x80000000
> internally. y is thus calculated by the cpu as +429496729.
I don't get this. The intermediate x value is -0x8000000. When loaded
into a 64-bit register, it will be sign-extended as you say below. It
will not be zero-extended; why would it do that?
>
> The undefined nature of signed integer overflow - and 1 << 31 in
> particular - means that the compiler can do the operations like this.
I thought it meant it could do anything it liked, including completely
random behaviour.
> For a processor which does all its arithmetic as 64-bit (I think the DEC
> Alpha was like that, but I am not sure), getting the result /you/ want
> would require an extra step.
Which result is that? And how does it compare with the result that /you/
want? All C compilers I've tried give:
-2147483648
-429496729
for x and y.
After calculating 1 << 31 to get
> 0x80000000 in the the 64-bit register,
If this is executing C code, calculations should be widened to 32 bits
but no further. Unless you are telling me that:
int x=1; // sizeof int=4
int y=x<<36; // or (x<<18)<<18 if preferred
int z=y>>28;
giving a result of z==256 (because it retains 64-bit intermediate
register contents between assignments) is valid C behaviour.
If you are saying that that z==256 is an acceptable result (compared
with z==0) because of UB, that then strikes me as a bad thing, not good,
because now you don't know what the hell a piece of code is going to do.
(Note that left-shifting a 32-bit value by 36 bits /is/ poorly defined
in hardware. On x64, it will only use the bottom 5 bits of the 36, so
will shift by 4. Other machines my be different.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 16:10 +0100 |
| Message-ID | <q72tse$fn$1@dont-email.me> |
| In reply to | #142241 |
On 22/03/2019 15:40, Bart wrote:
> On 22/03/2019 13:26, David Brown wrote:
>> On 22/03/2019 12:39, Bart wrote:
>
>> It is absolutely fine to have an operation whose result is sensible and
>> defined when interpreted as one type, and not sensible, valid or defined
>> when interpreted as another type.
>
> At what point would it generate nasal daemons?
When you try to use the result, interpreted as a value that is impossible.
void foo(void) {
union { int x; bool b } mixed;
mixed.x = rand();
if (mixed.b) {
printf("It's true!\n");
} else if (!mixed.b) {
printf("It's false!\n");
} else {
printf("It's neither true nor false!\n");
launch_nasal_daemons();
}
}
>
>>> So it's the next step up from assembly language.
>>>
>>
>> Nope.
>
> So what language is? (I don't count HLAs here.)
What is the next language sideways from Lisp?
It's a meaningless question.
You can certainly say that C is one of the lowest-level high-level
languages, but it is a high-level language - it is not a type of
assembly. (I'm not sure exactly how you would define the boundary
between "high level language" and "low level language". I'd choose
"defined in terms of an abstract model" rather than "defined in terms of
the underlying hardware". But you might have a different definition.)
>
>>> Since the result of the 32-bit shift that has been demanded has to be
>>> stored into a 32-bit destination, what possible difference can be it
>>> make whether the operation uses 64-bit registers or not?
>>>
>>
>> If you do the shift as a 64-bit operation, there is no overflow. But
>> there will be different results later depending on how it is used.
>>
>> The example he gave was:
>>
>> int x = 1 << 31;
>> int y = x / 5;
>>
>> Let's assume the compiler treats this as "int x = 0x80000000;", and that
>> conversion to signed int is done as modulo wrapping (the conversion is
>> implementation defined, not undefined, and I would be surprised to find
>> an implementation that does it any other way). When working as 32-bit,
>> that means x is actually -0x80000000, so y gets the value -429496729.
>>
>> But when working with 64-bit registers and operations, x is +0x80000000
>> internally. y is thus calculated by the cpu as +429496729.
>
> I don't get this. The intermediate x value is -0x8000000. When loaded
> into a 64-bit register, it will be sign-extended as you say below. It
> will not be zero-extended; why would it do that?
The point is, you are not loading a 32-bit signed int value -0x80000000
into a 64-bit register. You are loading a 32-bit signed int value 1
into the 64-bit register, then shifting it 31 bits left, then dividing
it by 5.
At no point does C require an intermediary value of -0x80000000. You
just think there is, because you still can't get your head around the
way c works.
>
>>
>> The undefined nature of signed integer overflow - and 1 << 31 in
>> particular - means that the compiler can do the operations like this.
>
> I thought it meant it could do anything it liked, including completely
> random behaviour.
>
Yes. But it also includes this particular behaviour, which is a good
deal more likely than random behaviour. (Of course, random behaviour is
always possible from any undefined behaviour - imagine the results of
the calculation are used to get the index into a table of function
pointers, which is then called. Your simple "wrong integer value"
undefined behaviour has turned into "launch nasal daemons" undefined
behaviour.)
>> For a processor which does all its arithmetic as 64-bit (I think the DEC
>> Alpha was like that, but I am not sure), getting the result /you/ want
>> would require an extra step.
>
> Which result is that? And how does it compare with the result that /you/
> want? All C compilers I've tried give:
>
> -2147483648
> -429496729
>
> for x and y.
I am assuming that the value /you/ want is -429496729. There is no
result that /I/ want - it is undefined behaviour, I am happy with that,
and I would not write code that asked for 1 << 31. (I have a strict
policy of only using bitwise operation on unsigned types - this is not
going to happen accidentally in my code.)
Tell me, what results did you get when you tried this on a DEC Alpha?
Or when you say, "all the C compilers I've tried", do you mean a few
mainstream C x86 compilers, and a few x86
toy/experimental/limited/partial C compilers ?
>
> After calculating 1 << 31 to get
>> 0x80000000 in the the 64-bit register,
>
> If this is executing C code, calculations should be widened to 32 bits
> but no further. Unless you are telling me that:
>
> int x=1; // sizeof int=4
> int y=x<<36; // or (x<<18)<<18 if preferred
> int z=y>>28;
>
> giving a result of z==256 (because it retains 64-bit intermediate
> register contents between assignments) is valid C behaviour.
Yes, it is perfectly valid. It would be perfectly valid - but rather
unlikely - even on 32-bit systems. But it is possible that you'd get
that result on some 64-bit systems - it is certainly far more likely
than the equally valid answer of 42.
>
> If you are saying that that z==256 is an acceptable result (compared
> with z==0) because of UB, that then strikes me as a bad thing, not good,
> because now you don't know what the hell a piece of code is going to do.
The trick to knowing what code will do, is to write sensible and valid
code. If you write code that has undefined behaviour, then you don't
know what it will do.
(My preferred result here is a compiler warning. That is what gcc will
give on the above code. Other reasonable results include a slap on the
wrist from the person doing the code review, or run-time errors when
compiled with run-time checks, or failures of test suites for the code.)
>
> (Note that left-shifting a 32-bit value by 36 bits /is/ poorly defined
> in hardware. On x64, it will only use the bottom 5 bits of the 36, so
> will shift by 4. Other machines my be different.)
If you are curious, gcc actually /does/ give partially specified
behaviour for 1 << 31. It is not required to do so by the C standards,
and unfortunately it does not document it very well:
"""
Bitwise operators act on the representation of the value including both
the sign and value bits, where the sign bit is considered immediately
above the highest-value value bit. Signed ‘>>’ acts on negative numbers
by sign extension.
As an extension to the C language, GCC does not use the latitude given
in C99 and C11 only to treat certain aspects of signed ‘<<’ as
undefined. However, -fsanitize=shift (and -fsanitize=undefined) will
diagnose such cases. They are also diagnosed where constant expressions
are required.
"""
As far as I can figure out, this means that 1 << 31 will give
-0x80000000 (on 32-bit gcc targets). But it will not be accepted in all
circumstances. gcc accepts:
int a[1u << 31];
but not
int a[1 << 31];
Such treatment is perfectly allowed by the C standards. Whether you
think it is good treatment or not, is up to you.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-22 16:05 +0000 |
| Message-ID | <2J7lE.185089$1p7.119303@fx05.am4> |
| In reply to | #142242 |
On 22/03/2019 15:10, David Brown wrote:
> On 22/03/2019 15:40, Bart wrote:
>> So what language is? (I don't count HLAs here.)
>
> What is the next language sideways from Lisp?
>
> It's a meaningless question.
Is C higher or lower level than Python? That's easy to answer. In that
case it shouldn't be hard to find a language X which is higher level
than ASM, and lower level than X, and that is portable.
But if X is elusive, then it might well be that C is the X I'm looking
for. In other words, the next one up from ASM. The one you said 'Nope'
too (and which made thing think, you seeming so certain, that you knew
of one for which you'd say 'Yep').)
>>> The example he gave was:
>>>
>>> int x = 1 << 31;
>>> int y = x / 5;
> The point is, you are not loading a 32-bit signed int value -0x80000000
> into a 64-bit register. You are loading a 32-bit signed int value 1
> into the 64-bit register, then shifting it 31 bits left, then dividing
> it by 5.
>
> At no point does C require an intermediary value of -0x80000000.
I don't believe this. Or it is you not understanding how C has to work.
You are saying that here:
int32_t x = f();
int32_t y = <some expression involving x, such as x>>8>
it is acceptable to use a 64-bit version of x, even though x is only 32
bits, because it's using a value left over in a 64-bit register from
some immediately prior calculation of x.
If that is actually what C allows, then it is even crazier than I'd
already thought, and that is saying something.
If you are saying that that is only allowed because of UB, then that
does little to change my opinion. It is certainly more crazy stuff that
the OP is complaining about.
> Tell me, what results did you get when you tried this on a DEC Alpha?
> Or when you say, "all the C compilers I've tried", do you mean a few
> mainstream C x86 compilers, and a few x86
> toy/experimental/limited/partial C compilers ?
I tried some C and C++ compilers on rextester.com. I don't know what
hardware they ran on, but they all gave the same results as on my PC.
I also tried it on my new language which is all 64-bit, uses 64-bit
registers, and promotes narrower types to 64-bits (my current one
doesn't promote).
It still gave the same results, because the x in 'x/5' MUST be a 32-bit
quantity, since x has a 32-bit type. However, if I define y like this:
int32 y:=(1<<31)/5
then it will give the other result (a positive value), because (1<<31)
is representable as 64 bits, and calculations are done as 64 bits.
So, you say the C compiler on DEC Alpha will give a nonsensical result?
That's something to stay clear of then, rather than it putting forward
as some sort of bizarre argument for C being superior because of its UB.
All I see is a bug.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-22 11:54 -0700 |
| Message-ID | <lnbm22g2ox.fsf@kst-u.example.com> |
| In reply to | #142244 |
Bart <bc@freeuk.com> writes:
[...]
> You are saying that here:
>
> int32_t x = f();
> int32_t y = <some expression involving x, such as x>>8>
>
> it is acceptable to use a 64-bit version of x, even though x is only 32
> bits, because it's using a value left over in a 64-bit register from
> some immediately prior calculation of x.
>
> If that is actually what C allows, then it is even crazier than I'd
> already thought, and that is saying something.
>
> If you are saying that that is only allowed because of UB, then that
> does little to change my opinion. It is certainly more crazy stuff that
> the OP is complaining about.
If the evaluation of the expression has undefined behavior, then yes,
literally anything is allowed. That's what undefined behavior means.
I'm not sure why you chose x>>8 as your example. That never
has undefined behavior. If x is negative, the result is
implementation-defined; otherwise, the result is well defined.
I think you know what "undefined behavior" means in C, but either
you refuse to accept it or you pretend to refuse to accept 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-22 19:19 +0000 |
| Message-ID | <tzalE.538943$uD1.435519@fx33.am4> |
| In reply to | #142254 |
On 22/03/2019 18:54, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> You are saying that here:
>>
>> int32_t x = f();
>> int32_t y = <some expression involving x, such as x>>8>
>>
>> it is acceptable to use a 64-bit version of x, even though x is only 32
>> bits, because it's using a value left over in a 64-bit register from
>> some immediately prior calculation of x.
>>
>> If that is actually what C allows, then it is even crazier than I'd
>> already thought, and that is saying something.
>>
>> If you are saying that that is only allowed because of UB, then that
>> does little to change my opinion. It is certainly more crazy stuff that
>> the OP is complaining about.
>
> If the evaluation of the expression has undefined behavior, then yes,
> literally anything is allowed. That's what undefined behavior means.
>
> I'm not sure why you chose x>>8 as your example.
Because it can introduce bits from the top half of a register.
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.
Then the low half of 0xFF000000 is written to y, rather than zero (ie.
0>>8).
This is what I said was crazy, whether it was done for signed/unsigned x
or y, or even only for signed x/y due to UB.
Because tweak the source code a little:
int32_t x = f();
g();
int32_t y = x>>8;
so that R0 is flushed, and now it has to physically reload x. Since it
has value 0, R0 ends up, sign-extended, as 0x00000000_00000000. You get
a different result.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-22 12:29 -0700 |
| Message-ID | <ln36neg124.fsf@kst-u.example.com> |
| In reply to | #142257 |
Bart <bc@freeuk.com> writes:
> On 22/03/2019 18:54, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> You are saying that here:
>>>
>>> int32_t x = f();
>>> int32_t y = <some expression involving x, such as x>>8>
>>>
>>> it is acceptable to use a 64-bit version of x, even though x is only 32
>>> bits, because it's using a value left over in a 64-bit register from
>>> some immediately prior calculation of x.
>>>
>>> If that is actually what C allows, then it is even crazier than I'd
>>> already thought, and that is saying something.
>>>
>>> If you are saying that that is only allowed because of UB, then that
>>> does little to change my opinion. It is certainly more crazy stuff that
>>> the OP is complaining about.
>>
>> If the evaluation of the expression has undefined behavior, then yes,
>> literally anything is allowed. That's what undefined behavior means.
>>
>> I'm not sure why you chose x>>8 as your example.
>
> Because it can introduce bits from the top half of a register.
No, it can't, because the >> operator is not defined in terms of
whatever shift instructions the CPU happens to provide.
If x is non-negative, then x>>8 yields the integral part of x/256.
If x is negative, the result of x>>8 is implementation-defined.
A conforming compiler will do whatever it needs to do to satisfy that
requirement.
> 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.
> Then the low half of 0xFF000000 is written to y, rather than zero (ie.
> 0>>8).
>
> This is what I said was crazy, whether it was done for signed/unsigned x
> or y, or even only for signed x/y due to UB.
You said "due to UB", but you used an example with no undefined
behavior.
If your example exhibited undefined behavior, then yes, a compiler
could generate code that uses garbage from the upper half of a
64-bit register. Feel free to present an example that actually
illustrates your point.
[...]
--
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-22 19:36 +0000 |
| Message-ID | <2PalE.135956$Ef4.37063@fx38.am4> |
| In reply to | #142258 |
On 22/03/2019 19:29, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 22/03/2019 18:54, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> [...] >>>> You are saying that here: >>>> >>>> int32_t x = f(); >>>> int32_t y = <some expression involving x, such as x>>8> >>>> >>>> it is acceptable to use a 64-bit version of x, even though x is only 32 >>>> bits, because it's using a value left over in a 64-bit register from >>>> some immediately prior calculation of x. >>>> >>>> If that is actually what C allows, then it is even crazier than I'd >>>> already thought, and that is saying something. >>>> >>>> If you are saying that that is only allowed because of UB, then that >>>> does little to change my opinion. It is certainly more crazy stuff that >>>> the OP is complaining about. >>> >>> If the evaluation of the expression has undefined behavior, then yes, >>> literally anything is allowed. That's what undefined behavior means. >>> >>> I'm not sure why you chose x>>8 as your example. >> >> Because it can introduce bits from the top half of a register. > > No, it can't, because the >> operator is not defined in terms of > whatever shift instructions the CPU happens to provide. > > If x is non-negative, then x>>8 yields the integral part of x/256. > If x is negative, the result of x>>8 is implementation-defined. > > A conforming compiler will do whatever it needs to do to satisfy that > requirement. > >> 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-22 13:54 -0700 |
| Message-ID | <lny356eikx.fsf@kst-u.example.com> |
| In reply to | #142259 |
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;
which has undefined behavior (again, assuming 32-bit int). Your example
does not have undefined behavior. Unless I've missed something, you are
misrepresenting what David wrote.
--
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 13:33 +0000 |
| Message-ID | <4BqlE.730757$RBa.544247@fx15.am4> |
| In reply to | #142265 |
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. 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. 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? 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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-23 14:46 +0000 |
| Message-ID | <871s2xtzre.fsf@bsb.me.uk> |
| In reply to | #142281 |
Bart <bc@freeuk.com> writes: >> Bart <bc@freeuk.com> writes: >>> int32_t x = f(); >>> int32_t y = <some expression involving x, such as x>>8> > Imagine that the f(x) in my example returned the value of 1<<31 as an > int32_t type. The value of 1 << 31 is not representable as an int32_t so your example is undefined and mean all bets are off. Depending on the width of the implementation's int, 1 << 31 may be undefined by itself. Maybe you meant that f() returns INT32_C(INT32_MIN)? It's much better to give an actual example, otherwise all the answers have to loaded with hypotheticals -- if this is undefined then that, but if it's defined and right shifts are signed then something else... Given an full example that you think will "go wrong" when 64-bit intermediaries are used. Explain the implementation. For example, 32-bit 2's complement ints with sign-propagating right shifts. Don't forget to say what actual value f() returns (if you use such a function call in the example). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 15:00 +0000 |
| Message-ID | <8SrlE.413614$%B.97090@fx03.am4> |
| In reply to | #142286 |
On 23/03/2019 14:46, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >>> Bart <bc@freeuk.com> writes: > >>>> int32_t x = f(); >>>> int32_t y = <some expression involving x, such as x>>8> > >> Imagine that the f(x) in my example returned the value of 1<<31 as an >> int32_t type. > > The value of 1 << 31 is not representable as an int32_t so your example > is undefined and mean all bets are off. Depending on the width of the > implementation's int, 1 << 31 may be undefined by itself. Maybe you > meant that f() returns INT32_C(INT32_MIN)? > > It's much better to give an actual example, otherwise all the answers > have to loaded with hypotheticals -- if this is undefined then that, but > if it's defined and right shifts are signed then something else... > > Given an full example that you think will "go wrong" when 64-bit > intermediaries are used. Explain the implementation. For example, > 32-bit 2's complement ints with sign-propagating right shifts. Don't > forget to say what actual value f() returns (if you use such a function > call in the example). The suggestion further up the thread (starting from antispam's post I think) was that results depend on whether 64-bit registers are used, and/or 64-bit instructions, presumably because in that case the 32-bit C expression '1<<31' does not overflow in its intermediate 64-bit value. I said that wouldn't matter, because in my example, the result must be written to 32-bit x, before it can be used to initialise y. At which point it will have the same value as 1<<31 evaluated as 32 bits. So it was up to other people to persuade me how it would be different. While David Brown suggested that the 64-bit intermediate representation of x persists even between 'int32_t x = f()' and its use in 'int32_t y=x>>8', and then confirmed that view. It's not yet clear whether that only applies in the case of UB (when it becomes irrelevant since the behaviour could be anything), or whether that is an allowed behaviour in general: a 64-bit intermediate value of a 32-bit expression can persist across statements.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-23 15:24 +0000 |
| Message-ID | <87va09sjff.fsf@bsb.me.uk> |
| In reply to | #142287 |
Bart <bc@freeuk.com> writes: > On 23/03/2019 14:46, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>>> Bart <bc@freeuk.com> writes: >> >>>>> int32_t x = f(); >>>>> int32_t y = <some expression involving x, such as x>>8> >> >>> Imagine that the f(x) in my example returned the value of 1<<31 as an >>> int32_t type. >> >> The value of 1 << 31 is not representable as an int32_t so your example >> is undefined and mean all bets are off. Depending on the width of the >> implementation's int, 1 << 31 may be undefined by itself. Maybe you >> meant that f() returns INT32_C(INT32_MIN)? >> >> It's much better to give an actual example, otherwise all the answers >> have to loaded with hypotheticals -- if this is undefined then that, but >> if it's defined and right shifts are signed then something else... >> >> Given an full example that you think will "go wrong" when 64-bit >> intermediaries are used. Explain the implementation. For example, >> 32-bit 2's complement ints with sign-propagating right shifts. Don't >> forget to say what actual value f() returns (if you use such a function >> call in the example). > > The suggestion further up the thread (starting from antispam's post I > think) was that results depend on whether 64-bit registers are used, > and/or 64-bit instructions, presumably because in that case the 32-bit > C expression '1<<31' does not overflow in its intermediate 64-bit > value. I think it's unwise for you to presume what anyone else means. Just ask. I, for one, have no idea what your example really is. I understood DB's example but I did not comment because he was commenting on it, and more voices would not have helped. > I said that wouldn't matter, because in my example, the result must be > written to 32-bit x, before it can be used to initialise y. At which > point it will have the same value as 1<<31 evaluated as 32 bits. > > So it was up to other people to persuade me how it would be different. Which is why I asked for a actual example -- code plus some implementation information. If you don't want to provide that, that's fine, but it makes persuading you of anything very hard indeed. > While David Brown suggested that the 64-bit intermediate > representation of x persists even between 'int32_t x = f()' and its > use in 'int32_t y=x>>8', and then confirmed that view. That's certainly possible. Why do you think it isn't? To explain in any more detail you would have to give an actual example. What does f() return? What width are ints and so on? > It's not yet clear whether that only applies in the case of UB (when > it becomes irrelevant since the behaviour could be anything), or > whether that is an allowed behaviour in general: a 64-bit intermediate > value of a 32-bit expression can persist across statements. I thought you were striving for an example without UB, but then you talked about "the value of 1 << 31 as an int32_t" which is not properly defined. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web