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 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-04-10 09:18 -0700 |
| Message-ID | <e1f99211-f2da-424a-a06b-79d10892c849@googlegroups.com> |
| In reply to | #142970 |
On Wednesday, April 10, 2019 at 11:35:16 AM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > > It's a nit-pick, to be sure - but clearly stating what you're > > talking about greatly improves communication. > > I see. When I do it, it's splitting hairs, Not always, but often. > but when you do it, it's greatly improving communication. You have a tendency to go farther in that direction than I think is appropriate, whereas, (oddly enough :-) I never go farther in that direction than I think is appropriate. Also, when I come close to my own personal limits as to what's appropriate, I will acknowledge that fact by using words such as "pedantic", "technically", or (as in this case) "nit-pick". It's a matter of judgement, and other people will judge that I'm just splitting hairs. I certainly don't expect you to agree with my judgments, in this matter or any other.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 17:23 +0100 |
| Message-ID | <q78auq$kdv$1@dont-email.me> |
| In reply to | #142319 |
On 23/03/2019 23:55, Bart wrote: > On 23/03/2019 19:41, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >> In real life, though, compilers are not "sloppy" in the way >> you describe. They assume, because they are permitted to do so, >> that the code they're processing has defined behavior (including >> unspecified or implementation-defined). If the code violates >> that assumption, they compiler might generate code that violates >> your expectations -- though strictly speaking if you write code >> whose behavior is undefined, > > Again, this is C's definition of undefined behaviour. What definition could you possibly want for /undefined/ behaviour? Do you also want the language to support negative integers, but not be quite so negative about them? > > I might take the same generic algorithm, and port to a half a dozen > languages including C. > > Only in C is integer overflow considered such a big deal, that it causes > undefined behaviour. And only in C, would code that overflows be assumed > to never happen, allowing compilers to do unpredictable things. > > (If there are languages, other than C++, which don't routinely do > runtime overflow checks, and where integer overflow also is considered > UB, then I'm sure people will tell me. I've only briefly checked Java, > Go, Rust and Fortran. All mine of course allow integer overflow for > primitive types.) I've already told you. Most languages that I know of which compile to assembly, and are aimed at high performance code, make signed integer overflow undefined behaviour. Many tools for these languages provide some help in debugging such code, with options that inserting run-time checks (in the same way gcc and clang can do for C and C++). Languages in this category include Pascal, Modula 2, Fortran, Ada, and Algol. Some languages (like Java) define integer overflow in terms of wrapping. This is cheap (on almost all realistic cpus), and gives you consistent results. Unfortunately, this is almost consistently wrong - and makes it far harder for tools to help you find the bug in your code that led to the overflow. > > The point is, I am just writing code, not necessarily C code, but it is > only when expressing it as C does this come up. > Perhaps this is because C is the only serious language where you have thought about it. Or perhaps C programmers are more concerned about program correctness than others. Or perhaps (and I think this is the right answer), C is the language where you find more of a mixture of programmers who are concerned with correctness, and programmers who are less concerned and happy to make "it worked when I tested it" assumptions. > Integer overflow in a program may well be unintentional, and could When would it /not/ be unintentional, and not a bug? There are very, very few occasions when you want wrapping for any kind of integer (signed or unsigned) - and you can do it safely using unsigned types. > signify a bug (as could unsigned overflow actually), one that sometimes > just simply needs a wider type, and C assuming that's never going to > happen, and using that fact to take liberties with my program, really > isn't helpful. It /is/ helpful to have signed overflow being undefined. It is /not/ helpful to have it defined. > >> One entirely possible consequence of that is that garbage bits from >> the upper half of a 64-bit register might unexpectedly be introduced >> into a 32-bit result. Again, this could happen in the presence of >> undefined behavior. > > That would never happen in any of my compilers. If it does, then it's a > bug. It certainly would never be intentional. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 16:51 +0000 |
| Message-ID | <OAOlE.402483$tK1.266202@fx28.am4> |
| In reply to | #142357 |
On 24/03/2019 16:23, David Brown wrote: > On 23/03/2019 23:55, Bart wrote: >> (If there are languages, other than C++, which don't routinely do >> runtime overflow checks, and where integer overflow also is considered >> UB, then I'm sure people will tell me. I've only briefly checked Java, >> Go, Rust and Fortran. All mine of course allow integer overflow for >> primitive types.) > > I've already told you. Most languages that I know of which compile to > assembly, and are aimed at high performance code, make signed integer > overflow undefined behaviour. You haven't given a list. Java, you've said doesn't make integer overflow undefined. D just wraps signed overflow. Fortran - I couldn't find a mention of it being undefined. Go - signed integers appear to wrap Rust - signed integers also wrap ASM: signed integer generally also wrap All my languages - signed integers wrap etc. If there are languages where this stuff is still UB, the chances are that C or C++ are involved (eg. using gcc or llvm back-ends). But even in C, in practice, most compilers will generate code that exhibits wrapping behaviour. Except that because some take advantage of UB, you can't rely on this. Result: UB programming in C is harder than in those other languages. Example: https://www.i-programmer.info/news/184-cc/11862-c-undefined-behavior-depressing-and-terrifying.html And all that grief for, what, 2% better performance on some programs? >> signify a bug (as could unsigned overflow actually), one that >> sometimes just simply needs a wider type, and C assuming that's never >> going to happen, and using that fact to take liberties with my >> program, really isn't helpful. > > It /is/ helpful to have signed overflow being undefined. It is /not/ > helpful to have it defined. So FF+1 = <totally random behaviour of a program> is good; but FF+1 = 0 is bad? Okay..... Actually, since at the minute no one is holding a gun to my head and demand that I code in C, I can only say that you're welcome to your crazy language AND its undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-24 16:38 -0700 |
| Message-ID | <lnimw7derw.fsf@kst-u.example.com> |
| In reply to | #142357 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I've already told you. Most languages that I know of which compile to
> assembly, and are aimed at high performance code, make signed integer
> overflow undefined behaviour. Many tools for these languages provide
> some help in debugging such code, with options that inserting run-time
> checks (in the same way gcc and clang can do for C and C++). Languages
> in this category include Pascal, Modula 2, Fortran, Ada, and Algol.
[...]
Ada requires an exception to be raised on signed integer overflow.
For example, given this code:
declare
X: Integer := Integer'Last;
begin
X := X + 1;
Put_Line("This should not happen");
end;
the Put_Line call will not be executed if the implementation is
conforming. (A program can handle the exception and continue normal
execution, but the exception transfers control out of the block.)
(Ada does have a "pragma Suppress" that can inhibit checks
-- but if a check would have been triggered, the program has
undefined behavior. There's still no guarantee that X will get
any particular value. Ada compilers can have options to suppress
checks, but strictly speaking such an option would render the
compiler non-conforming.)
I don't know about the other languages you mentioned.
--
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-25 01:32 +0100 |
| Message-ID | <q797iu$2i0$1@dont-email.me> |
| In reply to | #142381 |
On 25/03/2019 00:38, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I've already told you. Most languages that I know of which compile to
>> assembly, and are aimed at high performance code, make signed integer
>> overflow undefined behaviour. Many tools for these languages provide
>> some help in debugging such code, with options that inserting run-time
>> checks (in the same way gcc and clang can do for C and C++). Languages
>> in this category include Pascal, Modula 2, Fortran, Ada, and Algol.
> [...]
>
> Ada requires an exception to be raised on signed integer overflow.
> For example, given this code:
>
> declare
> X: Integer := Integer'Last;
> begin
> X := X + 1;
> Put_Line("This should not happen");
> end;
>
> the Put_Line call will not be executed if the implementation is
> conforming. (A program can handle the exception and continue normal
> execution, but the exception transfers control out of the block.)
>
> (Ada does have a "pragma Suppress" that can inhibit checks
> -- but if a check would have been triggered, the program has
> undefined behavior. There's still no guarantee that X will get
> any particular value. Ada compilers can have options to suppress
> checks, but strictly speaking such an option would render the
> compiler non-conforming.)
>
As I see it, Ada checks on integer overflow by default, but provides
mechanisms to skip these checks (including some that are
implementation-specific). C does not check for integer overflow by
default, but many implementations provide optional checks and/or defined
behaviours.
There is a difference in emphasis and default handling, clearly, but for
practical purposes users have similar choices.
> I don't know about the other languages you mentioned.
>
My experience with Pascal is that compilers usually offer an option to
check arithmetic, but the default is effectively for undefined behaviour
(at least when optimising). It's a /long/ time since I did any Modula
2, but I think the same applies there. For Fortran and Algol, my
comments are all based on stuff I've read.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-25 00:51 +0000 |
| Message-ID | <GCVlE.158925$MT2.51988@fx21.am4> |
| In reply to | #142381 |
On 24/03/2019 23:38, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> I've already told you. Most languages that I know of which compile to >> assembly, and are aimed at high performance code, make signed integer >> overflow undefined behaviour. Many tools for these languages provide >> some help in debugging such code, with options that inserting run-time >> checks (in the same way gcc and clang can do for C and C++). Languages >> in this category include Pascal, Modula 2, Fortran, Ada, and Algol. > [...] > > Ada requires an exception to be raised on signed integer overflow. What could the exception handler do? Especially on production code. > For example, given this code: > > declare > X: Integer := Integer'Last; > begin > X := X + 1; What about the line: 'X:=X+A-B' when A and B are both 1? How about if it's written as: 'X:=X+(A-B)'? And how about: 'X:=-2147483648' (for 32-bit Integer, or -(2**63) for 64-bit)? > I don't know about the other languages you mentioned. > This shows how various languages deal with overflow. https://rosettacode.org/wiki/Integer_overflow
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-24 17:57 -0700 |
| Message-ID | <lnbm1zdb48.fsf@kst-u.example.com> |
| In reply to | #142385 |
Bart <bc@freeuk.com> writes:
> On 24/03/2019 23:38, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> I've already told you. Most languages that I know of which compile to
>>> assembly, and are aimed at high performance code, make signed integer
>>> overflow undefined behaviour. Many tools for these languages provide
>>> some help in debugging such code, with options that inserting run-time
>>> checks (in the same way gcc and clang can do for C and C++). Languages
>>> in this category include Pascal, Modula 2, Fortran, Ada, and Algol.
>> [...]
>>
>> Ada requires an exception to be raised on signed integer overflow.
>
> What could the exception handler do? Especially on production code.
There are plenty of resources for learning Ada, including freely
available copies of the Ada language standard. There's even a
comp.lang.ada newsgroup -- which this is not.
[...]
--
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-25 01:05 +0000 |
| Message-ID | <8PVlE.327404$Pb7.261754@fx06.am4> |
| In reply to | #142386 |
On 25/03/2019 00:57, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 24/03/2019 23:38, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> I've already told you. Most languages that I know of which compile to >>>> assembly, and are aimed at high performance code, make signed integer >>>> overflow undefined behaviour. Many tools for these languages provide >>>> some help in debugging such code, with options that inserting run-time >>>> checks (in the same way gcc and clang can do for C and C++). Languages >>>> in this category include Pascal, Modula 2, Fortran, Ada, and Algol. >>> [...] >>> >>> Ada requires an exception to be raised on signed integer overflow. >> >> What could the exception handler do? Especially on production code. > > There are plenty of resources for learning Ada, including freely > available copies of the Ada language standard. There's even a > comp.lang.ada newsgroup -- which this is not. I don't want to learn Ada. I was just asking what the exception handler for integer overflow could usefully do in a running program, other than display: "Abort: integer overflow detected." The other examples are of things that can usually be handled harmlessly by allowing integers to wrap, as they will give the right answer.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-24 18:35 -0700 |
| Message-ID | <ln4l7rd9dm.fsf@kst-u.example.com> |
| In reply to | #142387 |
Bart <bc@freeuk.com> writes:
[...]
> I don't want to learn Ada.
>
> I was just asking what the exception handler for integer overflow
> could usefully do in a running program, other than display:
>
> "Abort: integer overflow detected."
I'll answer this question privately if you send me an email.
I won't discuss it further here in comp.lang.c.
--
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 | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-25 06:19 +0000 |
| Message-ID | <fpBJ8ChMnEv47@bongo-ra.co> |
| In reply to | #142387 |
On Mon, 25 Mar 2019 01:05:05 +0000
Bart <bc@freeuk.com> wrote:
> I was just asking what the exception handler for integer overflow could
> usefully do in a running program, other than display:
>
> "Abort: integer overflow detected."
It could display
Integer overflow detected! Aborting.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-24 18:51 +0000 |
| Message-ID | <q78jjs$a28$1@z-news.wcss.wroc.pl> |
| In reply to | #142319 |
Bart <bc@freeuk.com> wrote:
> On 23/03/2019 19:41, Keith Thompson wrote:
>
> Again, this is C's definition of undefined behaviour.
>
> I might take the same generic algorithm, and port to a half a dozen
> languages including C.
>
> Only in C is integer overflow considered such a big deal, that it causes
> undefined behaviour. And only in C, would code that overflows be assumed
> to never happen, allowing compilers to do unpredictable things.
>
> (If there are languages, other than C++, which don't routinely do
> runtime overflow checks, and where integer overflow also is considered
> UB, then I'm sure people will tell me. I've only briefly checked Java,
> Go, Rust and Fortran. All mine of course allow integer overflow for
> primitive types.)
You are very wrong here. Pascal spec uses word "error" but
meaning is the same as C undefinded behaviour. Fortran has
_more_ undefined behaviours than C used to have, and that
is why on numeric code Frotran could win with C. Strict
aliasing rules try to match Fortran, so now probably there
is parity... Ada mandates overflow checks, but if you
look at fine print then you will notice that leading Ada
compiler by default is not Ada compiler: overflow checks
are turned off and you get undefined behaviour.
Note that you can not test if overflow is undefined in
a language: simple-minded test is likely to give you
wraparound (or possibly error message if detected at
compile time). It is language spec that matters.
I do not know what Go and Rust specs say, IIUC Java
mandates wraparound. Of languages you did not mention
Lisp by default uses infinite precision, but you may
say to compiler that there are no overflow. If you lie
then you get undefined behaviour...
Realisticaly, it is programmer task to make sure that
there are no integer overflow. If programmer fails
then either you have expensive runtime checks or bad
things will happen. You seem to be in camp which
thinks that it is better if always the same bad
things happen. This has some merits, but IME
with C UB things are predictable enough for effective
debugging. And C rules means that debug code
_may_ catch overlow -- for normal runs that would
be too expensive, but is very helpful for
debugging. One guy wrote that 'cint' was his
secret tool to catch bugs -- with defined wraparound
checks done by 'cint' would be illegal.
Point is that _intentional_ wraparond is rare and
it is not much burden to explicitely mark it as such.
Then tools can insert checks and any unmarked
overflow is a bug. Once you define operations
to wraparound you need original programmer to
tell you what the intent was. Not a problem
if you are original programmer and you remember,
but problem in organizations employing many
programmers.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 19:08 +0000 |
| Message-ID | <yAQlE.366856$VA7.92154@fx07.am4> |
| In reply to | #142364 |
On 24/03/2019 18:51, antispam@math.uni.wroc.pl wrote: > Bart <bc@freeuk.com> wrote: >> On 23/03/2019 19:41, Keith Thompson wrote: >> >> Again, this is C's definition of undefined behaviour. >> >> I might take the same generic algorithm, and port to a half a dozen >> languages including C. >> >> Only in C is integer overflow considered such a big deal, that it causes >> undefined behaviour. And only in C, would code that overflows be assumed >> to never happen, allowing compilers to do unpredictable things. >> >> (If there are languages, other than C++, which don't routinely do >> runtime overflow checks, and where integer overflow also is considered >> UB, then I'm sure people will tell me. I've only briefly checked Java, >> Go, Rust and Fortran. All mine of course allow integer overflow for >> primitive types.) > > You are very wrong here. Pascal spec uses word "error" but > meaning is the same as C undefinded behaviour. Fortran has > _more_ undefined behaviours than C used to have, and that > is why on numeric code Frotran could win with C. Strict > aliasing rules try to match Fortran, so now probably there > is parity... Ada mandates overflow checks, but if you > look at fine print then you will notice that leading Ada > compiler by default is not Ada compiler: overflow checks > are turned off and you get undefined behaviour. > > Note that you can not test if overflow is undefined in > a language: simple-minded test is likely to give you > wraparound (or possibly error message if detected at > compile time). It is language spec that matters. > I do not know what Go and Rust specs say, IIUC Java > mandates wraparound. I gave a list in another post - it seems Java, D, Go and Rust wrap. While signed overflow (just like signed overflow IMO) might suggest a logic error, you do not want a compiler to generate nasal demons. Actually it's not clear if the nasal demons happen when such a compiler detects that UB might occur, or when it assume it can't, but it actually occurs. Programming is another of a job without second-guessing what a compiler might do.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2019-03-24 19:36 +0000 |
| Message-ID | <slrn3q1oq9fn15.hhl.ike@sdf.lonestar.org> |
| In reply to | #142365 |
On 2019-03-24, Bart <bc@freeuk.com> wrote: > While signed overflow (just like signed overflow IMO) Is this a typo? If so, what did you mean to say?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 19:45 +0000 |
| Message-ID | <87RlE.311898$7F3.162487@fx30.am4> |
| In reply to | #142366 |
On 24/03/2019 19:36, Ike Naar wrote: > On 2019-03-24, Bart <bc@freeuk.com> wrote: >> While signed overflow (just like signed overflow IMO) > > Is this a typo? If so, what did you mean to say? 'Just like unsigned overflow IMO'
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2019-03-24 19:49 +0000 |
| Message-ID | <slrn3skkq9fnqc.27g.ike@sdf.lonestar.org> |
| In reply to | #142368 |
On 2019-03-24, Bart <bc@freeuk.com> wrote: > On 24/03/2019 19:36, Ike Naar wrote: >> On 2019-03-24, Bart <bc@freeuk.com> wrote: >>> While signed overflow (just like signed overflow IMO) >> >> Is this a typo? If so, what did you mean to say? > > 'Just like unsigned overflow IMO' Unsigned arithmetic doesn't overflow, it wraps around in a well-defined manner.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 20:10 +0000 |
| Message-ID | <EuRlE.784327$Apg.63023@fx36.am4> |
| In reply to | #142369 |
On 24/03/2019 19:49, Ike Naar wrote: > On 2019-03-24, Bart <bc@freeuk.com> wrote: >> On 24/03/2019 19:36, Ike Naar wrote: >>> On 2019-03-24, Bart <bc@freeuk.com> wrote: >>>> While signed overflow (just like signed overflow IMO) >>> >>> Is this a typo? If so, what did you mean to say? >> >> 'Just like unsigned overflow IMO' > > Unsigned arithmetic doesn't overflow, it wraps around in a > well-defined manner. > Aarghh! Did you read my post in full? I said both kinds suggest logic errors. If you use a 16-bit unsigned word to count the bytes in a set of files, it's going to overflow, never mind that C doesn't consider it to overflow. Exactly the same with signed, which would overflow sooner (that's why you might prefer unsigned), but C classes that as UB. Not helpful.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2019-03-25 06:43 +0000 |
| Message-ID | <slrn3ib0q9gu4t.f90.ike@sdf.lonestar.org> |
| In reply to | #142370 |
On 2019-03-24, Bart <bc@freeuk.com> wrote: > On 24/03/2019 19:49, Ike Naar wrote: >> On 2019-03-24, Bart <bc@freeuk.com> wrote: >>> On 24/03/2019 19:36, Ike Naar wrote: >>>> On 2019-03-24, Bart <bc@freeuk.com> wrote: >>>>> While signed overflow (just like signed overflow IMO) >>>> >>>> Is this a typo? If so, what did you mean to say? >>> >>> 'Just like unsigned overflow IMO' >> >> Unsigned arithmetic doesn't overflow, it wraps around in a >> well-defined manner. >> > > > Aarghh! > > Did you read my post in full? I said both kinds suggest logic errors. > > If you use a 16-bit unsigned word to count the bytes in a set of files, > it's going to overflow, never mind that C doesn't consider it to overflow. > > Exactly the same with signed, which would overflow sooner (that's why > you might prefer unsigned), but C classes that as UB. > > Not helpful. Okay, lets assume that you want to use a 16-bit integer for that purpose (counting bytes in a set of files, which may produce a value that is too large to fit into a 16-bit integer). Now one can choose: - using a signed type, the behaviour on overflow will be undefined. - using an unsigned type, the behaviour on overflow will be well-defined. So far you have been arguing against the fact that unsigned integer overflow has undefined behaviour, and that you want it to be defined behaviour. If one uses an unsigned type, the behaviour *is* defined: the value wraps around in a well-defined manner. Now you say that this is not what you want because it may hide a logic error. So what is it that you want?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-25 11:17 +0000 |
| Message-ID | <0N2mE.429531$%B.129251@fx03.am4> |
| In reply to | #142397 |
On 25/03/2019 06:43, Ike Naar wrote: > On 2019-03-24, Bart <bc@freeuk.com> wrote: >> If you use a 16-bit unsigned word to count the bytes in a set of files, >> it's going to overflow, never mind that C doesn't consider it to overflow. >> >> Exactly the same with signed, which would overflow sooner (that's why >> you might prefer unsigned), but C classes that as UB. >> >> Not helpful. > > Okay, lets assume that you want to use a 16-bit integer for that purpose > (counting bytes in a set of files, which may produce a value that is too > large to fit into a 16-bit integer). > Now one can choose: > - using a signed type, the behaviour on overflow will be undefined. > - using an unsigned type, the behaviour on overflow will be well-defined. > > So far you have been arguing against the fact that unsigned integer overflow > has undefined behaviour, and that you want it to be defined behaviour. > > If one uses an unsigned type, the behaviour *is* defined: the value > wraps around in a well-defined manner. > Now you say that this is not what you want because it may hide a logic error. > > So what is it that you want? Sorry, I can't understand your post. Introducing UB (and possibly a typo; I can't tell), has also sown confusion. This is the point really. The actual choice is this: - Use a signed type with range -32768 to +32767 - Use an unsigned type with range 0 to 65535 That's all it is. In either case it can go wrong if you really need a wider span. If unsigned overflows, it overflows. If signed overflows, it overflows. At best, unsigned overflows in a tidy manner than signed. I understand that C has introduced special rules for those behaviours, so unsigned never overflows; it's a feature not a bug! And signed overflow could format your hard drive, not just because there might be a logic error in your program, but because a compiler is given a licence to do exactly that. So compilers are allowed to make these assumptions: * Unsigned numbers never overflow (they 'wrap') * Signed numbers never overflow (because the program is perfect), although it's not clear at what point the hard drive formatting or the nasal demons start Which makes as much sense as the golden unicorns promised to people who voted for UK's Brexit. What a load of nonsense.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-03-25 06:22 -0700 |
| Message-ID | <0794c970-8a95-4df6-a354-73c88e0a9b44@googlegroups.com> |
| In reply to | #142401 |
On Monday, 25 March 2019 11:17:25 UTC, Bart wrote: > > So compilers are allowed to make these assumptions: > > * Unsigned numbers never overflow (they 'wrap') > * Signed numbers never overflow (because the program is perfect), > although it's not clear at what point the hard drive formatting or > the nasal demons start > > Which makes as much sense as the golden unicorns promised to people who > voted for UK's Brexit. > > What a load of nonsense. > There was a fashion in comp.lang.c a while back for teasing newbies who posted program with UB with descriptions of little elves on screen, or demons flying out of noses, or WW III. It's a bit silly. UB for a wild pointer write can indeed cause the program to behave unpredictably, especially it it overwrites a return address. UB for arithmethical overflow is essentially a licence to either wrap as expected or to terminate the program with an error message. The last behaviour is usually preferable, except for something like a video game where it's better to continue and just hope that the bug doesn't take down the game. No results are usually better than wrong results.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-25 17:01 +0000 |
| Message-ID | <87k1gmoplk.fsf@bsb.me.uk> |
| In reply to | #142406 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > UB for arithmethical overflow is essentially a licence to either wrap > as expected or to terminate the program with an error message. Or to use saturating arithmetic or to perform optimisations based on assuming the operation won't overflow or (no doubt) other things I've forgotten about. Permitting "what the hardware does" is, by and large, universally agreed to be a Good Thing. It's the permission to assume that overflow does not happen that is contentious. Go, for example, explicitly rules that out. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web