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 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-25 21:26 -0400 |
| Message-ID | <q7bv3c$qfa$1@dont-email.me> |
| In reply to | #142392 |
On 3/24/19 23:37, Howard Chu wrote: ... > I vaguely recall (but don't have a specific reference now) that the rules > of "effective types" in C makes it impossible to write your own malloc() or > memcpy() implementations in conforming C. I hope you do remember the details - to the best of my knowledge a memcpy() equivalent can be trivially written in strictly conforming C. > The rule that pointers from different objects can't be compared is somewhat > meaningless. The malloc and free functions need to be able to compare their > arguments against their heap boundaries, at least. I think you mean "realloc", not "malloc". malloc()'s only argument cannot meaningfully compared with the heap boundaries. realloc() and free() don't need to check their arguments against their heap boundaries - they're entitled to assume that their argument points into the heap, and to fail catastrophically if that isn't the case. That fact greatly simplifies their implementation on some systems. > ... And for that to be legal > for them to do, the heap itself must be a single character array. But if the > heap *is* a single character array, that means that all pointers returned > from malloc are actually part of a single object, and thus should be legal > to compare to each other, regardless of what kind of structure/type the > caller uses them for. The heap need not be a single block of memory - it's entirely feasible for it to consist of a series of disconnected blocks. On a segment-offset architecture, the malloc() family could keep a list of specific segments that they're currently using, and search that list when needed - they need not be adjacent segments - the concept of "adjacent segments" need not even be meaningful on that platform. Some real world implementations of malloc() round every allocation up to a power of two, and allocate each power of two from a different memory pool. This simplifies some of the logic. They can tell what the size of an allocation is by determining which pool it's from. > Meanwhile, on a system where the heap is implemented by something like mmap() > which can return discontiguous memory regions on subsequent calls, the C spec > says you're screwed, you can't legally compare the pointers from different > map regions. Which is utter nonsense. This "nonsense" was written because there are real-world machines where pointers to different blocks of memory cannot be meaningfully give a total ordering. > One of the essential traits of K&R C was that you could implement the language > in itself. With modern C you can't do that any more. You could implement a C compiler in C - that's not quite the same thing. The C standard library contains many functions, such as fopen(), that do things that the language itself provides no method of implementing, at least not in portable code. They are implemented either by writing non-portable C code, or in some other language, such as assembler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-26 09:55 +0100 |
| Message-ID | <q7cpdf$bmp$1@dont-email.me> |
| In reply to | #142450 |
On 26/03/2019 02:26, James Kuyper wrote: > On 3/24/19 23:37, Howard Chu wrote: > ... >> I vaguely recall (but don't have a specific reference now) that the rules >> of "effective types" in C makes it impossible to write your own malloc() or >> memcpy() implementations in conforming C. > > I hope you do remember the details - to the best of my knowledge a > memcpy() equivalent can be trivially written in strictly conforming C. Can a "my_memcpy" function copy the effective type of an object, in the way the library "memcpy" does? It looks to me that this will work as long as "my_memcpy" works by character - but that is looking at C11 (6.5p6). I don't know if it is the same in earlier standards. (Also, does this in fact matter? Suppose you have an "int" and some memory with no declared type. If you use memcpy to copy the int into this space, the object now has effective type "int" and can only be accessed as an "int". If your copy function did not copy the type "int" to the new object, then you can still access it as an "int" - it takes its effective type from the access.) > >> The rule that pointers from different objects can't be compared is somewhat >> meaningless. The malloc and free functions need to be able to compare their >> arguments against their heap boundaries, at least. > > I think you mean "realloc", not "malloc". malloc()'s only argument > cannot meaningfully compared with the heap boundaries. > > realloc() and free() don't need to check their arguments against their > heap boundaries - they're entitled to assume that their argument points > into the heap, and to fail catastrophically if that isn't the case. That > fact greatly simplifies their implementation on some systems. Perhaps he means that the argument to malloc needs to be used in expressions that are then compared to the heap boundaries (such as adding it to a pointer to free memory, then comparing that result to the heap boundary). > >> ... And for that to be legal >> for them to do, the heap itself must be a single character array. But if the >> heap *is* a single character array, that means that all pointers returned >> from malloc are actually part of a single object, and thus should be legal >> to compare to each other, regardless of what kind of structure/type the >> caller uses them for. > > The heap need not be a single block of memory - it's entirely feasible > for it to consist of a series of disconnected blocks. On a > segment-offset architecture, the malloc() family could keep a list of > specific segments that they're currently using, and search that list > when needed - they need not be adjacent segments - the concept of > "adjacent segments" need not even be meaningful on that platform. > > Some real world implementations of malloc() round every allocation up to > a power of two, and allocate each power of two from a different memory > pool. This simplifies some of the logic. They can tell what the size of > an allocation is by determining which pool it's from. > >> Meanwhile, on a system where the heap is implemented by something like mmap() >> which can return discontiguous memory regions on subsequent calls, the C spec >> says you're screwed, you can't legally compare the pointers from different >> map regions. Which is utter nonsense. > > This "nonsense" was written because there are real-world machines where > pointers to different blocks of memory cannot be meaningfully give a > total ordering. > (And before we get the usual complaints about "no one has used such dinosaurs in decades", there are current microcontrollers that have multiple independent memory spaces.) >> One of the essential traits of K&R C was that you could implement the language >> in itself. With modern C you can't do that any more. > > You could implement a C compiler in C - that's not quite the same thing. > The C standard library contains many functions, such as fopen(), that do > things that the language itself provides no method of implementing, at > least not in portable code. They are implemented either by writing > non-portable C code, or in some other language, such as assembler. >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-26 08:57 -0400 |
| Message-ID | <q7d7kf$t96$1@dont-email.me> |
| In reply to | #142460 |
On 3/26/19 04:55, David Brown wrote: ... > Can a "my_memcpy" function copy the effective type of an object, in the > way the library "memcpy" does? It looks to me that this will work as > long as "my_memcpy" works by character - but that is looking at C11 > (6.5p6). I don't know if it is the same in earlier standards. In 6.2.6.1p4, the standard only uses memcpy() as an example of how an object's value can be copied, from which I have inferred that any other piece of code with the same defined behavior as memcpy() (copying as an array of unsigned char, in an unspecified order) would be equally effective in making such a copy. 6.5p6 identifies memcpy() and memmove() by name as things that can change the effective type, and says nothing to suggest that there's any other way to perform a byte-by-byte copy that will have the same effect. Copying an entire object of non-character type obviously will work, because it will access the memory using an lvalue of non-character type. I think 6.5p6 should have been worded the same way as 6.2.6.1p4, but it wasn't. I'm not sure if that reflects an actual difference in the committee's intent.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-26 15:22 +0000 |
| Message-ID | <87lg11mzj4.fsf@bsb.me.uk> |
| In reply to | #142468 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: <cut> > 6.5p6 identifies memcpy() and memmove() by name as things that can > change the effective type, and says nothing to suggest that there's any > other way to perform a byte-by-byte copy that will have the same > effect. Hmm... Not my reading of it: "If a value is copied into an object having no declared type using memcpy or memmove, or is copied /as/ an array of character type, then the effective type of the modified object ... is the effective type of the object from which the value is copied..." (text elided for clarity, emphasis mine) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-26 13:10 -0400 |
| Message-ID | <q7dmdl$pja$2@dont-email.me> |
| In reply to | #142473 |
On 3/26/19 11:22, Ben Bacarisse wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > <cut> >> 6.5p6 identifies memcpy() and memmove() by name as things that can >> change the effective type, and says nothing to suggest that there's any >> other way to perform a byte-by-byte copy that will have the same >> effect. > > Hmm... Not my reading of it: > > "If a value is copied into an object having no declared type using > memcpy or memmove, or is copied /as/ an array of character type, then > the effective type of the modified object ... is the effective type of > the object from which the value is copied..." Sorry - I looked for that phrase, didn't notice it, was surprised, looked for it again, and still didn't notice it. I must have been tireder than I thought. I was definitely in a hurry, being late for an appointment.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-25 19:08 +0000 |
| Message-ID | <ZG9mE.763586$RBa.687733@fx15.am4> |
| In reply to | #142376 |
On 24/03/2019 21:55, David Brown wrote: > On 24/03/2019 20:44, Bart wrote: >> On 24/03/2019 17:43, antispam@math.uni.wroc.pl wrote: >>> Bart <bc@freeuk.com> wrote: >> >>> Well, almost any HLL can represent data types used in assembly and >>> you can write code having the same effect as machine level instructions. >> >> I would like to dispute some of that but that is a debate for elsewhere. >> >>>> I called C a trumped-up assembler, which wasn't a criticism; it's just >>>> how I want to use such a language. >>> > > It is a pity for you that C is not such a language. > > On the other hand, none of the tasks you list below have any need of a > "trumped-up assembler". C, assuming you know how to use it, will work > for any of them. (It is a poor choice of language for many of these > tasks, but it will work. And of course it may have been a reasonable > choice at the time.) My point is this: I had a language which was highly adept at dealing with all those tasks, yet it managed that without all the annoying aspects of C, and specifically without having UB where UB is not needed. Ergo, C doesn't need it either. It was just enough of a HLL to have all the advantages of such, without all the problems with assembly. But to deal with bottlenecks, as it wasn't optimising, it had a VERY easy to use inline assembler. (C at the time wasn't optimising either, neither did it work slickly and effortlessly on the hardware I had, from the accounts I heard.) >>> You still did not explain why you want such a thing. I use low >>> level code for: >>> - controling hardware (C is doing this nicely) >>> - getting high speed (again C is doing well here, but sometimes >>> I need assembly) >>> - interfacing to OS (again C) >>> - low level runtime support for higher level languages >>> (C is useful here, but such code may do things impossible >>> to do in C, so down to assembly) >> >> I've used low level code, starting early 80s, for: >> >> - Test programs when developing microprocessor boards: doing i/o, >> writing to controllers, testing memory, etc etc > > As long as you understand "volatile", And it didn't need 'volatile'. If you wrote to memory, then it would write to memory. It could also directly access i/o ports. >> This may help explain a lot of my scepticism. IMO C has created a rod, >> not for its own back, but for all its programmers! > > No, it doesn't explain anything. You have built up an irrational fear > and hatred of C over many years, Tell me, after using my language very successfully for this stuff for 10-15 years (this would me mid-90s), what would C bring to the table? If that is the only choice, as it would be for very many, then you have to use it. And do battle for its over-zealous UB and its hundred and one quirks and compilers that can't make up their mind if your program is valid. (I've had either 0 lines of warnings, or 18,000 lines, for the same program, depending on options.) I've tried to use it (because I no longer wanted to maintain my own language), but it was like switching from my comfortable modern car to a Model T. > but it is very definitely irrational, > and strongly founded in misunderstanding. You firmly believe C to be > something that it is not - something it has never been. So when C or C > tools don't do as you expect, you fear them and blame them. At no point > have you accepted that the problem lies in your misunderstandings. Seriously, what exactly would happen if C decreed that signed overflow wasn't UB? It would just wrap (and give the wrong answers /if/ you expect them to be in range, but it would do something unexpected anyway). And there might be the odd optimisation that it might not do. (Although the ones demonstrated in this thread could also be handled by switching to a 64-bit int.) But imagine not having the burden of that particular set of UB to learn or teach or document or debate or to constantly have in mind. Keep It Simple.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-25 22:24 +0100 |
| Message-ID | <q7bguk$frp$1@dont-email.me> |
| In reply to | #142427 |
On 25/03/2019 20:08, Bart wrote: > On 24/03/2019 21:55, David Brown wrote: >> On 24/03/2019 20:44, Bart wrote: >>> On 24/03/2019 17:43, antispam@math.uni.wroc.pl wrote: >>>> Bart <bc@freeuk.com> wrote: >>> >>>> Well, almost any HLL can represent data types used in assembly and >>>> you can write code having the same effect as machine level >>>> instructions. >>> >>> I would like to dispute some of that but that is a debate for elsewhere. >>> >>>>> I called C a trumped-up assembler, which wasn't a criticism; it's just >>>>> how I want to use such a language. >>>> >> >> It is a pity for you that C is not such a language. >> >> On the other hand, none of the tasks you list below have any need of a >> "trumped-up assembler". C, assuming you know how to use it, will work >> for any of them. (It is a poor choice of language for many of these >> tasks, but it will work. And of course it may have been a reasonable >> choice at the time.) > > My point is this: I had a language which was highly adept at dealing > with all those tasks, yet it managed that without all the annoying > aspects of C, and specifically without having UB where UB is not needed. > > Ergo, C doesn't need it either. C doesn't need "while" or "for" loops. But the language is better for having them. Where you see undefined behaviour as annoying, other people (at least some other people, and in at least some cases) see it as useful. > > It was just enough of a HLL to have all the advantages of such, without > all the problems with assembly. But to deal with bottlenecks, as it > wasn't optimising, it had a VERY easy to use inline assembler. > > (C at the time wasn't optimising either, neither did it work slickly and > effortlessly on the hardware I had, from the accounts I heard.) > > >>>> You still did not explain why you want such a thing. I use low >>>> level code for: >>>> - controling hardware (C is doing this nicely) >>>> - getting high speed (again C is doing well here, but sometimes >>>> I need assembly) >>>> - interfacing to OS (again C) >>>> - low level runtime support for higher level languages >>>> (C is useful here, but such code may do things impossible >>>> to do in C, so down to assembly) >>> >>> I've used low level code, starting early 80s, for: >>> >>> - Test programs when developing microprocessor boards: doing i/o, >>> writing to controllers, testing memory, etc etc >> >> As long as you understand "volatile", > > And it didn't need 'volatile'. If you wrote to memory, then it would > write to memory. It could also directly access i/o ports. If the compiler you used at the time was happy to define the behaviour of such code, then you didn't need "volatile" - as long as you understood you were writing implementation-specific code. (That is usually the case when you would be wanting "volatile" anyway.) Quote from C11 5.1.2.2.2p9: """ EXAMPLE 1 An implementation might define a one-to-one correspondence between abstract and actual semantics: at every sequence point, the values of the actual objects would agree with those specified by the abstract semantics. The keyword volatile would then be redundant. """ The type of C compiler you describe is certainly allowed by the C standards. Your problem lies in thinking that this is the /only/ type of C compiler it allows, or that such compilers are better than optimising ones. (They are "better" only in that if you don't know how to use C, you might still be lucky and get a working program.) > >>> This may help explain a lot of my scepticism. IMO C has created a >>> rod, not for its own back, but for all its programmers! >> >> No, it doesn't explain anything. You have built up an irrational fear >> and hatred of C over many years, > > Tell me, after using my language very successfully for this stuff for > 10-15 years (this would me mid-90s), what would C bring to the table? > > If that is the only choice, as it would be for very many, then you have > to use it. And do battle for its over-zealous UB and its hundred and one > quirks and compilers that can't make up their mind if your program is > valid. (I've had either 0 lines of warnings, or 18,000 lines, for the > same program, depending on options.) > > I've tried to use it (because I no longer wanted to maintain my own > language), but it was like switching from my comfortable modern car to a > Model T. > >> but it is very definitely irrational, and strongly founded in >> misunderstanding. You firmly believe C to be something that it is not >> - something it has never been. So when C or C tools don't do as you >> expect, you fear them and blame them. At no point have you accepted >> that the problem lies in your misunderstandings. > > Seriously, what exactly would happen if C decreed that signed overflow > wasn't UB? It would just wrap (and give the wrong answers /if/ you > expect them to be in range, but it would do something unexpected anyway). I've told you. It would be a worse language, with less efficient tools, and poorer aids for developers. You have spent too long with x86 processors - chips that are excellent at making poor quality code run fast. > > And there might be the odd optimisation that it might not do. (Although > the ones demonstrated in this thread could also be handled by switching > to a 64-bit int.) > > But imagine not having the burden of that particular set of UB to learn > or teach or document or debate or to constantly have in mind. > It's no burden at all. > Keep It Simple. C's handling of signed integers is far simpler than your languages' handling. Imagine trying to teach it to someone who doesn't know about assembly, or the details of how cpus implement arithmetic. And imagine "int" is 16-bit, because the numbers are easier. Let's compare C to "Bart's Language" (you could replace that with Java if you prefer). C Teacher: When you add two numbers in C, make sure they don't go out of range for the type: -32768 to 32767. If you do, C won't give you the right answer. C Pupil: OK. So what happens if I have 32767 in an int, and add 1? C Teacher: It won't work. The number is too big, so C can't give you the right answer. So don't do it. C Pupil: OK. What do I do if I want bigger numbers? C Teacher: Use a larger type, like "long int". C Pupil: OK. BL Teacher: When you add two numbers in C, if they outside the range for the type (-32768 to 32767), the value is reduced modulo 65536. BL Pupil: What? What does "modulo" mean? BL Teacher: It means that numbers wrap. Adding 1 to 32767 gives you -32768. BL Pupil: Why?? What sense does that make? That will be the wrong answer. 32767 + 1 is 32768. BL Teacher: It doesn't matter that the answer is wrong. What is important is that you get the same wrong answer every time. BL Pupil: Now you are taking the piss. You are telling me that if I have 32767 apples in a pile, and put another apple on, I have a /negative/ number of apples? When I have 32767 coins in my piggy bank, if I add another coin, suddenly I'm deeply in debt? What kind of muppet came up with that idea? Yes, I can see why you think your treatment of signed integer overflow is /so/ much simpler than C's.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-25 22:08 +0000 |
| Message-ID | <BjcmE.346006$LG6.53420@fx04.am4> |
| In reply to | #142441 |
On 25/03/2019 21:24, David Brown wrote: > On 25/03/2019 20:08, Bart wrote: >> Ergo, C doesn't need it either. > > C doesn't need "while" or "for" loops. But the language is better for > having them. Those are tremendously useful. Inventing UB to suit compiler writers adds nothing of utility for the programmer, and makes their job harder. For example, they complicate the issues that exist for overflow, and can rule out useful tricks like aliasing with unions. So they are a feature that lets you accomplish less rather than more. >> Keep It Simple. > > C's handling of signed integers is far simpler than your languages' > handling. > > Imagine trying to teach it to someone who doesn't know about assembly, > or the details of how cpus implement arithmetic. And imagine "int" is > 16-bit, because the numbers are easier. Let's compare C to "Bart's > Language" (you could replace that with Java if you prefer). > > > C Teacher: When you add two numbers in C, make sure they don't go out of > range for the type: -32768 to 32767. If you do, C won't give you the > right answer. > > C Pupil: OK. So what happens if I have 32767 in an int, and add 1? > > C Teacher: It won't work. The number is too big, so C can't give you > the right answer. So don't do it. > > C Pupil: OK. What do I do if I want bigger numbers? > > C Teacher: Use a larger type, like "long int". > > C Pupil: OK. Exactly the same dialogue can be my used for my language. And actually, in most cases a compiler will give you exactly the same result as in one of my languages. Two concepts are really needed for these low level languages, one is that fixed-width whole numbers can overflow, or can wrap, a bit like mechanical tape counters, or abacuses, or odometers. The other is the idea of binary twos complement to to represent negative values, which gives a slightly different wrapping behaviour. But when you examine them some more, you realise that signed integers are just unsigned ones, interpreted as signed (same value when top bit is 0, otherwise subtract an offset to get the value). > BL Teacher: When you add two numbers in C, if they outside the range for > the type (-32768 to 32767), the value is reduced modulo 65536. > > BL Pupil: What? What does "modulo" mean? > > BL Teacher: It means that numbers wrap. Adding 1 to 32767 gives you > -32768. > > BL Pupil: Why?? What sense does that make? That will be the wrong > answer. 32767 + 1 is 32768. > > BL Teacher: It doesn't matter that the answer is wrong. What is > important is that you get the same wrong answer every time. > > BL Pupil: Now you are taking the piss. You are telling me that if I > have 32767 apples in a pile, and put another apple on, I have a > /negative/ number of apples? When I have 32767 coins in my piggy bank, > if I add another coin, suddenly I'm deeply in debt? What kind of muppet > came up with that idea? > > > Yes, I can see why you think your treatment of signed integer overflow > is /so/ much simpler than C's. This treatment of signed numbers is EXACTLY the same as C's unsigned numbers; a result above the range is reduced modulo 65536. BTW you forget to mention nasal demons in your C dialogue.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-26 10:20 +0100 |
| Message-ID | <q7cqtm$jfj$1@dont-email.me> |
| In reply to | #142444 |
On 25/03/2019 23:08, Bart wrote: > On 25/03/2019 21:24, David Brown wrote: >> On 25/03/2019 20:08, Bart wrote: > >>> Ergo, C doesn't need it either. >> >> C doesn't need "while" or "for" loops. But the language is better for >> having them. > > Those are tremendously useful. Agreed. > > Inventing UB to suit compiler writers adds nothing of utility for the > programmer, and makes their job harder. For example, they complicate the > issues that exist for overflow, and can rule out useful tricks like > aliasing with unions. > > So they are a feature that lets you accomplish less rather than more. No, UB lets you do /more/, and lets you get more efficient code with less effort, and lets you check mistakes more easily. This, of course, assumes the programmer is capable of understanding UB. It is quite clear that some people manage to resist all information and rational thought on the matter. > >>> Keep It Simple. >> >> C's handling of signed integers is far simpler than your languages' >> handling. >> >> Imagine trying to teach it to someone who doesn't know about assembly, >> or the details of how cpus implement arithmetic. And imagine "int" is >> 16-bit, because the numbers are easier. Let's compare C to "Bart's >> Language" (you could replace that with Java if you prefer). >> >> >> C Teacher: When you add two numbers in C, make sure they don't go out >> of range for the type: -32768 to 32767. If you do, C won't give you >> the right answer. >> >> C Pupil: OK. So what happens if I have 32767 in an int, and add 1? >> >> C Teacher: It won't work. The number is too big, so C can't give you >> the right answer. So don't do it. >> >> C Pupil: OK. What do I do if I want bigger numbers? >> >> C Teacher: Use a larger type, like "long int". >> >> C Pupil: OK. > > Exactly the same dialogue can be my used for my language. And actually, > in most cases a compiler will give you exactly the same result as in one > of my languages. > > Two concepts are really needed for these low level languages, one is > that fixed-width whole numbers can overflow, or can wrap, a bit like > mechanical tape counters, or abacuses, or odometers. > > The other is the idea of binary twos complement to to represent negative > values, which gives a slightly different wrapping behaviour. > > But when you examine them some more, you realise that signed integers > are just unsigned ones, interpreted as signed (same value when top bit > is 0, otherwise subtract an offset to get the value). Whoosh! Do you hear that sound? It is my point flying /way/ over your head. The C rule is simple - don't overflow your integer calculations. There is no need to learn about two's complement or anything else about the low-level implementation details. The idea of normal arithmetic, with limits, is ingrained in people since early kids school. For people who will be working with very low level code on specific implementations, you might need to learn about two's complement and integer representation. But that's an advanced topic for later. Remember, people learning to program now do not usually do so in the order /you/ learned. You learned assembly, then moved towards other languages and C - you try to fit the other languages into your assembly concepts. Most people don't learn in that direction. Sometimes this can mean it is hard to understand what other people find easy or difficult. (I have the same challenges myself.) > >> BL Teacher: When you add two numbers in C, if they outside the range >> for the type (-32768 to 32767), the value is reduced modulo 65536. >> >> BL Pupil: What? What does "modulo" mean? >> >> BL Teacher: It means that numbers wrap. Adding 1 to 32767 gives you >> -32768. >> >> BL Pupil: Why?? What sense does that make? That will be the wrong >> answer. 32767 + 1 is 32768. >> >> BL Teacher: It doesn't matter that the answer is wrong. What is >> important is that you get the same wrong answer every time. >> >> BL Pupil: Now you are taking the piss. You are telling me that if I >> have 32767 apples in a pile, and put another apple on, I have a >> /negative/ number of apples? When I have 32767 coins in my piggy >> bank, if I add another coin, suddenly I'm deeply in debt? What kind >> of muppet came up with that idea? >> >> >> Yes, I can see why you think your treatment of signed integer overflow >> is /so/ much simpler than C's. > > This treatment of signed numbers is EXACTLY the same as C's unsigned > numbers; a result above the range is reduced modulo 65536. > Yes, and you'd get there when teaching programming using C. But you'd get to unsigned behaviour a good deal later than for basic "int" arithmetic. And modulo behaviour for /unsigned/ types is easy to understand - it's just like a 24 hour clock. It's the wrapping from large positive to large negative numbers that is particularly weird and counter-intuitive. > BTW you forget to mention nasal demons in your C dialogue. Yes. There is no need to mention them. It is enough to say "don't do that" - you don't need to say what will happen if you break the rules.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-26 11:58 +0000 |
| Message-ID | <RtomE.856895$Apg.145853@fx36.am4> |
| In reply to | #142461 |
On 26/03/2019 09:20, David Brown wrote:
> On 25/03/2019 23:08, Bart wrote:
>> But when you examine them some more, you realise that signed integers
>> are just unsigned ones, interpreted as signed (same value when top bit
>> is 0, otherwise subtract an offset to get the value).
>
> Whoosh!
>
> Do you hear that sound? It is my point flying /way/ over your head.
>
> The C rule is simple - don't overflow your integer calculations.
That is far too simplistic. Like saying, don't write code with any bugs.
There
> is no need to learn about two's complement or anything else about the
> low-level implementation details. The idea of normal arithmetic, with
> limits, is ingrained in people since early kids school.
Remember the Y2K problem (which involved UNSIGNED overflow actually, the
one that C says can't happen). Remember the 2038 problem (well that
might still be in the future), which was signed 32-bit? Remember when
the viewing numbers for a certain youtube video overflowed the capacity
of the 32-bit signed int they were using? No nasal demons, just the
wrong results.
Lots of people don't seen to have followed your advice. Overflow is
going to happen.
> For people who will be working with very low level code on specific
> implementations, you might need to learn about two's complement and
> integer representation. But that's an advanced topic for later.
People masochistic enough to be coding in C will be working at low
level. They need to know this stuff.
They might also like to know why C doesn't care about unsigned overflow
- you can do that with impunity - but dare to have signed overflow and
the world might as well come to end.
Why is that? 'Because C says so' is not an answer. They will want to
know why C in particular is infamous for its nearly 200 UB behaviours,
and especially harmless ones like overflow.
> Remember, people learning to program now do not usually do so in the
> order /you/ learned. You learned assembly,
I was taught Algol, Fortran and Cobol before assembly. I didn't try C at
all until much later after 15 years of systems programming NOT using C.
> Yes, and you'd get there when teaching programming using C. But you'd
> get to unsigned behaviour a good deal later than for basic "int"
> arithmetic. And modulo behaviour for /unsigned/ types is easy to
> understand - it's just like a 24 hour clock. It's the wrapping from
> large positive to large negative numbers that is particularly weird and
> counter-intuitive.
Unsigned wrapping can be counter-intuitive too. Imagine your new car
(not a modern one) has 0 miles on the clock. You drive it forwards and
it gets to 1 mile then 2 miles, so you are two miles from where you
started from.
Now you drive it backwards for 3 miles (it helps to have seen Ferris
Bueller's Day Off). You are now 1 mile from your start point, in the
opposite direction. However it will most likely now display 99999 or
999999 miles, not -1.
Let's try this experiment on x86:
mov eax, 0x7FFFFFFF
add eax, 1
This results in eax containing 0x80000000. Is this overflow? Is it
undefined behaviour? Will this in itself cause the hard drive to be
formatted?
The answers are in order: (1) Only if YOU consider the values to signed;
(2) Only if C was additionally used to generate that code; (3) Only if a
particularly aggressive C compiler was involved.
The actual operation itself however is completely harmless (it sets the
OV flag on the x86). That is why C's claim of UB in this case is BS.
How can those same two instructions be harmless when generated by
anything other than a C compiler, but UB with a C compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-26 16:49 +0100 |
| Message-ID | <q7dhle$pru$1@dont-email.me> |
| In reply to | #142467 |
On 26/03/2019 12:58, Bart wrote: > On 26/03/2019 09:20, David Brown wrote: >> On 25/03/2019 23:08, Bart wrote: > >>> But when you examine them some more, you realise that signed integers >>> are just unsigned ones, interpreted as signed (same value when top bit >>> is 0, otherwise subtract an offset to get the value). >> >> Whoosh! >> >> Do you hear that sound? It is my point flying /way/ over your head. >> >> The C rule is simple - don't overflow your integer calculations. > > That is far too simplistic. Like saying, don't write code with any bugs. > No, it is not. It is like saying, "Try to write code that makes sense". You seem to be under the impression that integer overflow is only a problem with C's undefined behaviour. That is completely incorrect. A bug is a bug, regardless of the behaviour. If your integers overflow (except for /very/ rare use-cases), your code is buggy. You try to avoid the situation, and if it occurs, you find and fix it. C's treatment of integer overflow makes that easier than in your language. I really can't understand why anyone would want anything different. > There >> is no need to learn about two's complement or anything else about the >> low-level implementation details. The idea of normal arithmetic, with >> limits, is ingrained in people since early kids school. > > Remember the Y2K problem (which involved UNSIGNED overflow actually, the > one that C says can't happen). Yes, it's a bug. Overflow - unsigned or not - is usually a bug. (I've said before that I think it would be advantageous if unsigned arithmetic overflow was also undefined behaviour, though wrapping is less bad here than for signed arithmetic. And you still do need /some/ way to get wrapping for the rare occasions that you need it.) > Remember the 2038 problem (well that > might still be in the future), which was signed 32-bit? Remember when > the viewing numbers for a certain youtube video overflowed the capacity > of the 32-bit signed int they were using? No nasal demons, just the > wrong results. Yes, I know the 2038 problem. Exactly /how/ is it good that some systems will move from the year 2038 to the year 1901 (if I have my numbers right) ? Making the overflow undefined behaviour does not in any way fix the problem - but making it /defined/ behaviour does not help in any way either. > > Lots of people don't seen to have followed your advice. Overflow is > going to happen. Yes, bugs happen - most big software has bugs (at the very least, it has bugs of design or specification, even if the implementation and coding is perfect). What is your point? Do you think that if signed integer overflow were defined behaviour, there would be no bug? Do you think "avoid this error when writing software" is bad advice? Do you think there is /any/ advice about signed integer overflow that is better than "don't do it" ? > >> For people who will be working with very low level code on specific >> implementations, you might need to learn about two's complement and >> integer representation. But that's an advanced topic for later. > > People masochistic enough to be coding in C will be working at low > level. They need to know this stuff. > That's just nonsense. People are masochistic enough to program all sorts of stuff in C, including lots of things that would be better done in other languages. A great deal of C is written to get a balance between efficiency and portability, not for low level code, and the details of integer representation will generally not come up. Certainly overflow will not be needed. > They might also like to know why C doesn't care about unsigned overflow > - you can do that with impunity - but dare to have signed overflow and > the world might as well come to end. > They might - so you can explain it. I've given you answers and comments about it before. > Why is that? 'Because C says so' is not an answer. They will want to > know why C in particular is infamous for its nearly 200 UB behaviours, > and especially harmless ones like overflow. The answer is that C is a little clearer and more direct about it than other languages - /all/ languages have undefined behaviour. And in particular, any bug in any program is undefined behaviour in that the code is not doing something defined by the programmer's intentions. C does not have run-time checking, and expects programmers to take responsibility. That is all you need to know about UB, unless you are perverse enough to want to fight your compiler, language and tools instead of using them. > >> Remember, people learning to program now do not usually do so in the >> order /you/ learned. You learned assembly, > > I was taught Algol, Fortran and Cobol before assembly. I didn't try C at > all until much later after 15 years of systems programming NOT using C. > Fortran has more UB than C. >> Yes, and you'd get there when teaching programming using C. But you'd >> get to unsigned behaviour a good deal later than for basic "int" >> arithmetic. And modulo behaviour for /unsigned/ types is easy to >> understand - it's just like a 24 hour clock. It's the wrapping from >> large positive to large negative numbers that is particularly weird and >> counter-intuitive. > > Unsigned wrapping can be counter-intuitive too. Imagine your new car > (not a modern one) has 0 miles on the clock. You drive it forwards and > it gets to 1 mile then 2 miles, so you are two miles from where you > started from. I agree that it is counter-intuitive - just less so than for signed arithmetic. Imagine you zero the trip counter in your car, then drive 9,999 km (or miles). After the next km it will wrap to 0. People can handle that. Imagine now that it wrapped from 4,999 km to -5,000 km. Can you comprehend the difference? > > Now you drive it backwards for 3 miles (it helps to have seen Ferris > Bueller's Day Off). You are now 1 mile from your start point, in the > opposite direction. However it will most likely now display 99999 or > 999999 miles, not -1. > > Let's try this experiment on x86: > > mov eax, 0x7FFFFFFF > add eax, 1 > > This results in eax containing 0x80000000. Is this overflow? Is it > undefined behaviour? Will this in itself cause the hard drive to be > formatted? > > The answers are in order: (1) Only if YOU consider the values to signed; > (2) Only if C was additionally used to generate that code; (3) Only if a > particularly aggressive C compiler was involved. > > The actual operation itself however is completely harmless (it sets the > OV flag on the x86). That is why C's claim of UB in this case is BS. > > How can those same two instructions be harmless when generated by > anything other than a C compiler, but UB with a C compiler. C is not x86 assembly.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-26 16:23 +0000 |
| Message-ID | <imsmE.166642$pP5.25292@fx01.am4> |
| In reply to | #142475 |
On 26/03/2019 15:49, David Brown wrote: > On 26/03/2019 12:58, Bart wrote: >> On 26/03/2019 09:20, David Brown wrote: >>> On 25/03/2019 23:08, Bart wrote: >> >>>> But when you examine them some more, you realise that signed integers >>>> are just unsigned ones, interpreted as signed (same value when top bit >>>> is 0, otherwise subtract an offset to get the value). >>> >>> Whoosh! >>> >>> Do you hear that sound? It is my point flying /way/ over your head. >>> >>> The C rule is simple - don't overflow your integer calculations. >> >> That is far too simplistic. Like saying, don't write code with any bugs. >> > > No, it is not. It is like saying, "Try to write code that makes sense". > > You seem to be under the impression that integer overflow is only a > problem with C's undefined behaviour. That is completely incorrect. A > bug is a bug, regardless of the behaviour. This is exactly what I've been saying. It's just a bug - probably. You don't need UB on top, or a compiler deciding your program cannot possibly have that specific bug, and ends up doing not only totally unexpected things, but differently from 9 out of 10 other C compilers. >> Let's try this experiment on x86: >> >> mov eax, 0x7FFFFFFF >> add eax, 1 >> >> This results in eax containing 0x80000000. Is this overflow? Is it >> undefined behaviour? Will this in itself cause the hard drive to be >> formatted? > C is not x86 assembly. Nevertheless this is the kind of operation people will want to do, with the same semantics, and the same behaviour on overflow. If it doesn't overflow, fine. If it does, then it wraps around like it does most other languages of this level, and even most other C compilers.
[toc] | [prev] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2019-03-26 13:24 -0400 |
| Message-ID | <44mulhzgzp.fsf@be-well.ilk.org> |
| In reply to | #142475 |
David Brown <david.brown@hesbynett.no> writes: > Yes, it's a bug. Overflow - unsigned or not - is usually a bug. (I've > said before that I think it would be advantageous if unsigned arithmetic > overflow was also undefined behaviour, though wrapping is less bad here > than for signed arithmetic. And you still do need /some/ way to get > wrapping for the rare occasions that you need it.) In my experience, unsigned integer overflow is almost never a bug. My experience involves working with a lot of hardware counters that wrap exactly the same way that C requires of unsigned integers. In the (vastly unlikely, but hypothetically possible) case that some future version of C changed unsigned overflow into undefined behaviour, I would have to write macros or inline functions that mimic the currently defined behaviour, and then go add them in at most arithmetic operations on unsigned integers. -- Lowell Gilbert, embedded/networking software engineer http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-03-26 10:31 -0700 |
| Message-ID | <208bbca4-56fa-445e-a780-6032b9685c51@googlegroups.com> |
| In reply to | #142480 |
On Tuesday, 26 March 2019 17:24:18 UTC, Lowell Gilbert wrote: > David Brown <david.brown@hesbynett.no> writes: > > > Yes, it's a bug. Overflow - unsigned or not - is usually a bug. (I've > > said before that I think it would be advantageous if unsigned arithmetic > > overflow was also undefined behaviour, though wrapping is less bad here > > than for signed arithmetic. And you still do need /some/ way to get > > wrapping for the rare occasions that you need it.) > > In my experience, unsigned integer overflow is almost never a bug. My > experience involves working with a lot of hardware counters that wrap > exactly the same way that C requires of unsigned integers. In the > (vastly unlikely, but hypothetically possible) case that some future > version of C changed unsigned overflow into undefined behaviour, I would > have to write macros or inline functions that mimic the currently > defined behaviour, and then go add them in at most arithmetic operations > on unsigned integers. > Unsigned overflow can be used to implement wider types. However C has most of the routines you want built in to the type system, so you don't need to implement 32 bit integers on a 16 bit system.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-03-26 13:03 -0500 |
| Message-ID | <gbpk9etm9j3t0ji3cfj758fna9jlgsm26f@4ax.com> |
| In reply to | #142475 |
On Tue, 26 Mar 2019 16:49:01 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 26/03/2019 12:58, Bart wrote: >> Remember the 2038 problem (well that >> might still be in the future), which was signed 32-bit? Remember when >> the viewing numbers for a certain youtube video overflowed the capacity >> of the 32-bit signed int they were using? No nasal demons, just the >> wrong results. > >Yes, I know the 2038 problem. Exactly /how/ is it good that some >systems will move from the year 2038 to the year 1901 (if I have my >numbers right) ? Making the overflow undefined behaviour does not in >any way fix the problem - but making it /defined/ behaviour does not >help in any way either. The 32-bit Unix time base is January 1, 1970, and it will roll to a negative number in 2038, to roughly December 13, 1901 (if something actually successfully processes that as a negative number of seconds from the base time). You may be thinking of the 2042 problem, where the (unsigned) 64-bit S/370 time-of-day clock (units of 1/4096 microseconds) rolls over back to January 1, 1900 (which is the standard base for that system). Somewhat oddly, the time-of-day clock rolled to a "negative" number a few months after the first S/370s shipped. I've often wondered if the hardware guys did a clock with a 142 year period, figuring that it would almost certainly be enough to never worry about again, only to have the OS guys promptly throw half the range away.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-26 11:53 -0700 |
| Message-ID | <ln5zs5bh72.fsf@kst-u.example.com> |
| In reply to | #142482 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> The 32-bit Unix time base is January 1, 1970, and it will roll to a
> negative number in 2038, to roughly December 13, 1901 (if something
> actually successfully processes that as a negative number of seconds
> from the base time).
On most 32-bit Unix-like systems that are still running in 2038,
the clock will roll back to December 13, 1901 (in the absence of
any fixes). But neither C nor POSIX mandates this behavior.
C says only that time_t is a real (integer or floating-point) type
capable of representing times. It says nothing about the meaning of
(time_t)0, the epoch, resolution, or even that it's monotonic.
POSIX requires time_t to be an integer type and says that time()
returns "the value of time in seconds since the Epoch", which it
defines as January 1, 1970. It says that time() *may* fail, and
set errno to EOVERFLOW, if the time will not fit in an object of
type time_t.
Implementations in which time_t is a 32-bit signed integer (many
historical implementations) fail in the year 2038. POSIX.1-2017
does not address this problem.
The obvious solution (for UNIX-like systems, at least) is to make
time_t a signed 64-bit integer, even on 32-bit systems.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-03-26 19:59 +0000 |
| Message-ID | <IwvmE.165344$W44.105974@fx26.iad> |
| In reply to | #142485 |
Keith Thompson <kst-u@mib.org> writes:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>[...]
>> The 32-bit Unix time base is January 1, 1970, and it will roll to a
>> negative number in 2038, to roughly December 13, 1901 (if something
>> actually successfully processes that as a negative number of seconds
>> from the base time).
>
>On most 32-bit Unix-like systems that are still running in 2038,
>the clock will roll back to December 13, 1901 (in the absence of
>any fixes). But neither C nor POSIX mandates this behavior.
>
>C says only that time_t is a real (integer or floating-point) type
>capable of representing times. It says nothing about the meaning of
>(time_t)0, the epoch, resolution, or even that it's monotonic.
>
>POSIX requires time_t to be an integer type and says that time()
>returns "the value of time in seconds since the Epoch", which it
>defines as January 1, 1970. It says that time() *may* fail, and
>set errno to EOVERFLOW, if the time will not fit in an object of
>type time_t.
>
> Implementations in which time_t is a 32-bit signed integer (many
> historical implementations) fail in the year 2038. POSIX.1-2017
> does not address this problem.
>
>The obvious solution (for UNIX-like systems, at least) is to make
>time_t a signed 64-bit integer, even on 32-bit systems.
It may seem obvious, but it likely would have performance implications
given the frequency (pun intended) of time_t usage in the kernel. Better
to just go with 64-bit UNIX{-like} systems now, which most people have already
done.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-27 09:24 +1300 |
| Message-ID | <gfvg3rFar11U6@mid.individual.net> |
| In reply to | #142487 |
On 27/03/2019 08:59, Scott Lurndal wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>> [...]
>>> The 32-bit Unix time base is January 1, 1970, and it will roll to a
>>> negative number in 2038, to roughly December 13, 1901 (if something
>>> actually successfully processes that as a negative number of seconds
>>> from the base time).
>>
>> On most 32-bit Unix-like systems that are still running in 2038,
>> the clock will roll back to December 13, 1901 (in the absence of
>> any fixes). But neither C nor POSIX mandates this behavior.
>>
>> C says only that time_t is a real (integer or floating-point) type
>> capable of representing times. It says nothing about the meaning of
>> (time_t)0, the epoch, resolution, or even that it's monotonic.
>>
>> POSIX requires time_t to be an integer type and says that time()
>> returns "the value of time in seconds since the Epoch", which it
>> defines as January 1, 1970. It says that time() *may* fail, and
>> set errno to EOVERFLOW, if the time will not fit in an object of
>> type time_t.
>>
>> Implementations in which time_t is a 32-bit signed integer (many
>> historical implementations) fail in the year 2038. POSIX.1-2017
>> does not address this problem.
>>
>> The obvious solution (for UNIX-like systems, at least) is to make
>> time_t a signed 64-bit integer, even on 32-bit systems.
>
> It may seem obvious, but it likely would have performance implications
> given the frequency (pun intended) of time_t usage in the kernel. Better
> to just go with 64-bit UNIX{-like} systems now, which most people have already
> done.
The are probably millions of embedded 32 ARM Linux systems out there and
still on the drawing board many of which will still be running in 20
years time!
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-03-26 20:54 +0000 |
| Message-ID | <gkwmE.84773$e54.7917@fx09.iad> |
| In reply to | #142489 |
Ian Collins <ian-news@hotmail.com> writes:
> Thunderbird/60.5.1
>In-Reply-To: <IwvmE.165344$W44.105974@fx26.iad>
>Content-Language: en-US
>X-Received-Bytes: 3165
>X-Received-Body-CRC: 2836696427
>
>On 27/03/2019 08:59, Scott Lurndal wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>> [...]
>>>> The 32-bit Unix time base is January 1, 1970, and it will roll to a
>>>> negative number in 2038, to roughly December 13, 1901 (if something
>>>> actually successfully processes that as a negative number of seconds
>>>> from the base time).
>>>
>>> On most 32-bit Unix-like systems that are still running in 2038,
>>> the clock will roll back to December 13, 1901 (in the absence of
>>> any fixes). But neither C nor POSIX mandates this behavior.
>>>
>>> C says only that time_t is a real (integer or floating-point) type
>>> capable of representing times. It says nothing about the meaning of
>>> (time_t)0, the epoch, resolution, or even that it's monotonic.
>>>
>>> POSIX requires time_t to be an integer type and says that time()
>>> returns "the value of time in seconds since the Epoch", which it
>>> defines as January 1, 1970. It says that time() *may* fail, and
>>> set errno to EOVERFLOW, if the time will not fit in an object of
>>> type time_t.
>>>
>>> Implementations in which time_t is a 32-bit signed integer (many
>>> historical implementations) fail in the year 2038. POSIX.1-2017
>>> does not address this problem.
>>>
>>> The obvious solution (for UNIX-like systems, at least) is to make
>>> time_t a signed 64-bit integer, even on 32-bit systems.
>>
>> It may seem obvious, but it likely would have performance implications
>> given the frequency (pun intended) of time_t usage in the kernel. Better
>> to just go with 64-bit UNIX{-like} systems now, which most people have already
>> done.
>
>The are probably millions of embedded 32 ARM Linux systems out there and
>still on the drawing board many of which will still be running in 20
>years time!
I suspect they'll all support ARMv8 by then.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-27 09:58 +1300 |
| Message-ID | <gfvi3pFar11U8@mid.individual.net> |
| In reply to | #142494 |
On 27/03/2019 09:54, Scott Lurndal wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Thunderbird/60.5.1
>> In-Reply-To: <IwvmE.165344$W44.105974@fx26.iad>
>> Content-Language: en-US
>> X-Received-Bytes: 3165
>> X-Received-Body-CRC: 2836696427
>>
>> On 27/03/2019 08:59, Scott Lurndal wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>> [...]
>>>>> The 32-bit Unix time base is January 1, 1970, and it will roll to a
>>>>> negative number in 2038, to roughly December 13, 1901 (if something
>>>>> actually successfully processes that as a negative number of seconds
>>>>> from the base time).
>>>>
>>>> On most 32-bit Unix-like systems that are still running in 2038,
>>>> the clock will roll back to December 13, 1901 (in the absence of
>>>> any fixes). But neither C nor POSIX mandates this behavior.
>>>>
>>>> C says only that time_t is a real (integer or floating-point) type
>>>> capable of representing times. It says nothing about the meaning of
>>>> (time_t)0, the epoch, resolution, or even that it's monotonic.
>>>>
>>>> POSIX requires time_t to be an integer type and says that time()
>>>> returns "the value of time in seconds since the Epoch", which it
>>>> defines as January 1, 1970. It says that time() *may* fail, and
>>>> set errno to EOVERFLOW, if the time will not fit in an object of
>>>> type time_t.
>>>>
>>>> Implementations in which time_t is a 32-bit signed integer (many
>>>> historical implementations) fail in the year 2038. POSIX.1-2017
>>>> does not address this problem.
>>>>
>>>> The obvious solution (for UNIX-like systems, at least) is to make
>>>> time_t a signed 64-bit integer, even on 32-bit systems.
>>>
>>> It may seem obvious, but it likely would have performance implications
>>> given the frequency (pun intended) of time_t usage in the kernel. Better
>>> to just go with 64-bit UNIX{-like} systems now, which most people have already
>>> done.
>>
>> The are probably millions of embedded 32 ARM Linux systems out there and
>> still on the drawing board many of which will still be running in 20
>> years time!
>
> I suspect they'll all support ARMv8 by then.
Cost. We've had 32 micros for 40 odd years but more embedded systems
still use 8 and 16 bit micros due to cost. 32 bit ARMs will be the 8
bit MCUs of 2038 :)
--
Ian.
[toc] | [prev] | [next] | [standalone]
Page 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web