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 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 16:16 +0100 |
| Message-ID | <q72u7p$2ki$1@dont-email.me> |
| In reply to | #142240 |
On 22/03/2019 15:17, Malcolm McLean wrote: > On Thursday, 21 March 2019 22:13:57 UTC, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> 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. >> >> 1 << 31 is undefined (assuming 32-bit int) for two reasons. >> >> 6.5.7p3: It's undefined because the right operand is greater than >> or equal to the width of the promoted right operand. (0 << 31 is >> undefined for the same reason.) >> >> 6.5.7p4: It's undefined because 1 * 2**31 is not representable in >> the result type. (2<<30 is undefined for the same reason.) >> > Not really. It would make sense for > I don't know what you mean by "not really" here. What Keith wrote is correct (modified by Tim's reply - the width of "int" is 32, so 6.5.7p3 does not apply and 0 << 31 is well defined). I agree that the definition you give below would have been sensible and consistent. And I agree that a reason it is not used in C is likely to be for implementation efficiency. Note, however, that 1 << 31 would still be undefined - because the final step of 0x40000000 << 1 is undefined. > int x, Nshift; > > x <<= Nshift; > > to be equal to > > for(i=0;i<Nshift;i++) > x <<= 1; > > however some processors had instructions which allowed a non-single shift, > but not out of range. So allowing x << Nshift when Nshift was out of range > would have placed additional burdens on the compiler writer. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-22 12:06 -0700 |
| Message-ID | <ln7ecqg24c.fsf@kst-u.example.com> |
| In reply to | #142243 |
David Brown <david.brown@hesbynett.no> writes:
> On 22/03/2019 15:17, Malcolm McLean wrote:
>> On Thursday, 21 March 2019 22:13:57 UTC, Keith Thompson wrote:
[...]
>>> 1 << 31 is undefined (assuming 32-bit int) for two reasons.
>>>
>>> 6.5.7p3: It's undefined because the right operand is greater than
>>> or equal to the width of the promoted right operand. (0 << 31 is
>>> undefined for the same reason.)
>>>
>>> 6.5.7p4: It's undefined because 1 * 2**31 is not representable in
>>> the result type. (2<<30 is undefined for the same reason.)
>>>
>> Not really. It would make sense for
>
> I don't know what you mean by "not really" here. What Keith wrote is
> correct (modified by Tim's reply - the width of "int" is 32, so 6.5.7p3
> does not apply and 0 << 31 is well defined).
I also have no idea what Malcolm meant by "not really".
Tim is correct, and I was not. I misremembered the meaning of "width"
for signed integer types.
The "width" includes the sign bit, so assuming 32-bit int, 1<<31 is
undefined because the result is out of range, but 0<<31 is well defined.
0<<32 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 | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-23 16:59 +0000 |
| Message-ID | <q75ole$f5u$1@z-news.wcss.wroc.pl> |
| In reply to | #142195 |
Bart <bc@freeuk.com> 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.
I am thinking about popular architecture known as amd64 or x86_64.
On that architecture 32-bit instruction produce 64-bit results
with high 32 bits set to 0. When mixing 64-bit and 32-bit signed
operations for correct result one must sign extend 32-bit value
to 64-bits. When operationg on directly 64-bit values one can
skip sign extentions. To see possible effects consider the
following silly function:
int
foo(int * ap, int * ip) {
return ap[(*ip)<<5];
}
Translation which uses wraparound has 5 instructions:
foo:
movl (%rsi), %eax
sall $5, %eax
cltq
movl (%rdi,%rax,4), %eax
ret
Translation that promotes to 64-bits has 4 instructions:
foo:
movslq (%rsi), %rax
salq $5, %rax
movl (%rdi,%rax,4), %eax
ret
Now, can you say why second translation is "wrong"? Note that
second translation has 20% less instructions than the first one
so when speed is important we would like to use second version.
And, while this is silly example quite similar issue appear
for array indexing using integer variables. Such operations
are pretty frequent in C programs, so we would like to make
them fast.
gcc defines integer shift in terms of two-complement
representation, so it has to use 5 instruction version.
AFAICS 4 instruction version is legal and there is high
chance that programmer wanted this version. Coming back
to start of this thread, if you think that second version
is acceptable what would you write in language standard
to allow it?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 21:36 +0000 |
| Message-ID | <gFxlE.386446$0_.33568@fx19.am4> |
| In reply to | #142295 |
On 23/03/2019 16:59, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> 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.
>
> I am thinking about popular architecture known as amd64 or x86_64.
> On that architecture 32-bit instruction produce 64-bit results
> with high 32 bits set to 0. When mixing 64-bit and 32-bit signed
> operations for correct result one must sign extend 32-bit value
> to 64-bits. When operationg on directly 64-bit values one can
> skip sign extentions. To see possible effects consider the
> following silly function:
>
> int
> foo(int * ap, int * ip) {
> return ap[(*ip)<<5];
> }
>
> Translation which uses wraparound has 5 instructions:
>
> foo:
> movl (%rsi), %eax
> sall $5, %eax
> cltq
> movl (%rdi,%rax,4), %eax
> ret
I don't know what clt is; I expect it is used to extend eax to rax.
I also assume it is necessary to use 64-bit addressing (as 32-bit
address registers are acceptible). In which case this highlights a
mismatch between C's common 32-bit int type, and the 64-bit index and
address values that are needed. This may be where the true problem is.
>
> Translation that promotes to 64-bits has 4 instructions:
>
> foo:
> movslq (%rsi), %rax
> salq $5, %rax
> movl (%rdi,%rax,4), %eax
> ret
>
> Now, can you say why second translation is "wrong"?
You don't need to use shift; just having ap[x+y] can show the problem
when x and y are 32 bits. Somebody expecting x+y to be cropped to 32
bits, won't want the 64-bit intermediate value that might contain more info.
This particular issue can also be solved by adopting a 64-bit default
type (that doesn't need to mean that 'int' has to be 64 bits). Then many
such UB problems disappear (or only come up on 128-bit machines).
> Coming back
> to start of this thread, if you think that second version
> is acceptable what would you write in language standard
> to allow it?
I don't think a change in the standard is needed to default to 64-bit
standard int instead of 32-bit.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-24 16:16 +0000 |
| Message-ID | <q78ah3$4u7$1@z-news.wcss.wroc.pl> |
| In reply to | #142315 |
Bart <bc@freeuk.com> wrote:
> On 23/03/2019 16:59, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
>
> >> 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.
> >
> > I am thinking about popular architecture known as amd64 or x86_64.
> > On that architecture 32-bit instruction produce 64-bit results
> > with high 32 bits set to 0. When mixing 64-bit and 32-bit signed
> > operations for correct result one must sign extend 32-bit value
> > to 64-bits. When operationg on directly 64-bit values one can
> > skip sign extentions. To see possible effects consider the
> > following silly function:
> >
> > int
> > foo(int * ap, int * ip) {
> > return ap[(*ip)<<5];
> > }
> >
> > Translation which uses wraparound has 5 instructions:
> >
> > foo:
> > movl (%rsi), %eax
> > sall $5, %eax
> > cltq
> > movl (%rdi,%rax,4), %eax
> > ret
>
> I don't know what clt is; I expect it is used to extend eax to rax.
Yes.
> I also assume it is necessary to use 64-bit addressing (as 32-bit
> address registers are acceptible). In which case this highlights a
> mismatch between C's common 32-bit int type, and the 64-bit index and
> address values that are needed. This may be where the true problem is.
Well, ALU has hardware to handle 64 bits, so using it is essentially
free. But in memory 64 bits take more space that 32 bits, so
we want smallest size that can handle needed operations.
> >
> > Translation that promotes to 64-bits has 4 instructions:
> >
> > foo:
> > movslq (%rsi), %rax
> > salq $5, %rax
> > movl (%rdi,%rax,4), %eax
> > ret
> >
> > Now, can you say why second translation is "wrong"?
>
> You don't need to use shift; just having ap[x+y] can show the problem
> when x and y are 32 bits.
Yes.
> Somebody expecting x+y to be cropped to 32
> bits, won't want the 64-bit intermediate value that might contain more info.
I personally would not like to see code using wraparound without
clear indication that this is the intent. For example:
int
foo(int * ap, int * ip) {
return ap[(int)(((unsigned int)(*ip))<<5u)];
}
Crazy casting is reasonably clear warning that something strange is
intended. Without such indication IMO the only reasonable
interpretation is that programmer knows that using 32 bits there
will be no overflow.
> This particular issue can also be solved by adopting a 64-bit default
> type (that doesn't need to mean that 'int' has to be 64 bits). Then many
> such UB problems disappear (or only come up on 128-bit machines).
>
> > Coming back
> > to start of this thread, if you think that second version
> > is acceptable what would you write in language standard
> > to allow it?
>
> I don't think a change in the standard is needed to default to 64-bit
> standard int instead of 32-bit.
Well, ask Microsoft support to increase integer size in MSVC. Or
increase integer size is your compiler and watch how programs
break.
Seriously, increasing integer size is not viable due to existing
code that expects 32-bit integers. More reasonable would be
change to C promotion rules: saying that integer type promote
to some implementation defined type. But even that would
probably break too many programs. And such rule will prohibit
some other optimizations. Namely, basic operations (+, -, *)
in 32-bit integers as long as there is no integer overflow can
be performed exactly in double precision FPU. On machine with
fast FPU like Pentium or Raspberry Pi when you run out of
integer registers you can try to use FPU registers and FPU
operations. AFAICS with current rules in code like this:
foo(int inc, ....) {
int count = 0;
....
for(....) {
....
count += inc;
....
}
....
compiler may allocate count and inc to FPU registers. Assuming
that ommited part uses all available integer registers such
code may be faster than code which uses only integer operations.
On Raspberry Pi to perform addition count and inc must be in
registers, so before addition you need to store 2 values to
make space for count and inc, than load count and inc, add,
store count and reload 2 stored values. So 6 instruction
overhead + one useful operation. If count and inc are in FPU
registers you have single FPU operation. To use all registers
on ARM you probably will have 10-20 other instructions. So
using FPU may give about 30% saving. And maybe more practical
example:
struct sv {int i1; int i2; int i3; int i4;};
void
foo(struct sv * res, struct sv * a1, struct sv * a2) {
struct sv tmp = {a1->i1 + a2->i1, a1->i2 + a2->i2,
a1->i3 + a2->i3, a1->i4 + a2->i4};
*res = tmp;
}
On my machine gcc translates this to:
foo:
movdqu (%rsi), %xmm0
movdqu (%rdx), %xmm1
paddd %xmm1, %xmm0
movups %xmm0, (%rdi)
ret
So gcc automatically uses vector istruction giving significant
speedup. This example immediately stores result so optiomization
would be valid even with changed promotion rules. But if there
are bigger expressions with intermediate results which potentially
may overflow, than with bigger default type compiler would
have to revert to scalar operations.
More generally consider:
struct st {char c1; char c2; char c3;};
long
foo(struct st * p1, struct st * p2) {
return p1 - p2;
}
gcc translates this to:
foo:
subq %rsi, %rdi
movabsq $-6148914691236517205, %rdx
movq %rdi, %rax
imulq %rdx, %rax
ret
Do you understand what this is doing and why this is faster than
naive version? What standard should say to have fully defined
pointer subtraction and allow such code?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 20:25 +0000 |
| Message-ID | <eJRlE.784813$Apg.472001@fx36.am4> |
| In reply to | #142356 |
On 24/03/2019 16:16, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> I also assume it is necessary to use 64-bit addressing (as 32-bit
>> address registers are acceptible). In which case this highlights a
>> mismatch between C's common 32-bit int type, and the 64-bit index and
>> address values that are needed. This may be where the true problem is.
>
> Well, ALU has hardware to handle 64 bits, so using it is essentially
> free. But in memory 64 bits take more space that 32 bits, so
> we want smallest size that can handle needed operations.
Yes, for storage you can use narrower types if there are a lot of them.
But registers, operations, stack slots, constants can all be 64-bit.
>> I don't think a change in the standard is needed to default to 64-bit
>> standard int instead of 32-bit.
>
> Well, ask Microsoft support to increase integer size in MSVC. Or
> increase integer size is your compiler and watch how programs
> break.
I briefly switched my C compiler to use a 64-bit 'int', and programs did
break.
What I haven't tried (and don't have the time nor inclination now) is to
have 64-bit width as the default operation size, but to keep 'int' as
32-bit.
> Seriously, increasing integer size is not viable due to existing
> code that expects 32-bit integers. More reasonable would be
> change to C promotion rules: saying that integer type promote
> to some implementation defined type. But even that would
> probably break too many programs.
Is that same as what I said above? Probably...
> some other optimizations. Namely, basic operations (+, -, *)
> in 32-bit integers as long as there is no integer overflow can
> be performed exactly in double precision FPU. On machine with
> fast FPU like Pentium or Raspberry Pi when you run out of
> integer registers you can try to use FPU registers and FPU
> operations. AFAICS with current rules in code like this:
<snip code>
The sounds like a far-fetched example. And it might already be a problem
for 32-bit default working, if it stops packed 16-bit SIMD instructions
from being used.
> More generally consider:
>
> struct st {char c1; char c2; char c3;};
>
> long
> foo(struct st * p1, struct st * p2) {
> return p1 - p2;
> }
>
> gcc translates this to:
>
> foo:
> subq %rsi, %rdi
> movabsq $-6148914691236517205, %rdx
> movq %rdi, %rax
> imulq %rdx, %rax
> ret
>
> Do you understand what this is doing and why this is faster than
> naive version?
Divide by 3?
> What standard should say to have fully defined
> pointer subtraction and allow such code?
AIUI you can't subtract two arbitrary pointers. For example, your p1 and
p2 pointers may not differ by a multiple of 3 bytes, so the result would
be meaningless.
However I'm not sure how this ties in to what we've been discussing. UB
again?
As I said, the result just wouldn't be meaningful unless p1/p2 point to
two structs separated by a integral number of such structs (technically
they have to be part of the same object). That's a program error (you
just get the wrong result), but is not serious enough to be UB.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-25 20:00 +0000 |
| Message-ID | <q7bc00$j38$1@z-news.wcss.wroc.pl> |
| In reply to | #142371 |
Bart <bc@freeuk.com> wrote:
> On 24/03/2019 16:16, antispam@math.uni.wroc.pl wrote:
>
> > More generally consider:
> >
> > struct st {char c1; char c2; char c3;};
> >
> > long
> > foo(struct st * p1, struct st * p2) {
> > return p1 - p2;
> > }
> >
> > gcc translates this to:
> >
> > foo:
> > subq %rsi, %rdi
> > movabsq $-6148914691236517205, %rdx
> > movq %rdi, %rax
> > imulq %rdx, %rax
> > ret
> >
> > Do you understand what this is doing and why this is faster than
> > naive version?
>
> Divide by 3?
Yes. When pointers are correctly aligned difference is divisible
by 3 and result is correct. Otherwise you get strange result.
> > What standard should say to have fully defined
> > pointer subtraction and allow such code?
>
> AIUI you can't subtract two arbitrary pointers. For example, your p1 and
> p2 pointers may not differ by a multiple of 3 bytes, so the result would
> be meaningless.
Yes, exactly.
> However I'm not sure how this ties in to what we've been discussing. UB
> again?
>
> As I said, the result just wouldn't be meaningful unless p1/p2 point to
> two structs separated by a integral number of such structs (technically
> they have to be part of the same object). That's a program error (you
> just get the wrong result), but is not serious enough to be UB.
Well, what about following "spec":
On incorrect inputs operation may produce strange values.
Incorect values may propagate in complicated ways leading
finally to hard to predict consequences. Compiler can
use (possibly incorrect) result even if logically it is
not needed. Compiler can change order of operations which
are indepenent in correct programs, so bad effect may
occur before naively expected point when error happened.
Compared to UB this simply says that effect of "just get the
wrong result" is unpredictable enough...
Let me give example of bug that I fixed yesterday: my assembler
code left stack unalinged on Rasperry Pi. On ARM, hardware
requires that stack pointer is divisable at least by 4, but
software convention is that stack pointer is divisable by 8.
All libraries assume this, but my code had stack pointer
that so that division by 8 gave remainder 4 and called
library functions. You may expect that some instruction
needing correct alignment would trap. Well, program
crashed but in different way. Namely, return address
of one function get overwiten by data read from a file.
New "retun address" was in area of memory marked as
unaccesible and procesor signaled memory access error
trying to execute code from there. So something that
at first may look like "bounded error" give you typical
result of UB.
Point is: once you have "just a wrong value" it is extremaly
hard to limit possible damage (without adding extra error
checking code).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-24 21:56 +0000 |
| Message-ID | <FZK8UVknfi_8@bongo-ra.co> |
| In reply to | #142356 |
On Sun, 24 Mar 2019 16:16:35 +0000 (UTC)
antispam@math.uni.wroc.pl wrote:
> More generally consider:
>
> struct st {char c1; char c2; char c3;};
>
> long
> foo(struct st * p1, struct st * p2) {
> return p1 - p2;
> }
This will be undefined behaviour if p1 and p2 don't point to the same
object.
> gcc translates this to:
>
> foo:
> subq %rsi, %rdi
> movabsq $-6148914691236517205, %rdx
> movq %rdi, %rax
> imulq %rdx, %rax
> ret
>
> Do you understand what this is doing and why this is faster than
> naive version? What standard should say to have fully defined
> pointer subtraction and allow such code?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-21 22:39 -0700 |
| Message-ID | <86wokro4c9.fsf@mailhub.linuxsc.com> |
| In reply to | #142087 |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Tue, 19 Mar 2019 14:58:43 -0700 (PDT)
> Howard Chu <highlandsun@gmail.com> wrote:
>
>> There's a proposal to change the C++ spec to declare that all
>> {} integers are two's complement.
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html
>>
>> Is there a corresponding proposed change for the C spec? It would
>> certainly simplify life and could eliminate a number of undefined
>> behaviors from the spec.
>
> You can put near the beginning of your code
>
> int main ( ...... ) {
> ......
> if ((-1 & 3) != 3) {
> fprintf(stderr , "This programme only works with two's complement "
> "integer representation\n") ;
> return EXIT_FAILURE ;
> }
> ......
> }
>
> No change to the standard needed.
Right, and there are other ways of accomplishing the same thing,
and other related checks, even at compile time using static
assertions.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-20 06:10 +0000 |
| Message-ID | <bbXgbPvO0TB2QttltgH9QFl@bongo-ra.co> |
| In reply to | #142080 |
Here's another point :
On Tue, 19 Mar 2019 14:58:43 -0700 (PDT)
Howard Chu <highlandsun@gmail.com> wrote:
> On that topic, it would be nice to see a compiler mode that makes all undefined behaviors implementation defined,
Even if it was possible to have one , what makes you think that different
compilers would define it the same way ? If not then you would either have to
avoid undefined behaviour althogether , just as you do now , or have all over
your code constructs like
#if defined _Compiler_A
.....
#elif defined _Compiler_B
.....
.
.
.
#endif
for every undefined behaviour you might want to use. Would this be simpler than
simply avoiding undefined behaviour ?
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-20 06:57 +0000 |
| Message-ID | <slrnq93p31.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #142080 |
On Tue, 2019-03-19, Howard Chu wrote: > There's a proposal to change the C++ spec to declare that all > integers are two's complement. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html Published on 1 April 2018. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2019-03-20 11:06 +0100 |
| Message-ID | <q6t3ai$8uo$1@solani.org> |
| In reply to | #142080 |
Am 19.03.19 um 22:58 schrieb Howard Chu: > There's a proposal to change the C++ spec to declare that all integers are two's complement. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html > > Is there a corresponding proposed change for the C spec? It would certainly simplify life and could eliminate a number of undefined behaviors from the spec. Yes. See N2218, discussion to be found in 6.20 of the Brno meeting minutes. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 09:24 -0700 |
| Message-ID | <f3fd8fd5-53b4-4f18-876d-9e45cc140faf@googlegroups.com> |
| In reply to | #142096 |
On Wednesday, March 20, 2019 at 10:06:20 AM UTC, Philipp Klaus Krause wrote: > Am 19.03.19 um 22:58 schrieb Howard Chu: > > There's a proposal to change the C++ spec to declare that all integers are two's complement. > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html > > > > Is there a corresponding proposed change for the C spec? It would certainly simplify life and could eliminate a number of undefined behaviors from the spec. > > Yes. See N2218, discussion to be found in 6.20 of the Brno meeting minutes. > > Philipp Thanks for the reference, will check it out!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-20 13:15 -0700 |
| Message-ID | <lnlg19i9pz.fsf@kst-u.example.com> |
| In reply to | #142096 |
Philipp Klaus Krause <pkk@spth.de> writes:
> Am 19.03.19 um 22:58 schrieb Howard Chu:
>> There's a proposal to change the C++ spec to declare that all
>> integers are two's complement.
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html
>>
>> Is there a corresponding proposed change for the C spec? It would
>> certainly simplify life and could eliminate a number of undefined
>> behaviors from the spec.
>
> Yes. See N2218, discussion to be found in 6.20 of the Brno meeting minutes.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm
This proposal basically makes ones'-complement and sign-and-magnitude
representations non-conforming. It does not change the behavior
of integer overflow, so INT_MAX+1, for example, still has undefined
behavior.
Remember that the *representation* of integers (as two's-complement,
for example) is independent of the behavior on arithmetic overflow.
Using a two's-complement representation doesn't imply wraparound
behavior.
It *could* be proposed to require the common wraparound behavior for
two's-complement signed integers, but I'm not aware of any such
proposal. I'm not entirely sure I'd favor such a proposal. For one
thing, it would make it impossible for a conforming implementation to
trap signed integer overflow.
I might like a change that lets you specify, for a given signed
integer type, how it behaves on overflow. That would probably
have to be part of a larger proposal for specifying attributes of
integer types. It would also have to define the behavior of mixed
operations on wrapping and non-wrapping signed types.
One possible way to define this:
* `_Wrapped int` is a signed integer type with wraparound semantics.
* `_Checked int` is a signed integer type that traps on overflow
("traps" to be defined).
* `_Wrapped unsigned int` is allowed but redundant.
* `_Checked unsigned int` is an unsigned integer type that traps on
overflow.
Signed and unsigned integers keep their current behavior in the absence
of _Wrapped or _Checked.
The N2218 seems to me to be incomplete. It looks like it's largely
copyied (parts of) from the C++ proposal, not (yet?) adapted for C.
Both proposals have the same author, JF Bastien of Apple.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 15:38 +0100 |
| Message-ID | <q707ll$dba$1@dont-email.me> |
| In reply to | #142123 |
On 20/03/2019 21:15, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 19.03.19 um 22:58 schrieb Howard Chu:
>>> There's a proposal to change the C++ spec to declare that all
>>> integers are two's complement.
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html
>>>
>>> Is there a corresponding proposed change for the C spec? It would
>>> certainly simplify life and could eliminate a number of undefined
>>> behaviors from the spec.
>>
>> Yes. See N2218, discussion to be found in 6.20 of the Brno meeting minutes.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm
>
> This proposal basically makes ones'-complement and sign-and-magnitude
> representations non-conforming. It does not change the behavior
> of integer overflow, so INT_MAX+1, for example, still has undefined
> behavior.
>
> Remember that the *representation* of integers (as two's-complement,
> for example) is independent of the behavior on arithmetic overflow.
> Using a two's-complement representation doesn't imply wraparound
> behavior.
>
> It *could* be proposed to require the common wraparound behavior for
> two's-complement signed integers, but I'm not aware of any such
> proposal. I'm not entirely sure I'd favor such a proposal. For one
> thing, it would make it impossible for a conforming implementation to
> trap signed integer overflow.
>
> I might like a change that lets you specify, for a given signed
> integer type, how it behaves on overflow. That would probably
> have to be part of a larger proposal for specifying attributes of
> integer types. It would also have to define the behavior of mixed
> operations on wrapping and non-wrapping signed types.
>
> One possible way to define this:
>
> * `_Wrapped int` is a signed integer type with wraparound semantics.
> * `_Checked int` is a signed integer type that traps on overflow
> ("traps" to be defined).
> * `_Wrapped unsigned int` is allowed but redundant.
> * `_Checked unsigned int` is an unsigned integer type that traps on
> overflow.
>
> Signed and unsigned integers keep their current behavior in the absence
> of _Wrapped or _Checked.
>
> The N2218 seems to me to be incomplete. It looks like it's largely
> copyied (parts of) from the C++ proposal, not (yet?) adapted for C.
> Both proposals have the same author, JF Bastien of Apple.
>
One challenge with this approach is it is convenient to think in terms
of types, and certainly convenient to /use/ in terms of types. But
really, the semantics should be applied to the operations, not the
types. You want to specify "wrapped integer addition", not "addition of
wrapped integer types". This is particularly apparent when mixing types
- what should happen if you add a _Wrapped int to a _Checked int ?
Thinking in terms of operations, rather than types, makes it easier to
specify, and easier to think about correctly - but a lot harder to find
a nice, clean syntax :-(
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-21 09:17 -0700 |
| Message-ID | <711b315c-832b-4677-a0c6-82b1fe65803a@googlegroups.com> |
| In reply to | #142176 |
On Thursday, March 21, 2019 at 2:38:53 PM UTC, David Brown wrote:
> On 20/03/2019 21:15, Keith Thompson wrote:
> > Philipp Klaus Krause <pkk@spth.de> writes:
> >> Am 19.03.19 um 22:58 schrieb Howard Chu:
> >>> There's a proposal to change the C++ spec to declare that all
> >>> integers are two's complement.
> >>>
> >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html
> >>>
> >>> Is there a corresponding proposed change for the C spec? It would
> >>> certainly simplify life and could eliminate a number of undefined
> >>> behaviors from the spec.
> >>
> >> Yes. See N2218, discussion to be found in 6.20 of the Brno meeting minutes.
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm
> >
> > This proposal basically makes ones'-complement and sign-and-magnitude
> > representations non-conforming. It does not change the behavior
> > of integer overflow, so INT_MAX+1, for example, still has undefined
> > behavior.
> >
> > Remember that the *representation* of integers (as two's-complement,
> > for example) is independent of the behavior on arithmetic overflow.
> > Using a two's-complement representation doesn't imply wraparound
> > behavior.
> >
> > It *could* be proposed to require the common wraparound behavior for
> > two's-complement signed integers, but I'm not aware of any such
> > proposal. I'm not entirely sure I'd favor such a proposal. For one
> > thing, it would make it impossible for a conforming implementation to
> > trap signed integer overflow.
> >
> > I might like a change that lets you specify, for a given signed
> > integer type, how it behaves on overflow. That would probably
> > have to be part of a larger proposal for specifying attributes of
> > integer types. It would also have to define the behavior of mixed
> > operations on wrapping and non-wrapping signed types.
> >
> > One possible way to define this:
> >
> > * `_Wrapped int` is a signed integer type with wraparound semantics.
> > * `_Checked int` is a signed integer type that traps on overflow
> > ("traps" to be defined).
> > * `_Wrapped unsigned int` is allowed but redundant.
> > * `_Checked unsigned int` is an unsigned integer type that traps on
> > overflow.
> >
> > Signed and unsigned integers keep their current behavior in the absence
> > of _Wrapped or _Checked.
> >
> > The N2218 seems to me to be incomplete. It looks like it's largely
> > copyied (parts of) from the C++ proposal, not (yet?) adapted for C.
> > Both proposals have the same author, JF Bastien of Apple.
> >
>
> One challenge with this approach is it is convenient to think in terms
> of types, and certainly convenient to /use/ in terms of types. But
> really, the semantics should be applied to the operations, not the
> types. You want to specify "wrapped integer addition", not "addition of
> wrapped integer types". This is particularly apparent when mixing types
> - what should happen if you add a _Wrapped int to a _Checked int ?
>
> Thinking in terms of operations, rather than types, makes it easier to
> specify, and easier to think about correctly - but a lot harder to find
> a nice, clean syntax :-(
This is already a problem with the current syntax. CPUs don't have *signed integers*, they have *integers*. They have signed or unsigned *operators* for performing arithmetic on them - e.g. x86 MUL for unsigned multiplication, IMUL for signed multiplication. They have a single left-shift instruction because left-shift makes no difference whether you're doing signed or unsigned math. They have two right-shift instructions, one which shifts in 0 bits at the top, and one which shifts in copies of the sign bit at the top. But the sign bit isn't "special", it doesn't live in a separate memory or register space. It is merely the top-most bit of the word. They don't have signed vs unsigned Add or Subtract instructions because there is no difference.
For a language that evolved from PDP-11 assembly language, it has strayed pretty far from its roots. Words in a computer memory don't have types. They're just bytes; they're just sequences of bits. The only things that have "types" are the instructions that operate on them.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-21 09:58 -0700 |
| Message-ID | <54a40056-d25c-4471-80bf-768ed27ab818@googlegroups.com> |
| In reply to | #142183 |
On Thursday, March 21, 2019 at 12:17:26 PM UTC-4, Howard Chu wrote: ... > ... They don't have signed vs unsigned Add or Subtract instructions because there is no difference. That depends upon the CPU. The committee didn't add wording allowing for 1's complement and sign-magnitude representations just for the fun of it - they added that wording because, at the time C99 was written, there were known machines for which a C compiler would be desirable, which had hardware level support for those representations. Unlike 2's complement, a CPU with hardware support for one of the other two representations must have separate Add and Subtract instructions for signed and unsigned operations (or in some cases that I've heard of, no support for unsigned operations - they had to be emulated in software). Such systems were rare, and getting rarer, and some have claimed that they're now completely extinct (though I find that implausible), but they did exist at one time.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-03-21 17:22 +0000 |
| Message-ID | <9LPkE.179114$KB3.134422@fx02.iad> |
| In reply to | #142186 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: >On Thursday, March 21, 2019 at 12:17:26 PM UTC-4, Howard Chu wrote: >... >> ... They don't have signed vs unsigned Add or Subtract instructions because there is no difference. > >That depends upon the CPU. The committee didn't add wording allowing for >1's complement and sign-magnitude representations just for the fun of it >- they added that wording because, at the time C99 was written, there >were known machines for which a C compiler would be desirable, which had >hardware level support for those representations. Unlike 2's complement, >a CPU with hardware support for one of the other two representations >must have separate Add and Subtract instructions for signed and unsigned >operations (or in some cases that I've heard of, no support for unsigned >operations - they had to be emulated in software). > >Such systems were rare, and getting rarer, and some have claimed that >they're now completely extinct (though I find that implausible), but >they did exist at one time. Not completely extinct (Clearpath Dorado (Univac) and Clearpath Libra (Burroughs) are still in production, albeit emulated).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-03-21 23:44 -0500 |
| Message-ID | <4sp89eh3cap02d7kd9g4vvdjntq5eb6o3d@4ax.com> |
| In reply to | #142186 |
On Thu, 21 Mar 2019 09:58:20 -0700 (PDT), James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On Thursday, March 21, 2019 at 12:17:26 PM UTC-4, Howard Chu wrote: >... >> ... They don't have signed vs unsigned Add or Subtract instructions because there is no difference. > >That depends upon the CPU. The committee didn't add wording allowing for >1's complement and sign-magnitude representations just for the fun of it >- they added that wording because, at the time C99 was written, there >were known machines for which a C compiler would be desirable, which had >hardware level support for those representations. Unlike 2's complement, >a CPU with hardware support for one of the other two representations >must have separate Add and Subtract instructions for signed and unsigned >operations (or in some cases that I've heard of, no support for unsigned >operations - they had to be emulated in software). > >Such systems were rare, and getting rarer, and some have claimed that >they're now completely extinct (though I find that implausible), but >they did exist at one time. Separate signed and unsigned add and subtract instructions exist on some two's complement machines. S/360 and its descendents, for example. While the result value is the same, different condition codes are set.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-21 12:43 -0700 |
| Message-ID | <lnftrgggib.fsf@kst-u.example.com> |
| In reply to | #142183 |
Howard Chu <highlandsun@gmail.com> writes:
[...]
> This is already a problem with the current syntax. CPUs don't have
> *signed integers*, they have *integers*. They have signed or unsigned
> *operators* for performing arithmetic on them - e.g. x86 MUL for
> unsigned multiplication, IMUL for signed multiplication. They have a
> single left-shift instruction because left-shift makes no difference
> whether you're doing signed or unsigned math. They have two
> right-shift instructions, one which shifts in 0 bits at the top, and
> one which shifts in copies of the sign bit at the top. But the sign
> bit isn't "special", it doesn't live in a separate memory or register
> space. It is merely the top-most bit of the word. They don't have
> signed vs unsigned Add or Subtract instructions because there is no
> difference.
None of this is a "problem". C is not a high-level assembly language.
And not all CPUs have the characteristics you describe.
> For a language that evolved from PDP-11 assembly language, it has
> strayed pretty far from its roots. Words in a computer memory don't
> have types. They're just bytes; they're just sequences of bits. The
> only things that have "types" are the instructions that operate on
> them.
C did not evolve from PDP-11 assembly language. It evolved from B,
which evolved from BCPL, which evolved from CPL, which was implemented
before the PDP-11 existed.
--
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]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web