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 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 18:23 +0000 |
| Message-ID | <xQulE.948206$OGY.812464@fx08.am4> |
| In reply to | #142288 |
On 23/03/2019 15:24, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>>>>>> int32_t x = f();
>>>>>> int32_t y = <some expression involving x, such as x>>8>
>> 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?
Because it would be nonsense. Take this line:
int32_t x = f();
Say f() returns an in64_t result via a 64-bit register, and the bottom
32 bits are stored in x, and the top 32 bits are 'discarded'.
Now later on in the program (the next line in my example, or it could be
100 lines further; it should make no difference), the 32-bit value of x
is used, loaded into a 64-bit register.
Are you saying a program should somehow be able to remember those
discarded bits for the top half of that register (say, if they haven't
been overwritten by something else), whatever they were, rather than
properly sign-extend the current value of x? (Which then yields a top
half of all 0s or all 1s.)
That would be extraordinarily sloppy. And indeterminate (who knows what
goes on in between that write of x and subsequent read, or what
registers are used).
As for UB, David Brown is saying that if f() calculates 1<<31, that is
UB on a system with int==32 bits (whether the hardware is 64-bit only).
And that that UB then undermines the behaviour of everything that
subsequently happens in the program.
But this cannot explain why those garbage bits are carried over. The
code that determines whether that happens is generated at compile-time.
At compile-time, it doesn't know whether f() is generating a UB or not.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-23 22:40 +0000 |
| Message-ID | <878sx5rz8i.fsf@bsb.me.uk> |
| In reply to | #142304 |
Bart <bc@freeuk.com> writes: > On 23/03/2019 15:24, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>>>>>> int32_t x = f(); >>>>>>> int32_t y = <some expression involving x, such as x>>8> > >>> 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? > > Because it would be nonsense. Take this line: > > int32_t x = f(); > > Say f() returns an in64_t result via a 64-bit register, and the bottom > 32 bits are stored in x, and the top 32 bits are 'discarded'. The top 33 bits of the value are either zero or a signal is raised at this point. All bets are off if the signal is raised, so we can assume the top 33 bits are zeros on the next line. (I'm playing devil's advocate here. Since you won't give a full example, I'm going to say what the implementation I have in my mind will do.) > Now later on in the program (the next line in my example, or it could > be 100 lines further; it should make no difference), the 32-bit value > of x is used, loaded into a 64-bit register. There's no need to load it again. The program either terminated when the signal was raised, or the register still has a value in it that is less then or equal to INT32_MAX. You gave an example when the value was used on the next line. What a compiler might be able to do if there are 100 other lines of code between the two you gave is another question. Since compilers know when registers get used, it certainly /could/ know that the contents are still valid much later on. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 22:59 +0000 |
| Message-ID | <YSylE.361686$U64.192017@fx20.am4> |
| In reply to | #142318 |
On 23/03/2019 22:40, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >>>>>>>> int32_t x = f(); >>>>>>>> int32_t y = <some expression involving x, such as x>>8> >> Now later on in the program (the next line in my example, or it could >> be 100 lines further; it should make no difference), the 32-bit value >> of x is used, loaded into a 64-bit register. > > There's no need to load it again. The program either terminated when > the signal was raised, or the register still has a value in it that is > less then or equal to INT32_MAX. > > You gave an example when the value was used on the next line. What a > compiler might be able to do if there are 100 other lines of code > between the two you gave is another question. Since compilers know when > registers get used, it certainly /could/ know that the contents are > still valid much later on. But what is the programmer to make of it? You want the behaviour of 'x>>8' to depend only on the current value of 'x', not be dependent on what other operations have been done since it was set. If C actually allows that, then it's a language bug.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 16:24 -0700 |
| Message-ID | <lnzhplcgz2.fsf@kst-u.example.com> |
| In reply to | #142320 |
Bart <bc@freeuk.com> writes:
[...]
> But what is the programmer to make of it? You want the behaviour of
> 'x>>8' to depend only on the current value of 'x', not be dependent on
> what other operations have been done since it was set.
The behavior of x>>8 in C depends only on the current value of x. The
result is implementation-defined if x is negative, strictly defined if x
is non-negative.
That assumes the behavior of the program as a whole is not undefined.
If you have:
x/0;
printf("%d\n", x>>8);
then the behavior of the program is undefined.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-24 01:57 +0000 |
| Message-ID | <87ftrdqbk7.fsf@bsb.me.uk> |
| In reply to | #142320 |
Bart <bc@freeuk.com> writes: > On 23/03/2019 22:40, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>>>>>>>> int32_t x = f(); >>>>>>>>> int32_t y = <some expression involving x, such as x>>8> > >>> Now later on in the program (the next line in my example, or it could >>> be 100 lines further; it should make no difference), the 32-bit value >>> of x is used, loaded into a 64-bit register. >> >> There's no need to load it again. The program either terminated when >> the signal was raised, or the register still has a value in it that is >> less then or equal to INT32_MAX. >> >> You gave an example when the value was used on the next line. What a >> compiler might be able to do if there are 100 other lines of code >> between the two you gave is another question. Since compilers know when >> registers get used, it certainly /could/ know that the contents are >> still valid much later on. > > But what is the programmer to make of it? You want the behaviour of > 'x>>8' to depend only on the current value of 'x', not be dependent on > what other operations have been done since it was set. > > If C actually allows that, then it's a language bug. Allows what? The raising of a signal? Using a previous register value provided the result comes out right? All of these are allowed. What is the language bug you see? I have no idea what you are driving at. Please, please, give an actual example where you think something will go wrong. If you don't given an actual example, there's just no point in continuing. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 11:14 +0000 |
| Message-ID | <SEJlE.209711$kh.130610@fx27.am4> |
| In reply to | #142330 |
On 24/03/2019 01:57, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> But what is the programmer to make of it? You want the behaviour of >> 'x>>8' to depend only on the current value of 'x', not be dependent on >> what other operations have been done since it was set. >> >> If C actually allows that, then it's a language bug. > > Allows what? The raising of a signal? Using a previous register value > provided the result comes out right? All of these are allowed. What is > the language bug you see? > > I have no idea what you are driving at. Please, please, give an actual > example where you think something will go wrong. If you don't given an > actual example, there's just no point in continuing. It's not me suggesting this. One or two have said that if 32-bit 'x' is the truncated result of some 64-bit calculation, then a subsequent use of 'x' will not just use of its current 32-bit value (sign-extended to 64-bit), but could make use of the original 64-bit calculation if that is still lying around, where the top half isn't all 0s or 1s. I don't know how many times I need to repeat all this; you can look at the previous posts if you like. For example: 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. Although I suppose people will backtrack and say that would only happen with UB. I don't think anyone has an actual example where that happens, just supposition. I'm saying that would be totally wrong, even if it's only done when UB happens. In my example when f()'s definition is not visible, the statically generated code must be the same for both UB and non-UB situations. In any case, I thought the odd behaviour of UB was due to a compiler assuming that UB can never happen, in which case using a phantom 64-bit value of x /due to nothing being amiss/ would be even more bizarre. You see what happens with UB? Get rid of some it, and we wouldn't have many of these pointless debates. I'm not going to continue with this; as I mentioned, it's all been said already.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-24 14:01 +0000 |
| Message-ID | <874l7sqslj.fsf@bsb.me.uk> |
| In reply to | #142333 |
Bart <bc@freeuk.com> writes: > On 24/03/2019 01:57, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> But what is the programmer to make of it? You want the behaviour of >>> 'x>>8' to depend only on the current value of 'x', not be dependent on >>> what other operations have been done since it was set. >>> >>> If C actually allows that, then it's a language bug. >> >> Allows what? The raising of a signal? Using a previous register value >> provided the result comes out right? All of these are allowed. What is >> the language bug you see? >> >> I have no idea what you are driving at. Please, please, give an actual >> example where you think something will go wrong. If you don't given an >> actual example, there's just no point in continuing. > > It's not me suggesting this. One or two have said that if 32-bit 'x' > is the truncated result of some 64-bit calculation, then a subsequent > use of 'x' will not just use of its current 32-bit value > (sign-extended to 64-bit), but could make use of the original 64-bit > calculation if that is still lying around, where the top half isn't > all 0s or 1s. If you don't have an example, we can't continue. I've explained how a 64-bit register could be usined in one case in one example you gave. The results are, in that case, correct. > I don't know how many times I need to repeat all this; you can look at > the previous posts if you like. You cut my explanation of your example with no comment on the fact that the 64-bit value can be used correctly. I assumed you agreed. If you don't, go back say why you don't agree. > 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. > > Although I suppose people will backtrack and say that would only > happen with UB. I don't think anyone has an actual example where that > happens, just supposition. No I explained and you appeared not to comment on it. I say "appeared" because I suspect you probably think that your tangential remarks are direct comments, but I could se not criticism of what I wrote. > I'm saying that would be totally wrong, even if it's only done when UB > happens. Yes, we all get that. If that is your only point -- that you don't like what C guarantees about the results of certain program then we can leave it there, surely? > I'm not going to continue with this; as I mentioned, it's all been > said already. Sorry, I should have read to the end first. That seems like a fine plan. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 16:11 +0100 |
| Message-ID | <q786m5$lj4$1@dont-email.me> |
| In reply to | #142333 |
On 24/03/2019 12:14, Bart wrote:
> On 24/03/2019 01:57, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> But what is the programmer to make of it? You want the behaviour of
>>> 'x>>8' to depend only on the current value of 'x', not be dependent on
>>> what other operations have been done since it was set.
>>>
>>> If C actually allows that, then it's a language bug.
>>
>> Allows what? The raising of a signal? Using a previous register value
>> provided the result comes out right? All of these are allowed. What is
>> the language bug you see?
>>
>> I have no idea what you are driving at. Please, please, give an actual
>> example where you think something will go wrong. If you don't given an
>> actual example, there's just no point in continuing.
>
> It's not me suggesting this. One or two have said that if 32-bit 'x' is
> the truncated result of some 64-bit calculation, then a subsequent use
> of 'x' will not just use of its current 32-bit value (sign-extended to
> 64-bit), but could make use of the original 64-bit calculation if that
> is still lying around, where the top half isn't all 0s or 1s.
>
> I don't know how many times I need to repeat all this; you can look at
> the previous posts if you like. For example:
>
> 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.
>
> Although I suppose people will backtrack and say that would only happen
> with UB. I don't think anyone has an actual example where that happens,
> just supposition.
>
> I'm saying that would be totally wrong, even if it's only done when UB
> happens. In my example when f()'s definition is not visible, the
> statically generated code must be the same for both UB and non-UB
> situations.
>
> In any case, I thought the odd behaviour of UB was due to a compiler
> assuming that UB can never happen, in which case using a phantom 64-bit
> value of x /due to nothing being amiss/ would be even more bizarre.
>
> You see what happens with UB? Get rid of some it, and we wouldn't have
> many of these pointless debates.
>
> I'm not going to continue with this; as I mentioned, it's all been said
> already.
It's a shame that you get this so jumbled so often. Let me try to write
it one more time, and after that we must give up trying to teach you
about C. Please let me know if you understand and accept these points.
(It doesn't matter if you like them or not, or think they are a bad idea
- you can't argue about how you think C could be better until you
understand how it actually works.)
1. If code executes something with undefined behaviour, then anything
after that is irrelevant - the compiler has /no/ obligations to generate
code or results that the programmer would expect.
So given:
int foo(int x) {
int y = 1 << 31;
return x;
}
the compiler can implement the code as though it were:
int foo(int x) {
return 42;
}
2. Compilers generally /don't/ generate nonsense, even in the face of
undefined behaviour. They might use it to generate code that is smaller
and faster on the assumption that the undefined behaviour does not occur.
3. gcc, and many other compilers, provide a definition of 1 << 31 in at
least some use-cases. Thus on those implementations, this is defined
behaviour, not undefined behaviour. Implementations are always free to
define behaviour that the C standards don't define. This means that for
this particular case (but not most undefined behaviour), you are
unlikely to see results that are inconsistent with 1 << 31 being
calculated as -0x80000000.
4. Compilers can, and do, optimise on the basis of undefined behaviour
and the assumption that it does not occur. Consider this function
(picked because you can test it on godbolt.org) :
int foo(int x) {
int y = x * x * 12345 + 67890;
return (y & 0x80000000);
}
The compiler can see that y can never be negative, no matter what value
x has. So the return value is always 0, and the compiler generates code
matching a simple "return 0;". (gcc 7 and clang 3.6 onwards are both
smart enough to do this transformation.)
5. The same logic means that if you have this:
int foo(int x) {
int y = x * x * 12345 + 67890;
return y >> 8;
}
then the compiler can do the operations all using 64-bit instructions
and 64-bit registers, and return the results in a 64-bit register. It
knows that the results will be correct (and have 0 in the upper half of
the results register) when "foo" is called with any value of "x" for
which the calculations do not overflow - and it does not care what the
results are if the calculations /do/ overflow.
(Whether or not it does use 64-bit registers and instructions will
depend on the processor, and which instructions are most efficient.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-25 07:34 -0700 |
| Message-ID | <86tvfrm39d.fsf@mailhub.linuxsc.com> |
| In reply to | #142318 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Bart <bc@freeuk.com> writes: > >> On 23/03/2019 15:24, Ben Bacarisse wrote: >> >>> Bart <bc@freeuk.com> writes: >>> >>>>>>>> int32_t x = f(); >>>>>>>> int32_t y = <some expression involving x, such as x>>8> >>>> >>>> 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? >> >> Because it would be nonsense. Take this line: >> >> int32_t x = f(); >> >> Say f() returns an in64_t result via a 64-bit register, and the bottom >> 32 bits are stored in x, and the top 32 bits are 'discarded'. > > The top 33 bits of the value are either zero or a signal is raised at > this point. All bets are off if the signal is raised, so we can assume > the top 33 bits are zeros on the next line. Is there some reason the top 33 bits couldn't be all ones (indicating a negative number) rather than all zeroes? I'm not sure if there is an unstated assumption that precludes that possibility.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-25 17:11 +0000 |
| Message-ID | <87bm1yop58.fsf@bsb.me.uk> |
| In reply to | #142410 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Bart <bc@freeuk.com> writes: >> >>> On 23/03/2019 15:24, Ben Bacarisse wrote: >>> >>>> Bart <bc@freeuk.com> writes: >>>> >>>>>>>>> int32_t x = f(); >>>>>>>>> int32_t y = <some expression involving x, such as x>>8> >>>>> >>>>> 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? >>> >>> Because it would be nonsense. Take this line: >>> >>> int32_t x = f(); >>> >>> Say f() returns an in64_t result via a 64-bit register, and the bottom >>> 32 bits are stored in x, and the top 32 bits are 'discarded'. >> >> The top 33 bits of the value are either zero or a signal is raised at >> this point. All bets are off if the signal is raised, so we can assume >> the top 33 bits are zeros on the next line. > > Is there some reason the top 33 bits couldn't be all ones > (indicating a negative number) rather than all zeroes? I'm not > sure if there is an unstated assumption that precludes that > possibility. No, you are right. The shift will still work using the 64-bit register value except where the top bits are a mix of zeros and ones which is what would, in fact, trigger the signal. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-23 11:41 -0400 |
| Message-ID | <XsslE.63325$cD4.852@fx07.iad> |
| In reply to | #142287 |
On 3/23/19 11:00 AM, Bart wrote: > > 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. My understanding is that if no undefined behavior has occurred, then if the register holding x is bigger than x, and has upper bits in a configuration that make it have a value other than the now value of x, then those upper bits can't be allowed to influence a result that doesn't itself create undefined behavior. This comes from the fact that C defines operators on the VALUES in the abstract machine (which doesn't have those extra bits). Now one key point is that how would those upper bits have a value that differ without UB occurring? Unsigned 'overflow' has defined behavior, so that needs to be satisfied. Signed overflow has UB, so that can't generate the condition (since you are asking without overflow) Signed overflow at assignment (computation was 64 bits, but x was one 32 bits, and value is outside range of a 32 bit signed value) then the results are implementation defined (or a signal raised), and that value so defined must be something stored into the 32 bit object. This seems to exclude using the extra bits in the register. (Now, if the implementation defines the 32 bit type as having 32 padding bits + 32 value bits, and takes 64 bits in memory, and that result is a 'trap' representation, maybe they get closer to being able to argue this). I think that covers all the possibilities.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-23 19:52 +0000 |
| Message-ID | <q762qj$l7h$1@z-news.wcss.wroc.pl> |
| In reply to | #142287 |
Bart <bc@freeuk.com> wrote:
>
> 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.
First, there is no such thing as "written to 32-bit". Compiler
can keep variables in register, and on 64-bit machines registers
are effectively 64-bit (when you use "32-bit operations" on
Intel/AMD machines you get 64-bit result with high bit set to 0).
If there are enough registers there is no need to allocate memory
for variables. And even if compiler allocate varieble to memory
it can still keep it in register during execution of several
instructions. The "only" condition compiler has is to provide
effects descibed in standard (plus possibly extra promises in
compiler documentation).
>
> 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.
Well, by definition overflow appears when result of infintely
precise operations disagree with finite precision result of
machine arithemtic. Assuming that that there are no overflow
it does not matter if you use 64-bit arithmetic or 32-bit
one: by definition they give the same result (which you could
also obtain using infinite precision). Difference can only
appear when there is overflow. Now, assuming that all cases
of overflow for for signed integers are undefined behaviour
in C (of course somebody should _carefuly_ read standard to
check if C definitions agree with what I wrote above) this
means as long as there is no UB 64-bit and 32-bit arithemtic
agree, so compiler can keep intermediate values in 64-bit registers.
If there is UB, then compiler has free hand to do anything.
So in _both_ cases can keep intermediate values in 64-bit registers.
You should read about PL/1. PL/1 was specified results of
almost all operations. Implementers found out that it was
very hard to optimize, because language rules essentialy forced
use of naive sequences of operations. Users found PL/1
frustrationg because it gave precisely specified useless
results insted of error messages. And you can see effects:
PL/1 was pushed by biggest computer company in the world and
now is almost forgotten. Next generation of languages,
C, Pascal and followers used this experience and specs
contain UB when apriopriate. It seems that now PL/1
experience is so forgotten that software compunity may
need another expensive lesson...
BTW: Ritchie explicitly wrote that C differs from PL/1 by
leaving many things undefined.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 22:30 +0000 |
| Message-ID | <hsylE.363859$VA7.10693@fx07.am4> |
| In reply to | #142310 |
On 23/03/2019 19:52, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>>
>> 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.
>
> First, there is no such thing as "written to 32-bit". Compiler
> can keep variables in register, and on 64-bit machines registers
> are effectively 64-bit (when you use "32-bit operations" on
> Intel/AMD machines you get 64-bit result with high bit set to 0).
> If there are enough registers there is no need to allocate memory
> for variables. And even if compiler allocate varieble to memory
> it can still keep it in register during execution of several
> instructions. The "only" condition compiler has is to provide
> effects descibed in standard (plus possibly extra promises in
> compiler documentation).
Take this code:
char c = 12345678901234;
printf("%d\n", c);
Most people would be surprised if it were to print any number that is
outside the range of 'char', even if 'c' was resident in a 64-bit register.
> Now, assuming that all cases
> of overflow for for signed integers are undefined behaviour
> in C (of course somebody should _carefuly_ read standard to
> check if C definitions agree with what I wrote above) this
> means as long as there is no UB 64-bit and 32-bit arithemtic
> agree, so compiler can keep intermediate values in 64-bit registers.
> If there is UB, then compiler has free hand to do anything.
> So in _both_ cases can keep intermediate values in 64-bit registers.
Assuming no overflow is a nice luxury. But you can't guarantee that will
never happen, and runtime checks are too expensive in a low-level language.
So if and when it does happen, you want predictable results, you don't
want random things to happen that will be differ by machine, compiler
and settings. And AIUI, that happens because C /does/ assume overflow
won't happen.
I've already mentioned one solution I use myself (using 64-bit
arithmetic on 64-bit machines), then this question doesn't arise, not
for mixed 32/64-bit anyway.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 16:07 -0700 |
| Message-ID | <ln8sx5dwbq.fsf@kst-u.example.com> |
| In reply to | #142317 |
Bart <bc@freeuk.com> writes:
[...]
> Take this code:
>
> char c = 12345678901234;
>
> printf("%d\n", c);
>
> Most people would be surprised if it were to print any number that is
> outside the range of 'char', even if 'c' was resident in a 64-bit register.
Oh good, a concrete example.
12345678901234 will fit in 64 bits but not in 32, so it's of type
int, long, or long long. The value is converted from that type to
(plain) char. If plain char is unsigned, the result is well defined;
it's 242 if CHAR_BIT==8. If plain char is signed, the result of the
conversion is implementation-defined (or an implementation-defined
signal is raised); it's likely to be -14. No undefined behavior.
Remember that the rules for overflow on a conversion are different
from the rules for overflow on an arithmetic operation.
gcc 7.3.0 gives me a warning, "overflow in implicit constant
conversion". clang and later versions of gcc give a more detailed
warning, such as "implicit conversion from 'long' to 'char' changes
value from 12345678901234 to -14".
In the printf call, the value of c is promoted to int, and the
value is unchanged. (Unless CHAR_MAX > INT_MAX, which is possible
but let's ignore that.)
Assuming CHAR_BIT==8, the output must be either "242" (if plain char is
unsigned) or some value within the range of char if plain char is signed
(most commonly "-14") -- unless the implementation raises a signal on
the conversion, but I know of no implementation that does that.
I certainly would be surprised if it printed any number outside the
range of char, because that behavior would be non-conforming. If the
compiler has to do something extra to avoid letting garbage from the
upper half of a 64-bit register leak into the result, it must do so.
I think you were looking for an example that has undefined behavior.
If you want to try again, please state your assumptions explicitly
(value of CHAR_BIT, signedness of char, size of int, whatever else
is relevant to your example.)
[...]
--
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 16:42 +0100 |
| Message-ID | <q788hi$5h5$1@dont-email.me> |
| In reply to | #142317 |
On 23/03/2019 23:30, Bart wrote: > On 23/03/2019 19:52, antispam@math.uni.wroc.pl wrote: <snip - Keith answered the first bit> > >> Now, assuming that all cases >> of overflow for for signed integers are undefined behaviour >> in C (of course somebody should _carefuly_ read standard to >> check if C definitions agree with what I wrote above) this >> means as long as there is no UB 64-bit and 32-bit arithemtic >> agree, so compiler can keep intermediate values in 64-bit registers. >> If there is UB, then compiler has free hand to do anything. >> So in _both_ cases can keep intermediate values in 64-bit registers. > > Assuming no overflow is a nice luxury. But you can't guarantee that will > never happen, and runtime checks are too expensive in a low-level language. Overflows are bugs. It's rarely possible to /guarantee/ that your code is bug-free, but you certainly should be doing everything within reasonable limits to get there. Runtime checks are often expensive in finished code, but a help during debugging. > > So if and when it does happen, you want predictable results, you don't > want random things to happen that will be differ by machine, compiler > and settings. And AIUI, that happens because C /does/ assume overflow > won't happen. Why do you expect predictable results from bugs in the code? I certainly don't. I expect predictable results from correct code, but expect things to go wrong when there are bugs. I can't think of any general reason why I'd expect code bugs to produce the same result on different systems. Clearly it is /nice/ when code bugs give a clear, simple, predictable result - that's why tools like gcc/clang's sanitizers are helpful for debugging. But I don't expect defined results from undefined behaviour. > > I've already mentioned one solution I use myself (using 64-bit > arithmetic on 64-bit machines), then this question doesn't arise, not > for mixed 32/64-bit anyway. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 16:12 +0000 |
| Message-ID | <10OlE.278271$aO1.24042@fx14.am4> |
| In reply to | #142350 |
On 24/03/2019 15:42, David Brown wrote: > On 23/03/2019 23:30, Bart wrote: >> On 23/03/2019 19:52, antispam@math.uni.wroc.pl wrote: > > <snip - Keith answered the first bit> >> >>> Now, assuming that all cases >>> of overflow for for signed integers are undefined behaviour >>> in C (of course somebody should _carefuly_ read standard to >>> check if C definitions agree with what I wrote above) this >>> means as long as there is no UB 64-bit and 32-bit arithemtic >>> agree, so compiler can keep intermediate values in 64-bit registers. >>> If there is UB, then compiler has free hand to do anything. >>> So in _both_ cases can keep intermediate values in 64-bit registers. >> >> Assuming no overflow is a nice luxury. But you can't guarantee that >> will never happen, and runtime checks are too expensive in a low-level >> language. > > Overflows are bugs. It's rarely possible to /guarantee/ that your code > is bug-free, but you certainly should be doing everything within > reasonable limits to get there. Runtime checks are often expensive in > finished code, but a help during debugging. > >> >> So if and when it does happen, you want predictable results, you don't >> want random things to happen that will be differ by machine, compiler >> and settings. And AIUI, that happens because C /does/ assume overflow >> won't happen. > > Why do you expect predictable results from bugs in the code? I > certainly don't. I expect predictable results from correct code, but > expect things to go wrong when there are bugs. If I start with with 32-bit A set to 2'000'000'000, and then add 200'000'000 to it, then a result of -2'094'967'296 instead of 2'200'000'000 is a strong indication that I have an overflow situation. Then I can choose to fix that (remove a bug, use a wider type, re-order calculations etc), or choose to accept it because it doesn't matter (for example it will be converted to unsigned, or displayed as unsigned hex, or I only care about the bottom 24 bits, or it will be cancelled out by subtracting 300'000'000, etc etc. It is not help at all if a compiler chooses to randomly give me a result such as 42, or plays the National Anthem via the speaker. This is not some extra high level language where 'int' is only ever used to produce mathematically correct calculations; in low level, fixed-size 'int' types are abused for all sorts of things; you don't want a language that is getting too big for its boots to get in the way of your job. (If you did, then switch to Ada if you enjoy programming with one hand tied behind your back.) > I can't think of any > general reason why I'd expect code bugs to produce the same result on > different systems. > Clearly it is /nice/ when code bugs give a clear, simple, predictable > result Oh, now you're even agreeing with me! You should simply expect such a thing, not just be grateful whenever a compiler deigns to be helpful. - that's why tools like gcc/clang's sanitizers are helpful for > debugging. But I don't expect defined results from undefined behaviour. That's why my languages, and my C compiler, don't make a big deal out of undefined behaviour. Writing to some random out-of-bound element of an array is definitely a no-no, but adding +1 to a value of FF in AL to get 00: so what?
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-24 17:59 +0000 |
| Message-ID | <q78ghi$7qn$2@z-news.wcss.wroc.pl> |
| In reply to | #142355 |
Bart <bc@freeuk.com> wrote:
>
> Writing to some random out-of-bound element of an array is definitely a
> no-no, but adding +1 to a value of FF in AL to get 00: so what?
What is wrong with explicit truncation:
0xff & (x + 1)
And if that is too much work, than you can use Ada wich has modular
types were wraparound happens automaticaly (or define your type in
C++).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 22:19 +0100 |
| Message-ID | <q78s97$58i$1@dont-email.me> |
| In reply to | #142355 |
On 24/03/2019 17:12, Bart wrote: > On 24/03/2019 15:42, David Brown wrote: >> On 23/03/2019 23:30, Bart wrote: >>> On 23/03/2019 19:52, antispam@math.uni.wroc.pl wrote: >> >> <snip - Keith answered the first bit> >>> >>>> Now, assuming that all cases >>>> of overflow for for signed integers are undefined behaviour >>>> in C (of course somebody should _carefuly_ read standard to >>>> check if C definitions agree with what I wrote above) this >>>> means as long as there is no UB 64-bit and 32-bit arithemtic >>>> agree, so compiler can keep intermediate values in 64-bit registers. >>>> If there is UB, then compiler has free hand to do anything. >>>> So in _both_ cases can keep intermediate values in 64-bit registers. >>> >>> Assuming no overflow is a nice luxury. But you can't guarantee that >>> will never happen, and runtime checks are too expensive in a >>> low-level language. >> >> Overflows are bugs. It's rarely possible to /guarantee/ that your >> code is bug-free, but you certainly should be doing everything within >> reasonable limits to get there. Runtime checks are often expensive in >> finished code, but a help during debugging. >> >>> >>> So if and when it does happen, you want predictable results, you >>> don't want random things to happen that will be differ by machine, >>> compiler and settings. And AIUI, that happens because C /does/ assume >>> overflow won't happen. >> >> Why do you expect predictable results from bugs in the code? I >> certainly don't. I expect predictable results from correct code, but >> expect things to go wrong when there are bugs. > > If I start with with 32-bit A set to 2'000'000'000, and then add > 200'000'000 to it, then a result of -2'094'967'296 instead of > 2'200'000'000 is a strong indication that I have an overflow situation. > And how do you know you've ended up with -2 billion? Perhaps you've added extra code there to check because you think it's a likely spot for a problem in the code. So why not add such extra code in a way that is safe and correct for the language (use 64-bit ints, unsigned, compiler-specific features, or whatever suits your needs)? Your "defined" overflow has gained you nothing here. What about for cases where you don't know of likely spots? With undefined overflow, you can use a tool like gcc/clang's "-fsanitize=signed-integer-overflow". (Other tools may have similar options.) That is quite fast and unobtrusive, and will give you clear information every time you get an overflow - including in parts of your code that you did not suspect. But if overflow is defined as wraparound, you can't get that help - the compiler can't tell if your code is wrong or if you meant to write nonsense. To me, this is clearly a win for "undefined behaviour" - it makes it all much easier to find the bugs. > Then I can choose to fix that (remove a bug, use a wider type, re-order > calculations etc), or choose to accept it because it doesn't matter (for > example it will be converted to unsigned, or displayed as unsigned hex, > or I only care about the bottom 24 bits, or it will be cancelled out by > subtracting 300'000'000, etc etc. I am not keen on the idea of choosing to accept a bug. But if you mean accept the behaviour, then there are ways of writing it safely and correctly with the same results. > > It is not help at all if a compiler chooses to randomly give me a result > such as 42, or plays the National Anthem via the speaker. > An undetected bug can do that for you. That includes ones where you start off with defined but unexpected and logically incorrect behaviour. > This is not some extra high level language where 'int' is only ever used > to produce mathematically correct calculations; in low level, fixed-size > 'int' types are abused for all sorts of things; you don't want a > language that is getting too big for its boots to get in the way of your > job. (If you did, then switch to Ada if you enjoy programming with one > hand tied behind your back.) I don't abuse my "int" types. I can't see any reason why other people would either. I might /use/ them for things other than integers, but it's not abuse because I know how to use them (and I know what alternatives are available if I want something different). > >> I can't think of any general reason why I'd expect code bugs to >> produce the same result on different systems. > >> Clearly it is /nice/ when code bugs give a clear, simple, predictable >> result > > Oh, now you're even agreeing with me! You should simply expect such a > thing, not just be grateful whenever a compiler deigns to be helpful. > I think we can both agree that it would be nice with a perfect language, and tools that told you exactly where all your bugs are. That does not in any way mean we agree on undefined behaviour. > > - that's why tools like gcc/clang's sanitizers are helpful for >> debugging. But I don't expect defined results from undefined behaviour. > > That's why my languages, and my C compiler, don't make a big deal out of > undefined behaviour. You are making a big deal out of them now. Baring the occasional bug, I don't write code that relies on undefined behaviour - it is not a big deal, and it is not hard to do. And I'm glad my tools know that. And I am entirely confident that your languages and tools have undefined behaviour, and that they don't give predictable results when those happen. I am equally confident that almost every case you have of signed integer overflow - defined though it may be - is a bug in your code, and that many of these will lead to behaviour that is difficult to predict or detect. > > Writing to some random out-of-bound element of an array is definitely a > no-no, but adding +1 to a value of FF in AL to get 00: so what? > See above.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 22:13 +0000 |
| Message-ID | <aiTlE.232897$2t3.58633@fx10.am4> |
| In reply to | #142373 |
On 24/03/2019 21:19, David Brown wrote: > On 24/03/2019 17:12, Bart wrote: >> If I start with with 32-bit A set to 2'000'000'000, and then add >> 200'000'000 to it, then a result of -2'094'967'296 instead of >> 2'200'000'000 is a strong indication that I have an overflow situation. >> > > And how do you know you've ended up with -2 billion? Perhaps you've > added extra code there to check because you think it's a likely spot for > a problem in the code. So why not add such extra code in a way that is > safe and correct for the language (use 64-bit ints, unsigned, > compiler-specific features, or whatever suits your needs)? Your > "defined" overflow has gained you nothing here. Bugs can be anywhere and it any form. Overflowing the maximum value of a type is one of the simplest to find or even guess: a program works fine for data up to 30-odd thousand, but starts going wrong at some point between 32K and 33. What could it possibly be? > What about for cases where you don't know of likely spots? With > undefined overflow, you can use a tool like gcc/clang's > "-fsanitize=signed-integer-overflow". (Other tools may have similar > options.) That is quite fast and unobtrusive, and will give you clear > information every time you get an overflow - including in parts of your > code that you did not suspect. > > But if overflow is defined as wraparound, you can't get that help - the > compiler can't tell if your code is wrong or if you meant to write > nonsense. So what do you do if your program relies on unsigned types not overflowing? In fact, what do you do when calculating a value to be stored in 8-bit signed, but the expression overflows the -128..+127 range? If the result is still well within the 32-bit signed range, then presumably it doesn't count as UB. But you will get the wrong answer. I'm saying this because there seems to be far too much emphasis on the alleged problems of things like signed overflow, when there are a thousand other things to be aware of. > I don't abuse my "int" types. I can't see any reason why other people > would either. I might /use/ them for things other than integers, but > it's not abuse because I know how to use them So do I. So does everyone using such primitive types. We don't need a language making such a fuss about overflow.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-25 01:27 +0100 |
| Message-ID | <q79799$17m$1@dont-email.me> |
| In reply to | #142379 |
On 24/03/2019 23:13, Bart wrote: > On 24/03/2019 21:19, David Brown wrote: >> On 24/03/2019 17:12, Bart wrote: > >>> If I start with with 32-bit A set to 2'000'000'000, and then add >>> 200'000'000 to it, then a result of -2'094'967'296 instead of >>> 2'200'000'000 is a strong indication that I have an overflow situation. >>> >> >> And how do you know you've ended up with -2 billion? Perhaps you've >> added extra code there to check because you think it's a likely spot >> for a problem in the code. So why not add such extra code in a way >> that is safe and correct for the language (use 64-bit ints, unsigned, >> compiler-specific features, or whatever suits your needs)? Your >> "defined" overflow has gained you nothing here. > > Bugs can be anywhere and it any form. Overflowing the maximum value of a > type is one of the simplest to find or even guess: a program works fine > for data up to 30-odd thousand, but starts going wrong at some point > between 32K and 33. What could it possibly be? > For any bugs, you often have a clue as to what might be going wrong. Why would you think that having wraparound on integer overflow helps that? It may change the effect of the bug (or may not - wraparound is common behaviour for integer overflow in C. It's just not guaranteed). It is not going to make it easier to detect, just different. And it is going to stop any chance your tools have of detecting it. > > > >> What about for cases where you don't know of likely spots? With >> undefined overflow, you can use a tool like gcc/clang's >> "-fsanitize=signed-integer-overflow". (Other tools may have similar >> options.) That is quite fast and unobtrusive, and will give you clear >> information every time you get an overflow - including in parts of >> your code that you did not suspect. >> >> But if overflow is defined as wraparound, you can't get that help - >> the compiler can't tell if your code is wrong or if you meant to write >> nonsense. > > So what do you do if your program relies on unsigned types not overflowing? I don't normally overflow unsigned types either. Neither the compiler nor sanitizers can help catch such bugs, if they do occur - that makes them harder to find. Perhaps you think I write my code by random and rely on tools to find the bugs. I don't - but where there are tools available, I use them as aids. > > In fact, what do you do when calculating a value to be stored in 8-bit > signed, but the expression overflows the -128..+127 range? If the result > is still well within the 32-bit signed range, then presumably it doesn't > count as UB. But you will get the wrong answer. > Yes. The fact that it is not UB does not help - it is still wrong. > I'm saying this because there seems to be far too much emphasis on the > alleged problems of things like signed overflow, when there are a > thousand other things to be aware of. Agreed. It is merely a common example of undefined behaviour that /could/ be defined behaviour, and that some people think /should/ be defined behaviour. I notice that people who get their knickers in a twist about how terrible C's undefined behaviour is, and how signed integer overflow "obviously" should wrap, stay rather quite about access via invalid pointers, using function pointers that are not correct, or other kinds of undefined behaviour. > >> I don't abuse my "int" types. I can't see any reason why other people >> would either. I might /use/ them for things other than integers, but >> it's not abuse because I know how to use them > > So do I. So does everyone using such primitive types. We don't need a > language making such a fuss about overflow. The language does not make a fuss. It simply says that nonsensical signed integer overflow does not have a meaningful result in C.
[toc] | [prev] | [next] | [standalone]
Page 4 of 14 — ← Prev page 1 2 3 [4] 5 6 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web