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 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-26 13:43 -0700 |
| Message-ID | <ln1s2tbc3x.fsf@kst-u.example.com> |
| In reply to | #142487 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>>The obvious solution (for UNIX-like systems, at least) is to make
>>time_t a signed 64-bit integer, even on 32-bit systems.
>
> It may seem obvious, but it likely would have performance implications
> given the frequency (pun intended) of time_t usage in the kernel.
> Better to just go with 64-bit UNIX{-like} systems now, which most
> people have already done.
I suggest it's worth gathering more information.
My Android phone, for example, is a 32-bit system with as Linux
kernel, and I've recently worked on embedded 32-bit Linux-based
systems. Maybe abandoning all such systems for 64-bit before 2038
will make sense, but not *just* for the sake of time_t.
If the kernel uses time_t a lot internally, I wonder if it would make
sense to add, say, a kernel-only time32_t type (with an epoch of,
say, 2020-01-101) and converting between that and the 64-bit time_t
as needed, by adding or subtracting 1577836800. (Admittedly, that
could be a lot of work.) This assumes that the kernel never needs to
deal with times before 1951-12-13, 2**31 seconds before 2020-01-01.
The question is whether 32-bit systems will still make sense in
2038 -- and I doubt that anyone knows the answer to that.
--
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-26 22:49 +0000 |
| Message-ID | <q7ea9n$ako$2@z-news.wcss.wroc.pl> |
| In reply to | #142487 |
Scott Lurndal <scott@slp53.sl.home> wrote:
> Keith Thompson <kst-u@mib.org> writes:
> >Robert Wessel <robertwessel2@yahoo.com> writes:
> >[...]
> >> The 32-bit Unix time base is January 1, 1970, and it will roll to a
> >> negative number in 2038, to roughly December 13, 1901 (if something
> >> actually successfully processes that as a negative number of seconds
> >> from the base time).
> >
> >On most 32-bit Unix-like systems that are still running in 2038,
> >the clock will roll back to December 13, 1901 (in the absence of
> >any fixes). But neither C nor POSIX mandates this behavior.
> >
> >C says only that time_t is a real (integer or floating-point) type
> >capable of representing times. It says nothing about the meaning of
> >(time_t)0, the epoch, resolution, or even that it's monotonic.
> >
> >POSIX requires time_t to be an integer type and says that time()
> >returns "the value of time in seconds since the Epoch", which it
> >defines as January 1, 1970. It says that time() *may* fail, and
> >set errno to EOVERFLOW, if the time will not fit in an object of
> >type time_t.
> >
> > Implementations in which time_t is a 32-bit signed integer (many
> > historical implementations) fail in the year 2038. POSIX.1-2017
> > does not address this problem.
> >
> >The obvious solution (for UNIX-like systems, at least) is to make
> >time_t a signed 64-bit integer, even on 32-bit systems.
>
> It may seem obvious, but it likely would have performance implications
> given the frequency (pun intended) of time_t usage in the kernel. Better
> to just go with 64-bit UNIX{-like} systems now, which most people have already
> done.
I think that main issue is binary compatibility: bigger time_t
almost surely would break many existing binaries. And as long
as time_t has 32-bits new binares appear...
For kernel time_t is interface type, internaly it can use whatever
is efficient. Again, main issue probably is due to filesystem
data, IIRC on-disk structures store time_t.
In a sense most obvious solution is switch to "rolling time":
declare that time_t only covers a window around "now". In
particular in 2038 that would mean switch to unsigned representation.
and in 2106 switch back to signed and to new epoch.
Of course, such time_t would be only for programs needing
limited timespans. Other should switch to proper 64-bit
time.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-27 21:02 +0000 |
| Message-ID | <slrnq9np77.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #142503 |
On Tue, 2019-03-26, antispam@math.uni.wroc.pl wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
[time_t wraparound]
...
>> It may seem obvious, but it likely would have performance implications
>> given the frequency (pun intended) of time_t usage in the kernel. Better
>> to just go with 64-bit UNIX{-like} systems now, which most people have already
>> done.
>
> I think that main issue is binary compatibility: bigger time_t
> almost surely would break many existing binaries.
That already happened -- the programs broke and were fixed, around fifteen
years ago I think.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-28 18:04 +0000 |
| Message-ID | <q7j2b2$d5c$1@z-news.wcss.wroc.pl> |
| In reply to | #142527 |
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Tue, 2019-03-26, antispam@math.uni.wroc.pl wrote:
> > Scott Lurndal <scott@slp53.sl.home> wrote:
>
> [time_t wraparound]
>
> ...
> >> It may seem obvious, but it likely would have performance implications
> >> given the frequency (pun intended) of time_t usage in the kernel. Better
> >> to just go with 64-bit UNIX{-like} systems now, which most people have already
> >> done.
> >
> > I think that main issue is binary compatibility: bigger time_t
> > almost surely would break many existing binaries.
>
> That already happened -- the programs broke and were fixed, around fifteen
> years ago I think.
You mean in 2004? What happened?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-28 19:53 +0000 |
| Message-ID | <slrnq9q9h4.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #142555 |
On Thu, 2019-03-28, antispam@math.uni.wroc.pl wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> On Tue, 2019-03-26, antispam@math.uni.wroc.pl wrote:
>> > Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>> [time_t wraparound]
>>
>> ...
>> >> It may seem obvious, but it likely would have performance implications
>> >> given the frequency (pun intended) of time_t usage in the kernel. Better
>> >> to just go with 64-bit UNIX{-like} systems now, which most people have already
>> >> done.
>> >
>> > I think that main issue is binary compatibility: bigger time_t
>> > almost surely would break many existing binaries.
>>
>> That already happened -- the programs broke and were fixed, around fifteen
>> years ago I think.
>
> You mean in 2004? What happened?
You mean what were the symptoms? Probably none for the most part,
unless someone set the system clock to 2040 and tried various pieces of
software.
I wasn't part of that. People running Solaris on newer Sun hardware
(or similar) were the ones who had to fix software to work with 64-bit
time_t.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-26 18:25 +0000 |
| Message-ID | <Y8umE.230800$DX5.72608@fx16.am4> |
| In reply to | #142475 |
On 26/03/2019 15:49, David Brown wrote: > On 26/03/2019 12:58, Bart wrote: >> Remember the 2038 problem (well that >> might still be in the future), which was signed 32-bit? Remember when >> the viewing numbers for a certain youtube video overflowed the capacity >> of the 32-bit signed int they were using? No nasal demons, just the >> wrong results. > > Yes, I know the 2038 problem. Exactly /how/ is it good that some > systems will move from the year 2038 to the year 1901 (if I have my > numbers right) ? Making the overflow undefined behaviour does not in > any way fix the problem You admit that at least. But, isn't UB designed to allow any behaviour AT ALL? Mostly instigated by the compiler. That certainly cannot help. With predictable behaviour however, it is possible to mitigate some of the consequences. If you get date data from anywhere via non-updated software that happens to specify a year before 1970 when that shouldn't possible, then you can might be able to infer that the date-time value has wrapped, and adjust it accordingly. You can't do that if a compiler does God knows what because it makes the assumption that such a thing cannot occur.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-26 14:47 +0000 |
| Message-ID | <q7de2b$gac$1@z-news.wcss.wroc.pl> |
| In reply to | #142367 |
Bart <bc@freeuk.com> wrote:
> On 24/03/2019 17:43, antispam@math.uni.wroc.pl wrote:
> > You still did not explain why you want such a thing. I use low
>
> I've used low level code, starting early 80s, for:
>
> - Test programs when developing microprocessor boards: doing i/o,
> writing to controllers, testing memory, etc etc
> - Firmware (boot code/monitor code) for microcomputers
> - Text and graphics display drivers
> - Basic graphics libraries
> - Frame grabbing
> - Basic image processing
> - 3D graphics
> - Software floating point
> - Maths libraries
> - Text editors
> - Assemblers
> - Compilers (a few of these)
> - Linkers
> - Interpreters
> - Printer and plotter drivers
> - Interfacing to mice, and [digitising] tablets
> - Whole applications (mainly low-end 2D and 3D CAD)
> - GUI libraries
> - Arbitrary precision arithmetic
> - File format conversion (read/write image files, dxf, eps, 3ds etc)
> - Later interfacing to OSes like you, and to 3rd party APIs
> - etc
AFAICS it you used low-level language in several cases where
is was not strictly necessary. You may have good reason to
do what you did, but most task you mention can be done at
higher level.
Concerning arbitrary precision arithmetic I just needed
routines for Raspberry Pi. Existing system used (rather
crappy) assembler routines on i386. On Pi I tried C
and while code is still in developemnt and only lightly
tested it seem that C gives me better speed that old
assembler. OK, two example routines:
/* Compute dst + xp*m and assign to dst */
void
do_bgi_mult_add(unsigned int * dst, int len, unsigned int * xp,
unsigned int m) {
unsigned int c = 0;
int i = 0;
while(i < len) {
unsigned long long pp = (unsigned long long)(xp[i])*
(unsigned long long)m +
(unsigned long long)(dst[i]) +
(unsigned long long)c;
dst[i] = pp;
c = (pp >> (32ULL));
i++;
}
dst[i] += c;
}
/* Compute xp + yp and assign to dst */
void
do_bgi_sub(unsigned int * dst, int xlen, unsigned int * xp,
int ylen, unsigned int * yp) {
unsigned int c = 0;
int mlen = (xlen < ylen)?xlen:ylen;
int i = 0;
unsigned int xext = (unsigned int)(((int)(xp[xlen - 1])) >> 31);
unsigned int yext = (unsigned int)(((int)(yp[ylen - 1])) >> 31);
while(i < mlen) {
unsigned long long pp = (unsigned long long)(xp[i])
- (unsigned long long)(yp[i])
- (unsigned long long)c;
dst[i] = pp;
c = -(pp >> (32ULL));
i++;
}
while(i < xlen) {
unsigned long long pp = (unsigned long long)(xp[i])
- (unsigned long long)yext
- (unsigned long long)c;
dst[i] = pp;
c = -(pp >> (32ULL));
i++;
}
while(i < ylen) {
unsigned long long pp = (unsigned long long)xext
- (unsigned long long)(yp[i])
- (unsigned long long)c;
dst[i] = pp;
c = -(pp >> (32ULL));
i++;
}
{
unsigned long long pp = (unsigned long long)xext
- (unsigned long long)yext
- (unsigned long long)c;
dst[i] = pp;
}
}
Main loop in do_bgi_mult translatates to:
.L12:
ldr r1, [r2, ip]
mov r5, #0
umlal r4, r5, r3, r1
str r4, [r0, ip]
add ip, ip, #4
cmp ip, r6
mov r4, r5
bne .L12
Note the umlal istruction: compiler automatically realized that
it can use multiply and add instruction to get 32x32 bit
multiplication and 64-bit addition in single instruction.
Other instrictions are needed to correctly propagate carry.
At first glance I see nothing to improve in this code.
And the code I wrote is not particularly low-level. There are
casts to force use of 64-bit unsigned artimetic for intermediate
expressions, but that is all. Higher level language would
automatically use high precision for intermediates, but
then I probably would have to explicitely force truncation.
This code was written for Raspberry Pi, but should work on
ordinary machines using 32-bit words and 32-bit (unsigned)
it. Assuming resonably sized numbers it should work on
64-bit machines (using int for length limits size of numbers,
but way before that you would want switch to better algorithm).
Of course working in 32-bit pieces is suboptimal on 64-bit
machine so one would need to tweak types to get better
efficiency. In particular one needs 128-bit type for
intermediates (available in gcc, but nonstandard).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-26 18:14 +0000 |
| Message-ID | <t_tmE.201421$MT2.41163@fx21.am4> |
| In reply to | #142470 |
On 26/03/2019 14:47, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 24/03/2019 17:43, antispam@math.uni.wroc.pl wrote:
>>> You still did not explain why you want such a thing. I use low
>>
>> I've used low level code, starting early 80s, for:
>>
....
> AFAICS it you used low-level language in several cases where
> is was not strictly necessary. You may have good reason to
> do what you did, but most task you mention can be done at
> higher level.
The list is not precise. Some programs may have had parts that used
scripting code (esp the apps). Some may later have been written entirely
in scripting (ie dynamic/interpreted) code, although I'm now moving back
to static code.
But I'm also now creating one new language that is low level enough to
do the tasks in that last, and also has higher level features.
Still, none of those languages have a need for UB to be applied to
ordinary register overflows.
> Concerning arbitrary precision arithmetic I just needed
> routines for Raspberry Pi. Existing system used (rather
> crappy) assembler routines on i386. On Pi I tried C
> and while code is still in developemnt and only lightly
> tested it seem that C gives me better speed that old
> assembler. OK, two example routines:
>
> /* Compute dst + xp*m and assign to dst */
> void
> do_bgi_mult_add(unsigned int * dst, int len, unsigned int * xp,
> unsigned int m) {
> unsigned int c = 0;
> int i = 0;
> while(i < len) {
> unsigned long long pp = (unsigned long long)(xp[i])*
> (unsigned long long)m +
> (unsigned long long)(dst[i]) +
> (unsigned long long)c;
> dst[i] = pp;
> c = (pp >> (32ULL));
> i++;
> }
> dst[i] += c;
> }
> Main loop in do_bgi_mult translatates to:
>
> .L12:
> ldr r1, [r2, ip]
> mov r5, #0
> umlal r4, r5, r3, r1
> str r4, [r0, ip]
> add ip, ip, #4
> cmp ip, r6
> mov r4, r5
> bne .L12
I tried your code on x64 (not converted from 32-bit), using a quick
program shown below. Results roughly as follows:
gcc-O3 0.95 seconds (clang, msvc similar)
lccwin 2.5
pellesc 2.5
dmc 5.0
(mc 7.4 my non-C language+compiler)
bcc 8.2 my C compiler
tcc 8.4
So gcc is doing pretty well, or so it looked. Then I put the main() and
do_bgi_mult_add() functions in different modules.
Now gcc takes 2.2 seconds. It must have been inlining the function or
somehow taking unfair advantage of the fact that this was a simple test.
Still good, but not as great as it seemed.
Then, I knocked up a version in x64 assembly (however still using 32-bit
data like yours). That version also took 2.2 seconds (within the non-C
program that otherwise took 7.4 seconds).
So I easily matched gcc-O3 without needing to use any optimising tools
at all. Just by making it very simple to incorporate ASM.
You wouldn't write large swathes of your programs in ASM, but it's fine
as inline code for selected functions.
----------------------
int main(void){
unsigned int a[]={10,20,30,40,50,60,70,80,90,100, 0};
unsigned int b[]={ 2, 4, 6, 8,10,12,14,16,18, 20, 0};
for(int i=0; i<11; ++i) {
printf("%3d ",a[i]);
}
puts("");
for(int i=0; i<100000000; ++i)
do_bgi_mult_add(a,10,b,3);
for(int i=0; i<11; ++i) {
printf("%3u ",a[i]);
}
}
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-26 22:31 +0000 |
| Message-ID | <q7e97e$ako$1@z-news.wcss.wroc.pl> |
| In reply to | #142483 |
Bart <bc@freeuk.com> wrote:
> On 26/03/2019 14:47, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
>
> The list is not precise. Some programs may have had parts that used
> scripting code (esp the apps). Some may later have been written entirely
> in scripting (ie dynamic/interpreted) code, although I'm now moving back
> to static code.
>
> But I'm also now creating one new language that is low level enough to
> do the tasks in that last, and also has higher level features.
>
> Still, none of those languages have a need for UB to be applied to
> ordinary register overflows.
Well, we have different background here. I was learning programming
from books by Wirth, Dijksta and Alagic and Arbib. For me
reasonig in terms of precoditions and postconditions is natural.
If preconditons are statisfied, than I know that postconditions
hold. If preconditons are violated, then I do not know.
C standard says that if certain preconditons hold, then
I will get speciefied result, that is postconditions hold.
It does not matter what exactly happens if preconditons are
not satisfied. It if for people writing specifications
to ensure that specification contains correct initial
preconditons. And it programmer job to make sure that
starting from specified preconditons all intermediate
states will satisfy preconditons of following operations.
As I wrote, what happens when preconditons are not satified
is irrelevant, so I do not need definition what happens
in such case. Now, to know that correct conditions hold
in arithmetic may take some math. Since overflow means
normal math rules are no longer valid, preconditions
in particular mandate that results stay in range.
It does not matter what language says if overflow
happens: my mental tools are broken in such case
and I can not vouch for result. That is UB.
Of course, sometimes problem involves bit-twidling or
modular aritmetic. Languages that I use allow me
to handle this. But this is different than normal
aritmetic. C is here somewhat blurs difference
with notion of unsigned type, but what I would
change here probably goes in opposite direction
to what you want...
> > Concerning arbitrary precision arithmetic I just needed
> > routines for Raspberry Pi. Existing system used (rather
> > crappy) assembler routines on i386. On Pi I tried C
> > and while code is still in developemnt and only lightly
> > tested it seem that C gives me better speed that old
> > assembler. OK, two example routines:
> >
> > /* Compute dst + xp*m and assign to dst */
> > void
> > do_bgi_mult_add(unsigned int * dst, int len, unsigned int * xp,
> > unsigned int m) {
> > unsigned int c = 0;
> > int i = 0;
> > while(i < len) {
> > unsigned long long pp = (unsigned long long)(xp[i])*
> > (unsigned long long)m +
> > (unsigned long long)(dst[i]) +
> > (unsigned long long)c;
> > dst[i] = pp;
> > c = (pp >> (32ULL));
> > i++;
> > }
> > dst[i] += c;
> > }
>
> > Main loop in do_bgi_mult translatates to:
> >
> > .L12:
> > ldr r1, [r2, ip]
> > mov r5, #0
> > umlal r4, r5, r3, r1
> > str r4, [r0, ip]
> > add ip, ip, #4
> > cmp ip, r6
> > mov r4, r5
> > bne .L12
>
> I tried your code on x64 (not converted from 32-bit), using a quick
> program shown below. Results roughly as follows:
>
> gcc-O3 0.95 seconds (clang, msvc similar)
> lccwin 2.5
> pellesc 2.5
> dmc 5.0
> (mc 7.4 my non-C language+compiler)
> bcc 8.2 my C compiler
> tcc 8.4
>
> So gcc is doing pretty well, or so it looked. Then I put the main() and
> do_bgi_mult_add() functions in different modules.
>
> Now gcc takes 2.2 seconds. It must have been inlining the function or
> somehow taking unfair advantage of the fact that this was a simple test.
> Still good, but not as great as it seemed.
>
> Then, I knocked up a version in x64 assembly (however still using 32-bit
> data like yours). That version also took 2.2 seconds (within the non-C
> program that otherwise took 7.4 seconds).
>
> So I easily matched gcc-O3 without needing to use any optimising tools
> at all. Just by making it very simple to incorporate ASM.
You completely missed the point. First, challenge in multiprecision
aritmetic is to efficiently handle carries. Using 64-bit
machine to work on 32-bit chunks makes it easy, but is
inefficient beacause of small work unit. On 64-bit machine
I have:
#define WTYPE unsigned long long
#define DTYPE unsigned __int128
void
do_bgi_mult_add(WTYPE * dst, int len, WTYPE * xp,
WTYPE m) {
WTYPE c = 0;
int i = 0;
while(i < len) {
DTYPE pp = (DTYPE)(xp[i])* (DTYPE)m + (DTYPE)(dst[i]) +
(DTYPE)c;
dst[i] = pp;
c = (pp >> (64U));
i++;
}
dst[i] += c;
}
Resulting assembly does not look too bad:
.L5:
movq %rax, %rsi
.L3:
movq (%rdi,%rsi,8), %r9
movq %rbx, %rax
mulq (%r8,%rsi,8)
xorl %r10d, %r10d
movq %r13, %r11
xorl %r12d, %r12d
movq %r10, %r14
movq %r9, %r13
addq %r11, %r13
adcq %r12, %r14
addq %rax, %r13
leaq 1(%rsi), %rax
adcq %rdx, %r14
movq %r13, (%rdi,%rsi,8)
movq %r14, %r13
cmpq %rsi, %rbp
jne .L5
but I think that several register moves are useless. Second
point is not that C code runs faster than assembler. The
64-bit version above definitly could be improved, so this
would be false. Rather, I have 12 routines which together
take about 270 lines. There are other parts (about 1400
lines) written in another language that implement outer
loops and wrap everthing for convenient use. The point
is that those 270 lines of C for me were _much_ easier to
write than assembler. First, I made a few silly mistakes
that were immediately found by warnings from gcc. I
made a few logic error, caught by tests. They were
easier to fix in C. And I avoided a few errors that
I would probably make due to need to specify details
that C version delegated to compiler.
You wrote that you can easily write such function in
ASM. Sure, I would do them in ASM if really needed.
But do_bgi_mult_add is simple one (subtraction is
more tricky). Writing it took me probably around
2 min (you may add to it something like 5 min spent
drinking refreshments). There was one error, I intially
assumed that highest word in dst will be always 0,
so I just stored c there. But later I realized that
I need it also in cases when highest word is nonzero.
>
> ----------------------
> int main(void){
> unsigned int a[]={10,20,30,40,50,60,70,80,90,100, 0};
> unsigned int b[]={ 2, 4, 6, 8,10,12,14,16,18, 20, 0};
>
> for(int i=0; i<11; ++i) {
> printf("%3d ",a[i]);
> }
> puts("");
>
> for(int i=0; i<100000000; ++i)
> do_bgi_mult_add(a,10,b,3);
>
> for(int i=0; i<11; ++i) {
> printf("%3u ",a[i]);
> }
>
> }
Given constant data I expect compiler to produce specialized
version of program taking advantage of this. AFAICS in
this case when definition of do_bgi_mult_add was visible gcc
produced specialized version of do_bgi_mult_add which preformed
10 steps in sequence, without need for loop control.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-27 00:08 +0000 |
| Message-ID | <xazmE.250162$kh.65747@fx27.am4> |
| In reply to | #142502 |
On 26/03/2019 22:31, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> Still, none of those languages have a need for UB to be applied to
>> ordinary register overflows.
>
> Well, we have different background here. I was learning programming
> from books by Wirth, Dijksta and Alagic and Arbib. For me
> reasonig in terms of precoditions and postconditions is natural.
> If preconditons are statisfied, than I know that postconditions
> hold. If preconditons are violated, then I do not know.
> C standard says that if certain preconditons hold, then
> I will get speciefied result, that is postconditions hold.
> It does not matter what exactly happens if preconditons are
> not satisfied. It if for people writing specifications
> to ensure that specification contains correct initial
> preconditons. And it programmer job to make sure that
> starting from specified preconditons all intermediate
> states will satisfy preconditons of following operations.
>
> As I wrote, what happens when preconditons are not satified
> is irrelevant, so I do not need definition what happens
> in such case. Now, to know that correct conditions hold
> in arithmetic may take some math. Since overflow means
> normal math rules are no longer valid, preconditions
> in particular mandate that results stay in range.
> It does not matter what language says if overflow
> happens: my mental tools are broken in such case
> and I can not vouch for result. That is UB.
>
> Of course, sometimes problem involves bit-twidling or
> modular aritmetic. Languages that I use allow me
> to handle this. But this is different than normal
> aritmetic. C is here somewhat blurs difference
> with notion of unsigned type, but what I would
> change here probably goes in opposite direction
> to what you want...
My background is much more practical and stems from working with
machines that were barely capable of doing arithmetic at all.
Then you become extremely familiar with the inner workings. You have so
many bits to play with, sometimes they are enough and sometimes not. Or
it doesn't matter: look at George Marsaglia's random number programs
like KISS, which use unsigned numbers and rely on bits disappearing from
the top end as you /want/ to end up with a 32 or 64 bit value; overflow
is intentional.
On the rare occasions I need to do actual arithmetic on arbitrary
numbers, I would use my other language where you can get around the
limitations.
a:=int64.maxvalue # 9223372036854775807
println a+1
println longint(a)+1
Output:
-9223372036854775808
9223372036854775808
After all, you wouldn't use int32 or even int64 to implement any sort of
calculator (ignoring that they only represent whole numbers); the range
is too limited and too easy to overflow:
a:=123456
println a**7 # nice small numbers, what could go wrong?
Output:
-3701989680024125440 # oops, it shouldn't be negative!
Instead use:
a:=123456L
println a**7
Output:
437104634676747795452235896466702336 # looks more plausible
It sounds absurd to be demanding mathematical accuracy and range of such
a language as C. Its small fixed width integers are used for a
combination of low-value arithmetic and bitwise and logical operations.
>> So I easily matched gcc-O3 without needing to use any optimising tools
>> at all. Just by making it very simple to incorporate ASM.
>
> You completely missed the point.
TBH I couldn't see the connection between such code (were you suggesting
a higher or lower level language? I don't know) and the subject of UB
(in my subthread, specifically about overflow).
> #define WTYPE unsigned long long
> #define DTYPE unsigned __int128
>
> void
> do_bgi_mult_add(WTYPE * dst, int len, WTYPE * xp,
> WTYPE m) {
> WTYPE c = 0;
> int i = 0;
> while(i < len) {
> DTYPE pp = (DTYPE)(xp[i])* (DTYPE)m + (DTYPE)(dst[i]) +
> (DTYPE)c;
> dst[i] = pp;
> c = (pp >> (64U));
> i++;
> }
> dst[i] += c;
> }
(I would find the blatant use of a 128-bit type worrying here. Your
compiler seems to have recognised that a 64*64=>128 multiply, natively
available on some 64-bit hardware, is all that is needed. Others (eg
mine) would attempt a 128*128 multiply, with poor results.)
> You wrote that you can easily write such function in
> ASM.
No, I would write high level code, but might have an ASM version for an
alternate accelerated version. Not instead of the HLL version. Depending
on the target, the HLL versions should always work; the ASM is much less
portable.
And yes, ASM is much more painful to write and is always full of
hard-to-find bugs.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-28 18:45 +0000 |
| Message-ID | <q7j4oi$l7g$1@z-news.wcss.wroc.pl> |
| In reply to | #142504 |
Bart <bc@freeuk.com> wrote:
> On 26/03/2019 22:31, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
>
> >> Still, none of those languages have a need for UB to be applied to
> >> ordinary register overflows.
> >
> > Well, we have different background here. I was learning programming
> > from books by Wirth, Dijksta and Alagic and Arbib. For me
> > reasonig in terms of precoditions and postconditions is natural.
> > If preconditons are statisfied, than I know that postconditions
> > hold. If preconditons are violated, then I do not know.
> > C standard says that if certain preconditons hold, then
> > I will get speciefied result, that is postconditions hold.
> > It does not matter what exactly happens if preconditons are
> > not satisfied. It if for people writing specifications
> > to ensure that specification contains correct initial
> > preconditons. And it programmer job to make sure that
> > starting from specified preconditons all intermediate
> > states will satisfy preconditons of following operations.
> >
> > As I wrote, what happens when preconditons are not satified
> > is irrelevant, so I do not need definition what happens
> > in such case. Now, to know that correct conditions hold
> > in arithmetic may take some math. Since overflow means
> > normal math rules are no longer valid, preconditions
> > in particular mandate that results stay in range.
> > It does not matter what language says if overflow
> > happens: my mental tools are broken in such case
> > and I can not vouch for result. That is UB.
> >
> > Of course, sometimes problem involves bit-twidling or
> > modular aritmetic. Languages that I use allow me
> > to handle this. But this is different than normal
> > aritmetic. C is here somewhat blurs difference
> > with notion of unsigned type, but what I would
> > change here probably goes in opposite direction
> > to what you want...
>
> My background is much more practical and stems from working with
> machines that were barely capable of doing arithmetic at all.
>
> Then you become extremely familiar with the inner workings. You have so
> many bits to play with, sometimes they are enough and sometimes not. Or
> it doesn't matter: look at George Marsaglia's random number programs
> like KISS, which use unsigned numbers and rely on bits disappearing from
> the top end as you /want/ to end up with a 32 or 64 bit value; overflow
> is intentional.
>
> On the rare occasions I need to do actual arithmetic on arbitrary
> numbers, I would use my other language where you can get around the
> limitations.
>
> a:=int64.maxvalue # 9223372036854775807
>
> println a+1
> println longint(a)+1
>
> Output:
>
> -9223372036854775808
> 9223372036854775808
>
> After all, you wouldn't use int32 or even int64 to implement any sort of
> calculator (ignoring that they only represent whole numbers); the range
> is too limited and too easy to overflow:
>
> a:=123456
> println a**7 # nice small numbers, what could go wrong?
>
> Output:
>
> -3701989680024125440 # oops, it shouldn't be negative!
>
> Instead use:
>
> a:=123456L
> println a**7
>
> Output:
>
> 437104634676747795452235896466702336 # looks more plausible
>
> It sounds absurd to be demanding mathematical accuracy and range of such
> a language as C. Its small fixed width integers are used for a
> combination of low-value arithmetic and bitwise and logical operations.
Well, I demand mathematical accuracy as long as results stay
in supported range. I understand that implementers may save
effort and limit range, but I prefer implementations which
give me max of 64 bit and twice the native wordlength
(so 128 bits on 64-bit machnes and 64 when wordlength is
32 bits or smaller).
>
> >> So I easily matched gcc-O3 without needing to use any optimising tools
> >> at all. Just by making it very simple to incorporate ASM.
> >
> > You completely missed the point.
>
> TBH I couldn't see the connection between such code (were you suggesting
> a higher or lower level language? I don't know) and the subject of UB
> (in my subthread, specifically about overflow).
This is a low level task of kind you would like to do. Correctenss
of this code depened on fact that overflow is impossible. It does
not matter if behaviour on overflow is defined or not: overflow
would mean that the code is wrong. To make it more explicit,
in 32-bit case the pp wariable can represent numbers up to 2^64 - 1.
When we compute pp = xp[i]*m + dst[i] + c (I ommited casts for
clarity) max value of each ingredient is 2^32 - 1, to max values is
(2^32 - 1)*(2^32 - 1) + (2^32 - 1) + (2^32 - 1) =
(2^32 - 1)*((2^32 - 1) + 2) = (2^32 - 1)*(2^32 + 1)
= 2^64 - 1
so it fits. And C (using gcc) works well for this task.
> > #define WTYPE unsigned long long
> > #define DTYPE unsigned __int128
> >
> > void
> > do_bgi_mult_add(WTYPE * dst, int len, WTYPE * xp,
> > WTYPE m) {
> > WTYPE c = 0;
> > int i = 0;
> > while(i < len) {
> > DTYPE pp = (DTYPE)(xp[i])* (DTYPE)m + (DTYPE)(dst[i]) +
> > (DTYPE)c;
> > dst[i] = pp;
> > c = (pp >> (64U));
> > i++;
> > }
> > dst[i] += c;
> > }
>
> (I would find the blatant use of a 128-bit type worrying here. Your
> compiler seems to have recognised that a 64*64=>128 multiply, natively
> available on some 64-bit hardware, is all that is needed. Others (eg
> mine) would attempt a 128*128 multiply, with poor results.)
That is why I wrote that I want resonable optimizer. I hope that
you understand now that I expect my compiler to do such
optimization. And that is why compiler should support
at least twice native wordlength: otherwise it is impossible
to write such code...
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-21 15:13 -0700 |
| Message-ID | <lny357g9k2.fsf@kst-u.example.com> |
| In reply to | #142206 |
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.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-21 22:29 +0000 |
| Message-ID | <lfUkE.712083$RBa.238098@fx15.am4> |
| In reply to | #142210 |
On 21/03/2019 22:13, 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.)
But it's easy to see how the resulting bit-pattern (the same one
mentioned in K&R2) could be well-defined.
On a machine which I /know/ used 32-bit twos complement, why can't I
count on the pattern 0x00000001 being left-shifted 31 places to produce
0x80000000, and being able to interpret that result as a signed integer?
On the basis of 1<<31 being undefined, then so could all of these,
depending on the values involved (all int32_t), because of overflow:
a+b
a*b
a<<b
Not sure about a-b, a/b or a>>b regarding overflow. Nor about overflow
when using uint32_t:
0x000000FF << 28
As a bit-pattern, I would expect that to yield 0xF0000000, which is not
256*2^28; defined or undefined? And if defined, why?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-21 23:51 +0000 |
| Message-ID | <871s2zwzuc.fsf@bsb.me.uk> |
| In reply to | #142212 |
Bart <bc@freeuk.com> writes:
> On a machine which I /know/ used 32-bit twos complement, why can't I
> count on the pattern 0x00000001 being left-shifted 31 places to
> produce 0x80000000, and being able to interpret that result as a
> signed integer?
You can. C allows you to write exactly that:
(union { unsigned u; signed s; }){ 1u << 31 }.s
This is an expression where a bit-pattern made by shifting is
interpreted as a signed int.
> On the basis of 1<<31 being undefined, then so could all of these,
> depending on the values involved (all int32_t), because of overflow:
>
> a+b
> a*b
> a<<b
>
> Not sure about a-b, a/b or a>>b regarding overflow.
All but the last (a >> b) can overflow, but they can all be undefined.
> Nor about overflow when using uint32_t:
>
> 0x000000FF << 28
0xFF has type int so that is also undefined. 0xFFu << 28 is fine,
though, as is UINT32_C(0xFF) << 28 if you really want to use a uint32_t
constant.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 11:37 +0100 |
| Message-ID | <q72dth$3os$1@dont-email.me> |
| In reply to | #142212 |
On 21/03/2019 23:29, Bart wrote: > On 21/03/2019 22:13, 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.) > > But it's easy to see how the resulting bit-pattern (the same one > mentioned in K&R2) could be well-defined. > > On a machine which I /know/ used 32-bit twos complement, why can't I > count on the pattern 0x00000001 being left-shifted 31 places to produce > 0x80000000, and being able to interpret that result as a signed integer? The representation is irrelevant. If it representation were the reason for the C standards not giving a fully defined value for these shift results, then it would have written "implementation defined", not "undefined". This is the case for right-shift of negative integer values - the result is implementation defined. > > On the basis of 1<<31 being undefined, then so could all of these, > depending on the values involved (all int32_t), because of overflow: > > a+b > a*b > a<<b > Yes - and they /are/ all undefined if the values overflow. Surely that is not news to you? > > Not sure about a-b, a/b or a>>b regarding overflow. Nor about overflow > when using uint32_t: > > 0x000000FF << 28 > > As a bit-pattern, I would expect that to yield 0xF0000000, which is not > 256*2^28; defined or undefined? And if defined, why? > Unsigned types are defined to use modulo wrapping. This is the kind of stuff I would expect to explain to someone who has been learning C for a few weeks - not someone who has worked with it for years, and has written a sort-of-C compiler.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-22 07:54 -0400 |
| Message-ID | <q72icr$rd4$1@dont-email.me> |
| In reply to | #142232 |
On 3/22/19 06:37, David Brown wrote: > On 21/03/2019 23:29, Bart wrote: ... >> Not sure about a-b, a/b or a>>b regarding overflow. Nor about overflow >> when using uint32_t: >> >> 0x000000FF << 28 The value of 0x000000FF is guaranteed to be less than INT_MAX, so that constant is guaranteed to have the type "int" (6.4.4.1p5). It therefore cannot be of type uint32_t. If he had written 0xFFU, then it would have been of type "unsigned int", which on many systems would be the same as uint32_t. However, if it's important to him that it be uint32_t on all machines that provide such a type, he should have used UINT32_C(0xFF). Even that won't work on systems where UINT_MAX > UINT32_MAX; on such machines, the integer promotions would guarantee that << would never actually operate on 32-bit values, rendering his question meaningless. > Unsigned types are defined to use modulo wrapping. In this case, it's not an unsigned type, though his issue was about an unsigned type.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-22 13:15 +0000 |
| Message-ID | <Cd5lE.724215$Xct1.105830@fx12.am4> |
| In reply to | #142232 |
On 22/03/2019 10:37, David Brown wrote:
> On 21/03/2019 23:29, Bart wrote:
>> As a bit-pattern, I would expect that to yield 0xF0000000, which is not
>> 256*2^28; defined or undefined? And if defined, why?
>>
>
> Unsigned types are defined to use modulo wrapping.
>
> This is the kind of stuff I would expect to explain to someone who has
> been learning C for a few weeks - not someone who has worked with it for
> years, and has written a sort-of-C compiler.
A compiler where integer operations are well-defined (other then divide
by zero). If they overflow, then they overflow in predictable ways that
can be taken into account when writing code:
int32_t a,b,c;
a=2000000000; // defined
b=a+2000000000; // UB according to C
c=b-2000000000; // UB according to C
printf("%d\n",a);
printf("%d\n",b);
printf("%d\n",c);
Guaranteed to display:
2000000000
-294967296
2000000000
I use several languages and I need to have confidence that they will
work solidly and consistently.
I don't have the patience with the fine distinctions that C likes to
make, especially when, as sometimes happens, it sits between one of my
languages where the above is well-defined, and native code where the
above is well-defined, but C is liable to throw a spanner in the works.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 14:31 +0100 |
| Message-ID | <q72o3k$srg$1@dont-email.me> |
| In reply to | #142236 |
On 22/03/2019 14:15, Bart wrote:
> On 22/03/2019 10:37, David Brown wrote:
>> On 21/03/2019 23:29, Bart wrote:
>
>>> As a bit-pattern, I would expect that to yield 0xF0000000, which is not
>>> 256*2^28; defined or undefined? And if defined, why?
>>>
>>
>> Unsigned types are defined to use modulo wrapping.
>>
>> This is the kind of stuff I would expect to explain to someone who has
>> been learning C for a few weeks - not someone who has worked with it for
>> years, and has written a sort-of-C compiler.
>
> A compiler where integer operations are well-defined (other then divide
> by zero). If they overflow, then they overflow in predictable ways that
> can be taken into account when writing code:
>
> int32_t a,b,c;
>
> a=2000000000; // defined
> b=a+2000000000; // UB according to C
> c=b-2000000000; // UB according to C
>
> printf("%d\n",a);
> printf("%d\n",b);
> printf("%d\n",c);
>
> Guaranteed to display:
>
> 2000000000
> -294967296
> 2000000000
>
> I use several languages and I need to have confidence that they will
> work solidly and consistently.
>
> I don't have the patience with the fine distinctions that C likes to
> make, especially when, as sometimes happens, it sits between one of my
> languages where the above is well-defined, and native code where the
> above is well-defined, but C is liable to throw a spanner in the works.
>
Certainly you can make a language where signed integer overflow is
defined as modulo wrapping. You can get it with many C compilers - such
as "gcc -fwrapv". Then there is no undefined behaviour, and the
compiler has to generate code based on those definitions. And it is
solid, consistent and reliable.
But it is, IMHO, a silly idea.
I fail to see the "advantage" of consistent but incorrect answers.
I fail to see the "advantage" of defined behaviour that reduces error
checking and debugging help.
I fail to see the "advantage" of reducing the efficiency of sensible and
correct code.
Undefined behaviour is always incorrect. What you - and others who
misunderstand UB - get wrong, is that giving the code defined behaviour
does not make it correct. It is still wrong, but now it is harder to
see that it is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-21 22:55 -0700 |
| Message-ID | <86sgvfo3la.fsf@mailhub.linuxsc.com> |
| In reply to | #142210 |
Keith Thompson <kst-u@mib.org> writes: > 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.) This part is wrong. The width of a 32-bit int is 32, not 31. The /precision/ of a 32-bit int is 31, but it's the width that matters for the constraints on shifting. The expression 0 << 31 is well defined for 32-bit int's.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-03-22 07:17 -0700 |
| Message-ID | <e6526560-cda0-49ec-9551-3b2bace7d3c3@googlegroups.com> |
| In reply to | #142210 |
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 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]
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web