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 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-20 16:53 +0100 |
| Message-ID | <q6tnla$k2v$1@dont-email.me> |
| In reply to | #142080 |
On 19/03/2019 22:58, Howard Chu wrote: > There's a proposal to change the C++ spec to declare that all > integers are two's complement. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r1.html > > Is there a corresponding proposed change for the C spec? It would > certainly simplify life and could eliminate a number of undefined > behaviors from the spec. I don't think there is such a proposal. But it would not be unreasonable to have something similar. Just don't think it will eliminate many undefined behaviours. It would remove a few implementation defined behaviours. In particular, it would /not/ make signed integer overflow into defined behaviour - I'd hate to see that happen. I think it would be a good idea for future C standards to fix the signed representation as two's complement, remove all mentions of trapping values for integer types, remove the possibility of padding bits in these types (except perhaps for _Bool), enforce either big or little endian ordering, and tighten up implementation defined behaviour when all current targets have the same behaviour. > > On that topic, it would be nice to see a compiler mode that makes all > undefined behaviors implementation defined, lets the underlying > hardware do whatever it's going to do with them, That will /never/ happen. I can think of several reasons: 1. It would be impossible (there are always things that can be written that have no logical meaning.) 2. Getting even halfway there would require fundamental changes to the nature of C (you'd need a unified error handling mechanism, for a start). 3. It would significantly reduce the efficiency of perfectly good code, and most people don't want that. 4. It would turn incorrect code with undefined behaviour into incorrect code with defined - but still incorrect - behaviour. This does not help the broken code in any way, but makes it a lot harder for static analysers and debugging tools to find the problem, because they now don't know if your code had an error or not. > and most > importantly, stops abusing them in the optimizer. E.g., quit allowing > compilers to delete NULL-pointer checks > https://lwn.net/Articles/342420/ Again, that will /never/ happen - because this is not an "abuse". It is making correct code faster, while changing the way in which broken code is broken. Sometimes such optimisations will inadvertently mean the source code error has greater consequences than it might otherwise have had - but the fault here lies with the Linux kernel code that was clearly incorrect. Compilers give you the choice of fine-grained control of optimisations so that you can balance their benefits against the consequences of the effects of source code errors. (This particular optimisation would not have been very useful in code like the kernel - but it is certainly useful in other kinds of code.) C is a language that demands the programmer take responsibility for writing correct code. Accept that, or find a different programming language. > > I.e., a mode where there are no undefined behaviors, so that the > optimizer is not allowed to assume "this never happens" and thus > cannot ignore or gratuitously delete any of the source code being > compiled. > That can't and won't happen - not when you also want the compiler to generate fast and efficient code.
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 09:30 -0700 |
| Message-ID | <b2676902-cb4c-46a7-aa0e-52f8c2974e28@googlegroups.com> |
| In reply to | #142105 |
On Wednesday, March 20, 2019 at 3:53:23 PM UTC, David Brown wrote:
> C is a language that demands the programmer take responsibility for
> writing correct code.
On this we certainly agree.
> Accept that, or find a different programming language.
It is not the compiler's job to prevent the programmer from writing broken code. That's the programmer's responsibility.
Given:
% cat xx.c
int foo() {
int i = 1 / 0;
}
% gcc -c xx.c
xx.c: In function ‘foo’:
xx.c:2:12: warning: division by zero [-Wdiv-by-zero]
int i = 1 / 0;
^
The compiler still compiles this, even though it generates a warning.
It's not the compiler's job to fix or prevent programmers from writing this.
> >
> > I.e., a mode where there are no undefined behaviors, so that the
> > optimizer is not allowed to assume "this never happens" and thus
> > cannot ignore or gratuitously delete any of the source code being
> > compiled.
> >
>
> That can't and won't happen - not when you also want the compiler to
> generate fast and efficient code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-20 22:58 +0100 |
| Message-ID | <q6ud1u$thm$1@dont-email.me> |
| In reply to | #142110 |
On 20/03/2019 17:30, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 3:53:23 PM UTC, David Brown wrote:
>> C is a language that demands the programmer take responsibility for
>> writing correct code.
>
> On this we certainly agree.
>
>> Accept that, or find a different programming language.
>
> It is not the compiler's job to prevent the programmer from writing broken code. That's the programmer's responsibility.
>
True. But it is also not the compiler's job (or the compiler writers'
job) to read the programmer's mind and guess what he/she was trying to
achieve but failed to write correctly.
> Given:
>
> % cat xx.c
> int foo() {
> int i = 1 / 0;
> }
> % gcc -c xx.c
> xx.c: In function ‘foo’:
> xx.c:2:12: warning: division by zero [-Wdiv-by-zero]
> int i = 1 / 0;
> ^
>
> The compiler still compiles this, even though it generates a warning.
> It's not the compiler's job to fix or prevent programmers from writing this.
>
The compiler "compiles" this code, because it could legally be used in a
program that never calls "foo" - so it has to accept it. But the
compiler is entirely free to implement foo as though the programmer had
written:
int foo() {
launch_nasal_daemons();
return programmers_bank_card_PIN;
}
>
>
>
>
>
>>>
>>> I.e., a mode where there are no undefined behaviors, so that the
>>> optimizer is not allowed to assume "this never happens" and thus
>>> cannot ignore or gratuitously delete any of the source code being
>>> compiled.
>>>
>>
>> That can't and won't happen - not when you also want the compiler to
>> generate fast and efficient code.
>
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-20 15:41 -0700 |
| Message-ID | <9747a924-fa28-4737-99f4-4a59cfa95e27@googlegroups.com> |
| In reply to | #142140 |
On Wednesday, March 20, 2019 at 9:58:29 PM UTC, David Brown wrote:
> On 20/03/2019 17:30, Howard Chu wrote:
> > On Wednesday, March 20, 2019 at 3:53:23 PM UTC, David Brown wrote:
> >> C is a language that demands the programmer take responsibility for
> >> writing correct code.
> >
> > On this we certainly agree.
> >
> >> Accept that, or find a different programming language.
> >
> > It is not the compiler's job to prevent the programmer from writing broken code. That's the programmer's responsibility.
> >
>
> True. But it is also not the compiler's job (or the compiler writers'
> job) to read the programmer's mind and guess what he/she was trying to
> achieve but failed to write correctly.
>
> > Given:
> >
> > % cat xx.c
> > int foo() {
> > int i = 1 / 0;
> > }
> > % gcc -c xx.c
> > xx.c: In function ‘foo’:
> > xx.c:2:12: warning: division by zero [-Wdiv-by-zero]
> > int i = 1 / 0;
> > ^
> >
> > The compiler still compiles this, even though it generates a warning.
> > It's not the compiler's job to fix or prevent programmers from writing this.
> >
>
> The compiler "compiles" this code, because it could legally be used in a
> program that never calls "foo" - so it has to accept it. But the
> compiler is entirely free to implement foo as though the programmer had
> written:
>
> int foo() {
> launch_nasal_daemons();
> return programmers_bank_card_PIN;
> }
I'd say that's totally bogus, since the source is perfectly valid C syntax,
and the compiler has well defined rules for translating syntactically valid
C source into assembly language, and none of those rules include either of
the two items you included above.
Back when I was a gcc maintainer, in the 1.x days, "#pragma" wasn't yet part
of the spec, and so the preprocessor's behavior when encountering it was
officially undefined. In gcc, when the preprocessor encountered #pragma, it
would search your $PATH for rogue or hack binaries and invoke them. If none
of these games were found it would quit with an error. That behavior was both
perfectly legal and perfectly defensible, since "#pragma" isn't actually part
of the C language syntax. I.e., there was nothing else within the language that
you could reasonably expect it to be translated into. But such does not apply
when the source is actually comprised of syntactically valid code.
> >>> I.e., a mode where there are no undefined behaviors, so that the
> >>> optimizer is not allowed to assume "this never happens" and thus
> >>> cannot ignore or gratuitously delete any of the source code being
> >>> compiled.
> >>>
> >>
> >> That can't and won't happen - not when you also want the compiler to
> >> generate fast and efficient code.
I would also argue that invoking random bizarre functions doesn't conform to
the goal of optimizing either space or time, and as such a user could still
legitimately complain that invoking launch_nasal_daemons() is in fact a defect
in the compiler and/or optimizer.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-20 20:12 -0400 |
| Message-ID | <q6uksk$c4g$1@dont-email.me> |
| In reply to | #142151 |
On 3/20/19 18:41, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 9:58:29 PM UTC, David Brown wrote:
>> On 20/03/2019 17:30, Howard Chu wrote:
...
>>> Given:
>>>
>>> % cat xx.c
>>> int foo() {
>>> int i = 1 / 0;
>>> }
>>> % gcc -c xx.c
>>> xx.c: In function ‘foo’:
>>> xx.c:2:12: warning: division by zero [-Wdiv-by-zero]
>>> int i = 1 / 0;
>>> ^
>>>
>>> The compiler still compiles this, even though it generates a warning.
>>> It's not the compiler's job to fix or prevent programmers from writing this.
>>>
>>
>> The compiler "compiles" this code, because it could legally be used in a
>> program that never calls "foo" - so it has to accept it. But the
>> compiler is entirely free to implement foo as though the programmer had
>> written:
>>
>> int foo() {
>> launch_nasal_daemons();
>> return programmers_bank_card_PIN;
>> }
>
> I'd say that's totally bogus, since the source is perfectly valid C syntax,
> and the compiler has well defined rules for translating syntactically valid
> C source into assembly language, and none of those rules include either of
> the two items you included above.
Those rules include "... if the value of
the second operand is zero, the behavior is undefined." (6.5.5p5) and a
definition for "undefined behavior" which reads "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for
which this International Standard imposes no requirements" (3.4.3p1).
You'll have to cite something other than the currently applicable rules
for C code to justify rejecting such a translation.
> Back when I was a gcc maintainer, in the 1.x days, "#pragma" wasn't yet part
> of the spec, and so the preprocessor's behavior when encountering it was
> officially undefined. In gcc, when the preprocessor encountered #pragma, it
> would search your $PATH for rogue or hack binaries and invoke them. If none
> of these games were found it would quit with an error. That behavior was both
> perfectly legal and perfectly defensible, since "#pragma" isn't actually part
> of the C language syntax.
You must be referring to K&R C, for which #pragma did not yet exist.
#pragma has been a part of the C language syntax since the very first
version of the C standard. In C89, it's listed under section 3.8
"Preprocessing Directives" in the section labeled "Syntax".
The thing that made such an implementation legal was in C89 or later was
that the behavior of #pragma directives was completely
implementation-defined, with no restrictions on the form it could take -
except an implicit restriction that it could not have any effect on
translation phases 1-3, since preprocessing directives are not
recognized as such until translation phase 4.
This changed in C99, when a number of standard-defined #pragmas were
added. An implementation can now do what you describe only if the pragma
starts with something other than __STDC__.
...
>>>> That can't and won't happen - not when you also want the compiler to
>>>> generate fast and efficient code.
>
> I would also argue that invoking random bizarre functions doesn't conform to
> the goal of optimizing either space or time,
No, but many other things that do serve to optimize space or time, when
applied to code with defined behavior, can cause comparably bizarre
things to happen when applied to code with undefined behavior.
> ... and as such a user could still
> legitimately complain that invoking launch_nasal_daemons() is in fact a defect
> in the compiler and/or optimizer.
And the compiler can correctly respond to that faulty complaint by
pointing out that the actual defect is in the user's code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 16:00 +0100 |
| Message-ID | <q708uj$l55$1@dont-email.me> |
| In reply to | #142151 |
On 20/03/2019 23:41, Howard Chu wrote:
> On Wednesday, March 20, 2019 at 9:58:29 PM UTC, David Brown wrote:
>> On 20/03/2019 17:30, Howard Chu wrote:
>>> On Wednesday, March 20, 2019 at 3:53:23 PM UTC, David Brown wrote:
>>>> C is a language that demands the programmer take responsibility for
>>>> writing correct code.
>>>
>>> On this we certainly agree.
>>>
>>>> Accept that, or find a different programming language.
>>>
>>> It is not the compiler's job to prevent the programmer from writing broken code. That's the programmer's responsibility.
>>>
>>
>> True. But it is also not the compiler's job (or the compiler writers'
>> job) to read the programmer's mind and guess what he/she was trying to
>> achieve but failed to write correctly.
>>
>>> Given:
>>>
>>> % cat xx.c
>>> int foo() {
>>> int i = 1 / 0;
>>> }
>>> % gcc -c xx.c
>>> xx.c: In function ‘foo’:
>>> xx.c:2:12: warning: division by zero [-Wdiv-by-zero]
>>> int i = 1 / 0;
>>> ^
>>>
>>> The compiler still compiles this, even though it generates a warning.
>>> It's not the compiler's job to fix or prevent programmers from writing this.
>>>
>>
>> The compiler "compiles" this code, because it could legally be used in a
>> program that never calls "foo" - so it has to accept it. But the
>> compiler is entirely free to implement foo as though the programmer had
>> written:
>>
>> int foo() {
>> launch_nasal_daemons();
>> return programmers_bank_card_PIN;
>> }
>
> I'd say that's totally bogus, since the source is perfectly valid C syntax,
> and the compiler has well defined rules for translating syntactically valid
> C source into assembly language, and none of those rules include either of
> the two items you included above.
>
You are failing to understand how C works, on two points. The
expression "1/0" is syntactically valid - but it is a semantic error
(i.e., it does not make sense). It is undefined behaviour, it has no
meaning in C, and the compiler can do whatever it likes if that code is
run. The translation I gave above is allowed.
Secondly, you are misunderstanding how C works even when behaviour is
fully defined (by the C standard, or by the implementation). There are
no rules for generating assembly language. The compiler is /not/ a
translator (or at least, it does not have to be). The compiler's job is
to identify the effects the C code would have on the abstract C machine,
concentrating solely on the "observable behaviour", and generate
assembly code that produces the same pattern of observable behaviour for
the same input. It can do so in whatever way it wants. A good compiler
will usually try to generate more efficient code than a direct
translation (i.e., it will optimise code), but it is also allowed to
"pessimise" in any way it likes.
In the "old days", C compilers were often close to direct translators.
But modern compilers, when heavy optimisations are enabled, give you
something very far from the structure of the original source code.
> Back when I was a gcc maintainer, in the 1.x days, "#pragma" wasn't yet part
> of the spec, and so the preprocessor's behavior when encountering it was
> officially undefined. In gcc, when the preprocessor encountered #pragma, it
> would search your $PATH for rogue or hack binaries and invoke them. If none
> of these games were found it would quit with an error. That behavior was both
> perfectly legal and perfectly defensible, since "#pragma" isn't actually part
> of the C language syntax. I.e., there was nothing else within the language that
> you could reasonably expect it to be translated into. But such does not apply
> when the source is actually comprised of syntactically valid code.
>
>>>>> I.e., a mode where there are no undefined behaviors, so that the
>>>>> optimizer is not allowed to assume "this never happens" and thus
>>>>> cannot ignore or gratuitously delete any of the source code being
>>>>> compiled.
>>>>>
>>>>
>>>> That can't and won't happen - not when you also want the compiler to
>>>> generate fast and efficient code.
>
> I would also argue that invoking random bizarre functions doesn't conform to
> the goal of optimizing either space or time, and as such a user could still
> legitimately complain that invoking launch_nasal_daemons() is in fact a defect
> in the compiler and/or optimizer.
>
Clearly, intentionally invoking random functions for undefined behaviour
is not helpful - and it is not something any real compiler would do.
But it is allowed behaviour for conforming compilers. And this is vital
to the efficiency of C - it means that compilers do not have to avoid
/accidentally/ doing something weird when there is undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-03-21 08:10 -0700 |
| Message-ID | <9a25fbb8-e4f1-4348-ba97-073b73994994@googlegroups.com> |
| In reply to | #142178 |
On Thursday, 21 March 2019 15:00:44 UTC, David Brown wrote: > On 20/03/2019 23:41, Howard Chu wrote: > > > > > I would also argue that invoking random bizarre functions doesn't conform to > > the goal of optimizing either space or time, and as such a user could still > > legitimately complain that invoking launch_nasal_daemons() is in fact a > > defect in the compiler and/or optimizer. > > > > Clearly, intentionally invoking random functions for undefined behaviour > is not helpful - and it is not something any real compiler would do. > But it is allowed behaviour for conforming compilers. And this is vital > to the efficiency of C - it means that compilers do not have to avoid > /accidentally/ doing something weird when there is undefined behaviour. > The other factor is that undefined behaviour allows the compiler to insert code to terminate the process with an error message, such as "arithmetical overflow". Given the constraints of fixed-width arithmetic, that's as close to correct behaviour as it can get, and far preferable to silently wrapping the result and ploughing on with a now corrupted value. Unfortunately you can't mandate the error message without imposing unacceptable run time costs on processors that don't flag overflow conditions, so the behaviour has to be "undefined".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-21 22:35 +0100 |
| Message-ID | <q7103r$c9d$1@dont-email.me> |
| In reply to | #142179 |
On 21/03/2019 16:10, Malcolm McLean wrote: > On Thursday, 21 March 2019 15:00:44 UTC, David Brown wrote: >> On 20/03/2019 23:41, Howard Chu wrote: >> >>> >>> I would also argue that invoking random bizarre functions doesn't conform to >>> the goal of optimizing either space or time, and as such a user could still >>> legitimately complain that invoking launch_nasal_daemons() is in fact a >>> defect in the compiler and/or optimizer. >>> >> >> Clearly, intentionally invoking random functions for undefined behaviour >> is not helpful - and it is not something any real compiler would do. >> But it is allowed behaviour for conforming compilers. And this is vital >> to the efficiency of C - it means that compilers do not have to avoid >> /accidentally/ doing something weird when there is undefined behaviour. >> > The other factor is that undefined behaviour allows the compiler to insert > code to terminate the process with an error message, such as "arithmetical > overflow". Given the constraints of fixed-width arithmetic, that's as > close to correct behaviour as it can get, and far preferable to silently > wrapping the result and ploughing on with a now corrupted value. > Unfortunately you can't mandate the error message without imposing > unacceptable run time costs on processors that don't flag overflow > conditions, so the behaviour has to be "undefined". > Yes, that's all true. I already mentioned that one advantage of undefined behaviour is that it helps in static error checking and run-time debugging. If a calculation overflows in an undefined way, it is fine for a compiler to insert such run-time checks and error messages to help debug the code. But if overflows were defined in some way (such as wrapping), then there is no way for the compiler to know if this was intentional or not - it can't help you find your mistakes.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-03-22 10:32 +0100 |
| Message-ID | <q72a3o$e4p$1@dont-email.me> |
| In reply to | #142179 |
Le 21/03/2019 à 16:10, Malcolm McLean a écrit : > without imposing > unacceptable run time costs on processors that don't flag overflow > conditions, Yeah, I have heared a lot about those processors in this group... Can you name one please? A processor without overflow flag or a means to detect overflow??? Thanks
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-22 12:25 +0100 |
| Message-ID | <q72go2$ilb$1@dont-email.me> |
| In reply to | #142230 |
On 22/03/2019 10:32, jacobnavia wrote: > Le 21/03/2019 à 16:10, Malcolm McLean a écrit : >> without imposing >> unacceptable run time costs on processors that don't flag overflow >> conditions, > > Yeah, I have heared a lot about those processors in this group... > > Can you name one please? > > A processor without overflow flag or a means to detect overflow??? > MIPS, RISC-V and Alpha do not have processor flags. They do, of course, have means to detect overflow - just not by flags. Flags are often a serious pain in pipelined cpu design - they can be a big bottleneck, and a dependency that must be tracked. Some ISA's, like x86, deal with this by a lot of smart hardware. Others, like most RISC designs, have no flag settings for most instructions. (On the PPC, for example, "add" does not set any flags - you use "add." to set flags.) Some don't have flag registers at all, but have instructions that effectively implement C expressions like "x = (y >= z)". There are also some small microcontrollers that have more limited flags than the usual (carry, overflow, zero). I have worked with one such processor (the COP8, since you wanted names).
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-03-22 18:15 +0100 |
| Message-ID | <q7358a$dl5$1@dont-email.me> |
| In reply to | #142233 |
Le 22/03/2019 à 12:25, David Brown a écrit : > On 22/03/2019 10:32, jacobnavia wrote: >> Le 21/03/2019 à 16:10, Malcolm McLean a écrit : >>> without imposing >>> unacceptable run time costs on processors that don't flag overflow >>> conditions, >> >> Yeah, I have heared a lot about those processors in this group... >> >> Can you name one please? >> >> A processor without overflow flag or a means to detect overflow??? >> > > MIPS, RISC-V and Alpha do not have processor flags. They do, of course, > have means to detect overflow - just not by flags. > Sure. Thats why I said "a means of detecting overflow!" ALL of them can detect overflow. > Flags are often a serious pain in pipelined cpu design - they can be a > big bottleneck, and a dependency that must be tracked. Some ISA's, like > x86, deal with this by a lot of smart hardware. Others, like most RISC > designs, have no flag settings for most instructions. (On the PPC, for > example, "add" does not set any flags - you use "add." to set flags.) As the ARM etc. But they DO HAVE a means of detecting overflow, again. > Some don't have flag registers at all, but have instructions that > effectively implement C expressions like "x = (y >= z)". > > There are also some small microcontrollers that have more limited flags > than the usual (carry, overflow, zero). I have worked with one such > processor (the COP8, since you wanted names). > The COP8 can detect overflow using the caryy out flag. (Even if it is small, the processor DOES have a carry FLAG). Anyway, that processor will never support standard C since it has no floating point, and with 1KB of RAM you can't do anything with a high level language. I stand by my assertion: there is NO processor that can't detect overflow.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 15:29 +0100 |
| Message-ID | <q78493$bb$1@dont-email.me> |
| In reply to | #142249 |
On 22/03/2019 18:15, jacobnavia wrote: > Le 22/03/2019 à 12:25, David Brown a écrit : >> On 22/03/2019 10:32, jacobnavia wrote: >>> Le 21/03/2019 à 16:10, Malcolm McLean a écrit : >>>> without imposing >>>> unacceptable run time costs on processors that don't flag overflow >>>> conditions, >>> >>> Yeah, I have heared a lot about those processors in this group... >>> >>> Can you name one please? >>> >>> A processor without overflow flag or a means to detect overflow??? >>> >> >> MIPS, RISC-V and Alpha do not have processor flags. They do, of course, >> have means to detect overflow - just not by flags. >> > > Sure. Thats why I said "a means of detecting overflow!" > > ALL of them can detect overflow. > Agreed. Any cpu that can do basic arithmetic and comparisons can detect overflow. But they do not "flag overflow conditions". There is a distinction. In particular, processors that have flags will get the overflow detection "for free", while processors without flags require several additional steps to detect overflow. If you think anyone has suggested otherwise in this group, you have misunderstood. People have, correctly, suggested that overflow detection can be expensive in terms of processor time or code size. But no one has ever suggested it could not be done. (It is costly in time and code space even on processors that have overflow flags.) > >> Flags are often a serious pain in pipelined cpu design - they can be a >> big bottleneck, and a dependency that must be tracked. Some ISA's, like >> x86, deal with this by a lot of smart hardware. Others, like most RISC >> designs, have no flag settings for most instructions. (On the PPC, for >> example, "add" does not set any flags - you use "add." to set flags.) > > As the ARM etc. But they DO HAVE a means of detecting overflow, again. > >> Some don't have flag registers at all, but have instructions that >> effectively implement C expressions like "x = (y >= z)". >> >> There are also some small microcontrollers that have more limited flags >> than the usual (carry, overflow, zero). I have worked with one such >> processor (the COP8, since you wanted names). >> > > The COP8 can detect overflow using the caryy out flag. (Even if it is > small, the processor DOES have a carry FLAG). A carry flag does not detect signed integer overflow. If you add 0x40 to 0x40 on such a processor, you get 0x80 and no flags are set, despite the signed integer overflow. The carry flag is very useful for multi-byte arithmetic, but not for overflow detection. It is, obviously, possible to check for overflow - but it is an ugly and complicated matter (especially on a chip with one 8-bit accumulator and only two other limited registers). Basically, you don't do much signed arithmetic on such devices - and you make sure your calculations won't overflow. > > Anyway, that processor will never support standard C since it has no > floating point, and with 1KB of RAM you can't do anything with a high > level language. There are C compilers for this chip, as there are for many others - there is no requirement that a cpu supports floating point. Very few of the chips I use have hardware floating point support, and few of these have hardware double support - you use software libraries as needed. (To be fair, the C compilers I know of for the the COP8 had only 32-bit floating point support and no double support, and are thus not fully compliant C compilers.) Only the very biggest devices in that family had 1 KB of RAM. Common ones had 128 bytes. > > I stand by my assertion: there is NO processor that can't detect overflow. > As I said, no one has ever suggested otherwise. What people /have/ said, correctly, is that there are several processors (including some very powerful cpus) that don't have overflow flags. And what people have also said, correctly, is that overflow detection is often an expensive matter in time and code space, regardless of the cpu in question.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-24 22:03 +0000 |
| Message-ID | <k3_uC0Qm1FU@bongo-ra.co> |
| In reply to | #142249 |
On Fri, 22 Mar 2019 18:15:54 +0100 jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 22/03/2019 12:25, David Brown : > > > > MIPS, RISC-V and Alpha do not have processor flags. They do, of course, > > have means to detect overflow - just not by flags. > > > > Sure. Thats why I said "a means of detecting overflow!" > > ALL of them can detect overflow. [...] > I stand by my assertion: there is NO processor that can't detect overflow. Since one can detect , even using standard C , that the result of an integer arithmetic operation won't be within bounds , it's a trivial corollary that there is a sequence of assembly instructions which achieves the same result. The crucial question is how much slower these will be compared to the assembly instructions which simply perform the operation without checking that the result is within bounds.
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-21 10:43 -0700 |
| Message-ID | <b42079b6-61d4-4620-b363-44a64aacf189@googlegroups.com> |
| In reply to | #142178 |
On Thursday, March 21, 2019 at 3:00:44 PM UTC, David Brown wrote:
> On 20/03/2019 23:41, Howard Chu wrote:
> > On Wednesday, March 20, 2019 at 9:58:29 PM UTC, David Brown wrote:
> >> On 20/03/2019 17:30, Howard Chu wrote:
> >>> On Wednesday, March 20, 2019 at 3:53:23 PM UTC, David Brown wrote:
> >>>> C is a language that demands the programmer take responsibility for
> >>>> writing correct code.
> >>>
> >>> On this we certainly agree.
> >>>
> >>>> Accept that, or find a different programming language.
> >>>
> >>> It is not the compiler's job to prevent the programmer from writing broken code. That's the programmer's responsibility.
> >>>
> >>
> >> True. But it is also not the compiler's job (or the compiler writers'
> >> job) to read the programmer's mind and guess what he/she was trying to
> >> achieve but failed to write correctly.
> >>
> >>> Given:
> >>>
> >>> % cat xx.c
> >>> int foo() {
> >>> int i = 1 / 0;
> >>> }
> >>> % gcc -c xx.c
> >>> xx.c: In function ‘foo’:
> >>> xx.c:2:12: warning: division by zero [-Wdiv-by-zero]
> >>> int i = 1 / 0;
> >>> ^
> >>>
> >>> The compiler still compiles this, even though it generates a warning.
> >>> It's not the compiler's job to fix or prevent programmers from writing this.
> >>>
> >>
> >> The compiler "compiles" this code, because it could legally be used in a
> >> program that never calls "foo" - so it has to accept it. But the
> >> compiler is entirely free to implement foo as though the programmer had
> >> written:
> >>
> >> int foo() {
> >> launch_nasal_daemons();
> >> return programmers_bank_card_PIN;
> >> }
> >
> > I'd say that's totally bogus, since the source is perfectly valid C syntax,
> > and the compiler has well defined rules for translating syntactically valid
> > C source into assembly language, and none of those rules include either of
> > the two items you included above.
> >
>
> You are failing to understand how C works, on two points. The
> expression "1/0" is syntactically valid - but it is a semantic error
> (i.e., it does not make sense). It is undefined behaviour, it has no
> meaning in C, and the compiler can do whatever it likes if that code is
> run. The translation I gave above is allowed.
If the spec is being interpreted this way, this is either a faulty interpretation or a faulty spec.
>
> Secondly, you are misunderstanding how C works even when behaviour is
> fully defined (by the C standard, or by the implementation). There are
> no rules for generating assembly language. The compiler is /not/ a
> translator (or at least, it does not have to be). The compiler's job is
> to identify the effects the C code would have on the abstract C machine,
> concentrating solely on the "observable behaviour", and generate
> assembly code that produces the same pattern of observable behaviour for
> the same input. It can do so in whatever way it wants. A good compiler
> will usually try to generate more efficient code than a direct
> translation (i.e., it will optimise code), but it is also allowed to
> "pessimise" in any way it likes.
>
> In the "old days", C compilers were often close to direct translators.
> But modern compilers, when heavy optimisations are enabled, give you
> something very far from the structure of the original source code.
>
> > Back when I was a gcc maintainer, in the 1.x days, "#pragma" wasn't yet part
> > of the spec, and so the preprocessor's behavior when encountering it was
> > officially undefined. In gcc, when the preprocessor encountered #pragma, it
> > would search your $PATH for rogue or hack binaries and invoke them. If none
> > of these games were found it would quit with an error. That behavior was both
> > perfectly legal and perfectly defensible, since "#pragma" isn't actually part
> > of the C language syntax. I.e., there was nothing else within the language that
> > you could reasonably expect it to be translated into. But such does not apply
> > when the source is actually comprised of syntactically valid code.
> >
> >>>>> I.e., a mode where there are no undefined behaviors, so that the
> >>>>> optimizer is not allowed to assume "this never happens" and thus
> >>>>> cannot ignore or gratuitously delete any of the source code being
> >>>>> compiled.
> >>>>>
> >>>>
> >>>> That can't and won't happen - not when you also want the compiler to
> >>>> generate fast and efficient code.
> >
> > I would also argue that invoking random bizarre functions doesn't conform to
> > the goal of optimizing either space or time, and as such a user could still
> > legitimately complain that invoking launch_nasal_daemons() is in fact a defect
> > in the compiler and/or optimizer.
> >
>
> Clearly, intentionally invoking random functions for undefined behaviour
> is not helpful - and it is not something any real compiler would do.
> But it is allowed behaviour for conforming compilers. And this is vital
> to the efficiency of C - it means that compilers do not have to avoid
> /accidentally/ doing something weird when there is undefined behaviour.
Saying that compilers don't have to avoid doing weird things by accident is NOT the same as saying that compilers *are free to do weird things whenever they wish.*
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-21 15:09 -0400 |
| Message-ID | <q70ngp$lfo$1@dont-email.me> |
| In reply to | #142192 |
On 3/21/19 13:43, Howard Chu wrote: > On Thursday, March 21, 2019 at 3:00:44 PM UTC, David Brown wrote: ... >> You are failing to understand how C works, on two points. The >> expression "1/0" is syntactically valid - but it is a semantic error >> (i.e., it does not make sense). It is undefined behaviour, it has no >> meaning in C, and the compiler can do whatever it likes if that code is >> run. The translation I gave above is allowed. > > If the spec is being interpreted this way, this is either a faulty interpretation or a faulty spec. You would probably consider it a faulty spec, but the people who created that spec did so with the deliberate intent that it be interpreted that way, because they considered it desirable that it be so interpreted. ... >> Clearly, intentionally invoking random functions for undefined behaviour >> is not helpful - and it is not something any real compiler would do. >> But it is allowed behaviour for conforming compilers. And this is vital >> to the efficiency of C - it means that compilers do not have to avoid >> /accidentally/ doing something weird when there is undefined behaviour. > > Saying that compilers don't have to avoid doing weird things by accident is NOT the same as saying that compilers *are free to do weird things whenever they wish.* Actually, it pretty much is - any attempt to say otherwise requires that you define what you mean by "wierd things", and it's pretty hard to come up with a definition that allows optimizations that the committee considers desirable while prohibiting things that you'd consider undesirable (particularly because I'm pretty sure, from your messages, that there's overlap between those two categories).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-21 12:45 -0700 |
| Message-ID | <lnbm24ggeg.fsf@kst-u.example.com> |
| In reply to | #142192 |
Howard Chu <highlandsun@gmail.com> writes:
> On Thursday, March 21, 2019 at 3:00:44 PM UTC, David Brown wrote:
[...]
>> You are failing to understand how C works, on two points. The
>> expression "1/0" is syntactically valid - but it is a semantic error
>> (i.e., it does not make sense). It is undefined behaviour, it has no
>> meaning in C, and the compiler can do whatever it likes if that code is
>> run. The translation I gave above is allowed.
>
> If the spec is being interpreted this way, this is either a faulty
> interpretation or a faulty spec.
It is not a faulty interpretation. It is a "faulty spec" only in the
sense that, apparently, it's a spec that you dislike. That's perfectly
fine, and I agree completely -- that is, I agree that you dislike it.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-21 10:53 -0700 |
| Message-ID | <ff19f3bb-cb50-4e49-9c1d-4e8062bc2928@googlegroups.com> |
| In reply to | #142178 |
On Thursday, March 21, 2019 at 3:00:44 PM UTC, David Brown wrote: > You are failing to understand how C works, on two points. The > expression "1/0" is syntactically valid - but it is a semantic error > (i.e., it does not make sense). It is undefined behaviour, it has no > meaning in C, and the compiler can do whatever it likes if that code is > run. The translation I gave above is allowed. > > Secondly, you are misunderstanding how C works even when behaviour is > fully defined (by the C standard, or by the implementation). There are > no rules for generating assembly language. The compiler is /not/ a > translator (or at least, it does not have to be). The compiler's job is > to identify the effects the C code would have on the abstract C machine, > concentrating solely on the "observable behaviour", and generate > assembly code that produces the same pattern of observable behaviour for > the same input. It can do so in whatever way it wants. A good compiler > will usually try to generate more efficient code than a direct > translation (i.e., it will optimise code), but it is also allowed to > "pessimise" in any way it likes. The language may be defined in terms of an abstract machine, but its result must run on real machines; this is why anyone bothers to use it. Otherwise you could just run Java or any of a multitude of other VM-based languages. It would be sufficient to amend the spec to say: the effect of undefined behaviors in the abstract machine are left to the underlying real machine to manifest. I.e., the underlying machine may generate a trap, may ignore the instructions, or whatever. But it's not the compiler's prerogative to *delete* the code and prevent the underlying machine from even executing the relevant code at all. That's just utter nonsense. The compiler's job is to translate source code into executable code for the underlying machine. Not to judge whether the code makes sense, either in abstract or in an actual machine. > > In the "old days", C compilers were often close to direct translators. > But modern compilers, when heavy optimisations are enabled, give you > something very far from the structure of the original source code. > > > Back when I was a gcc maintainer, in the 1.x days, "#pragma" wasn't yet part > > of the spec, and so the preprocessor's behavior when encountering it was > > officially undefined. In gcc, when the preprocessor encountered #pragma, it > > would search your $PATH for rogue or hack binaries and invoke them. If none > > of these games were found it would quit with an error. That behavior was both > > perfectly legal and perfectly defensible, since "#pragma" isn't actually part > > of the C language syntax. I.e., there was nothing else within the language that > > you could reasonably expect it to be translated into. But such does not apply > > when the source is actually comprised of syntactically valid code.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-21 15:18 -0400 |
| Message-ID | <q70o1j$op8$1@dont-email.me> |
| In reply to | #142193 |
On 3/21/19 13:53, Howard Chu wrote: > On Thursday, March 21, 2019 at 3:00:44 PM UTC, David Brown wrote: > >> You are failing to understand how C works, on two points. The >> expression "1/0" is syntactically valid - but it is a semantic error >> (i.e., it does not make sense). It is undefined behaviour, it has no >> meaning in C, and the compiler can do whatever it likes if that code is >> run. The translation I gave above is allowed. >> >> Secondly, you are misunderstanding how C works even when behaviour is >> fully defined (by the C standard, or by the implementation). There are >> no rules for generating assembly language. The compiler is /not/ a >> translator (or at least, it does not have to be). The compiler's job is >> to identify the effects the C code would have on the abstract C machine, >> concentrating solely on the "observable behaviour", and generate >> assembly code that produces the same pattern of observable behaviour for >> the same input. It can do so in whatever way it wants. A good compiler >> will usually try to generate more efficient code than a direct >> translation (i.e., it will optimise code), but it is also allowed to >> "pessimise" in any way it likes. > > The language may be defined in terms of an abstract machine, but its result > must run on real machines; this is why anyone bothers to use it. Otherwise > you could just run Java or any of a multitude of other VM-based languages. > > It would be sufficient to amend the spec to say: the effect of undefined behaviors in the abstract machine are left to the underlying real machine to manifest. > > I.e., the underlying machine may generate a trap, may ignore the instructions, or whatever. But it's not the compiler's prerogative to *delete* the code and prevent the underlying machine from even executing the relevant code at all. ... Well, the intended purpose of the relevant wording is allow optimizations that, among other things, delete unnecessary code. Modern C compilers would produce much slower code if they were prohibited from doing so. Code that deals with a case that could only come up if the behavior is undefined IS unnecessary code. You're thinking like an assembly code writer - the assembler's job is to do precisely whatever the author of the code told it to do. That's not how C is intended to work. As the author of C code, you tell the compiler what results you want, and the C implementation chooses whichever method it thinks best to achieve those results. If you don't want to give the implementation that much freedom, choose a different language which gives it less freedom - C isn't that language. When you write C code with undefined behavior, you're telling the implementation that you don't care what the results are. I recommend not telling it that, unless you really mean it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-21 12:55 -0700 |
| Message-ID | <ln7ecsgfyb.fsf@kst-u.example.com> |
| In reply to | #142193 |
Howard Chu <highlandsun@gmail.com> writes:
[...]
> The language may be defined in terms of an abstract machine, but its result
> must run on real machines; this is why anyone bothers to use it. Otherwise
> you could just run Java or any of a multitude of other VM-based languages.
>
> It would be sufficient to amend the spec to say: the effect of
> undefined behaviors in the abstract machine are left to the underlying
> real machine to manifest.
>
> I.e., the underlying machine may generate a trap, may ignore the
> instructions, or whatever. But it's not the compiler's prerogative to
> *delete* the code and prevent the underlying machine from even
> executing the relevant code at all. That's just utter nonsense. The
> compiler's job is to translate source code into executable code for
> the underlying machine. Not to judge whether the code makes sense,
> either in abstract or in an actual machine.
I'd like to see a rigorous specification of that, in terms of C
source code and the *observable behavior* of C programs. It's not
the C standard's place to talk about generated machine code.
There might not even be any generated code for an interpretive
implementation.
Optimizing C compilers do not detect undefined behavior and then
decide to generate silly code. They *assume* that the input source
code has defined behavior, and then generate machine code based
on that assumption. By the time an optimizer is deleting code
(more accurately, refraining from generating machine code for some
source code), the compiler likely doesn't even know that the input
C code had undefined behavior.
For this:
#include <stdio.h>
int main(void) {
puts("Hello");
return 0;
puts("WTF?");
}
would you require a compiler to generate code for the second puts()
call?
(It certainly would be nice if it were easier to determine whether
a given C source program has undefined behavior. In some languages
other than C, it *is* generally easier. But I don't know of any
language that completely avoids undefined behavior without expensive
run-time checking.)
--
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-21 19:55 +0000 |
| Message-ID | <bbbbPvO0TB2QttltgH9QFlBQ7@bongo-ra.co> |
| In reply to | #142193 |
On Thu, 21 Mar 2019 10:53:17 -0700 (PDT) Howard Chu <highlandsun@gmail.com> wrote: > The language may be defined in terms of an abstract machine, but its result > must run on real machines; this is why anyone bothers to use it. Otherwise > you could just run Java or any of a multitude of other VM-based languages. One uses C for various reasons and one of them is not to use assembly because one finds it easier to think in terms of C than in terms of assembly and of course their code will be more portable too. In certain situations it might be more convenient to think in terms of assembly than in terms of C (for example in assembly it's way easier than it is in C to find out if the result of an integer arithmetic operation was not within bounds). But averaging out of all situations , it's easier to think in terms of C than it terms of assembly. You seem to have some kind of abstract assembly language in mind , which you haven't even specified , and you seem to also think that there is an obvious translation of any C source code (even if it has undefined behaviour) to this abstract assembly. Well , if you describe what that abstract assembly is and what the translation is , then we might make progress. Giving some simple examples is nowhere near enough. > It would be sufficient to amend the spec to say: the effect of undefined > behaviors in the abstract machine are left to the underlying real machine > to manifest. In the case of undefined behaviour , there's no such thing as "the" effect , any behaviour of the executable can count as "the" effect. So if the compiler creates an executable , then it is already the case that the executable , running on the underlying real machine , manifests some effect(s) of the undefined behaviour which are as legitimate as any other effects. So the only corollary of your stipulation would be that in the case of undefined behaviour , the compiler would be forbidden to exit with an error message without producing an executable. I consider this an undesirable restriction. > I.e., the underlying machine may generate a trap, may ignore the > instructions, or whatever. But it's not the compiler's prerogative to > *delete* the code and prevent the underlying machine from even executing > the relevant code at all. If the source code has undefined behaviour then any executable code can count as "the relevant code" even if it's identical to executable code which would have been produced by entirely different source code (which might or might not have undefined behaviour). > That's just utter nonsense. The compiler's job is > to translate source code into executable code for the underlying machine. > Not to judge whether the code makes sense, either in abstract or in an > actual machine. The compiler must decide what the source code specifies the abstract machine to do and generate executable code to achieve that result. If the source code has undefined behaviour then it doesn't specify the abstract machine to do anything specific. The distinction between defined and undefined behaviour has nothing to do with whether the code "makes sense". -- vlaho.ninja/prog
[toc] | [prev] | [next] | [standalone]
Page 13 of 14 — ← Prev page 1 … 11 12 [13] 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web