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 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-23 18:12 +0100 |
| Message-ID | <q75pe2$2bv$1@dont-email.me> |
| In reply to | #142253 |
On 22/03/2019 19:46, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 22/03/2019 13:26, David Brown wrote: >>> On 22/03/2019 12:39, Bart wrote: >>> It is absolutely fine to have an operation whose result is sensible and >>> defined when interpreted as one type, and not sensible, valid or defined >>> when interpreted as another type. >> >> At what point would it generate nasal daemons? > > (Demons, not daemons.) > This is off topic, but your comment inspired me to look up the difference, which I had assumed was just a difference in spelling - and I have used the two words incorrectly. It turns out that "demons" are "evil spirits" (derived from Latin), while "daemons" are "good spirits" (derived from Greek). Presumably the two words have a common origin going back further, but that is their difference in modern English. So "nasal demons" is the correct term here. (Of course, undefined behaviour in C could also lead to launching nasal daemons, but that would not be as objectionable.) So I for one have learned something useful in this thread!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-23 13:00 -0700 |
| Message-ID | <lnlg15e4yw.fsf@kst-u.example.com> |
| In reply to | #142297 |
David Brown <david.brown@hesbynett.no> writes:
> On 22/03/2019 19:46, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 22/03/2019 13:26, David Brown wrote:
>>>> On 22/03/2019 12:39, Bart wrote:
>>>> It is absolutely fine to have an operation whose result is sensible and
>>>> defined when interpreted as one type, and not sensible, valid or defined
>>>> when interpreted as another type.
>>>
>>> At what point would it generate nasal daemons?
>>
>> (Demons, not daemons.)
>
> This is off topic, but your comment inspired me to look up the
> difference, which I had assumed was just a difference in spelling - and
> I have used the two words incorrectly.
>
> It turns out that "demons" are "evil spirits" (derived from Latin),
> while "daemons" are "good spirits" (derived from Greek). Presumably the
> two words have a common origin going back further, but that is their
> difference in modern English.
[...]
The distinction I intended to make is that "demons" are spirits, and
"daemons" are background processes on UNIX-like operating systems.
(I hadn't known about the apparent distinction between "demon" and
"daemon" as different kinds of spirits. According to dictionary.com,
a secondary meaning of "daemon" is simply "demon", and both words
are derived from Latin, which got them from Greek. Apparently the
derivations are not identical, but that's *completely* off-topic.)
I believe the term "nasal demons" is intended to refer to spirits
(probably evil) flying out of your nose -- i.e., something that's
not physically possible but is not forbidden by the standard.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 22:27 +0100 |
| Message-ID | <q78snl$7uk$1@dont-email.me> |
| In reply to | #142311 |
On 23/03/2019 21:00, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 22/03/2019 19:46, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 22/03/2019 13:26, David Brown wrote: >>>>> On 22/03/2019 12:39, Bart wrote: >>>>> It is absolutely fine to have an operation whose result is sensible and >>>>> defined when interpreted as one type, and not sensible, valid or defined >>>>> when interpreted as another type. >>>> >>>> At what point would it generate nasal daemons? >>> >>> (Demons, not daemons.) >> >> This is off topic, but your comment inspired me to look up the >> difference, which I had assumed was just a difference in spelling - and >> I have used the two words incorrectly. >> >> It turns out that "demons" are "evil spirits" (derived from Latin), >> while "daemons" are "good spirits" (derived from Greek). Presumably the >> two words have a common origin going back further, but that is their >> difference in modern English. > [...] > > The distinction I intended to make is that "demons" are spirits, and > "daemons" are background processes on UNIX-like operating systems. > > (I hadn't known about the apparent distinction between "demon" and > "daemon" as different kinds of spirits. According to dictionary.com, > a secondary meaning of "daemon" is simply "demon", and both words > are derived from Latin, which got them from Greek. Apparently the > derivations are not identical, but that's *completely* off-topic.) > I don't think there is any real authoritative reference for this kind of thing, and certainly in some cases "daemon" and "demon" (and "daimon", and "dæmon") are just alternative spellings. But the good spirit / evil spirit reference does match well with the "nasal demons" and "unix daemons" spellings. Mind you, having the "systemd" daemon fly out your nose does not sound much fun either... > I believe the term "nasal demons" is intended to refer to spirits > (probably evil) flying out of your nose -- i.e., something that's > not physically possible but is not forbidden by the standard. > Yes.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-23 23:34 +0000 |
| Message-ID | <uozlE.154825$MT2.27483@fx21.am4> |
| In reply to | #142253 |
On 22/03/2019 18:46, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> So what language is? (I don't count HLAs here.) > Here's the difference. An assembly language program specifies > a sequence of CPU instructions. The behavior of the resulting > sequence is specified by the CPU, not by the assembler. A C program > specifies behavior. > > C is lower level than many other languages, and higher level > assembly language. I suppose you could, by stretching the point, > say that C is "one level up" from assembly language. But there is a > tremendous gulf between languages that specify CPU instructions and > languages that specify behavior, and it's clear which side C is on. I said I didn't count HLAs, but here's one such example from the 1970s: https://en.wikipedia.org/wiki/Babbage_(programming_language) (A version of this I actually implemented for pdp10 as a college project. After bootstrapping, it was implemented in itself. The language however has long disappeared.) This doesn't specify individual instructions, but it can refer to registers by name (although I remember little else about it). That makes it somewhat lower level than what I had in mind. What I'm really getting at is taking the same primitive data types that can be used in assembly, the same ways of organising them, the same operations on them, and being able to write programs that do that in a recognisably high level, structured syntax. This HLL can add a type system, some extra operations (eg. double width arithmetic generating multiple instructions), all the things that can make writing programs much quicker, more easily, more readable, less error prone and more fun. And, with the right HLL, more portable (although also slower without optimising compilers). Now such a language as I've described, can match several actual languages including C. But my complaint was that C seems to want to go beyond that, especially with all these fancy notions of 'undefined behaviour' which the poor guy who just wants an easier, more productive language than ASM, isn't interested in. I called C a trumped-up assembler, which wasn't a criticism; it's just how I want to use such a language.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-03-24 17:43 +0000 |
| Message-ID | <q78fku$7qn$1@z-news.wcss.wroc.pl> |
| In reply to | #142324 |
Bart <bc@freeuk.com> wrote:
> On 22/03/2019 18:46, Keith Thompson wrote:
> > Bart <bc@freeuk.com> writes:
>
> >> So what language is? (I don't count HLAs here.)
>
> > Here's the difference. An assembly language program specifies
> > a sequence of CPU instructions. The behavior of the resulting
> > sequence is specified by the CPU, not by the assembler. A C program
> > specifies behavior.
> >
> > C is lower level than many other languages, and higher level
> > assembly language. I suppose you could, by stretching the point,
> > say that C is "one level up" from assembly language. But there is a
> > tremendous gulf between languages that specify CPU instructions and
> > languages that specify behavior, and it's clear which side C is on.
>
> I said I didn't count HLAs, but here's one such example from the 1970s:
>
> https://en.wikipedia.org/wiki/Babbage_(programming_language)
>
> (A version of this I actually implemented for pdp10 as a college
> project. After bootstrapping, it was implemented in itself. The language
> however has long disappeared.)
>
> This doesn't specify individual instructions, but it can refer to
> registers by name (although I remember little else about it). That makes
> it somewhat lower level than what I had in mind.
>
> What I'm really getting at is taking the same primitive data types that
> can be used in assembly, the same ways of organising them, the same
> operations on them, and being able to write programs that do that in a
> recognisably high level, structured syntax.
Well, almost any HLL can represent data types used in assembly and
you can write code having the same effect as machine level instructions.
If language allows user defined operators (like C++) you can
use those operations as they were primitive. And with decent
optimizer they will translate to small number (frequently one
or zero) machine instructions. Some HLL (like Java) will stash
some extra data that is invisible when you stay in the language,
but shows up when you examine memory content. With C++ (using
implementation defined features) you can write program in such
a way that there is no such extra data: data structures will
contain exacly what you specified and nothing more. You can
get most of this with C, but syntax will be more ugly, you
will need to write things like:
int32_t x = (int32_t)(((uint32_t)y) + ((unit32_t)z));
to get 32-bit 2-complement addition. If you want assembly
for machine with 19-bit words you can replace the above by
int19 x = (int19)(0x7ffff & (((uint32_t)y) + ((unit32_t)z)));
The point is, using unsigned arithmetic (or extended precision)
and bit operations you can get whatever kind of operations
you need. And if your HLL have decent optimizer and operation
of abstract assembly machine are resonably close to real (target)
machine you can expect simple target code.
> This HLL can add a type system, some extra operations (eg. double width
> arithmetic generating multiple instructions), all the things that can
> make writing programs much quicker, more easily, more readable, less
> error prone and more fun.
>
> And, with the right HLL, more portable (although also slower without
> optimising compilers).
Here you have snippet of output of compiler that uses low level
stack machine as intermediate representation:
xc_isuppercode:
/ M_CREATE_SF [8] 0 0 0 [] <ident 256>
pushq %r8
movq $c_isuppercode, %rbp
pushq %rbp
/ M_LABEL _L5
_L5:
/ M_MOVE {rbx <true>} r8
movq (%rbx), %r8
/ M_BIT 2 r8 EQ _L1
testq $2, %r8
leaq 8(%rbx), %rbx
je _L1
/ M_ASH -2 r8 r8
sarq $2, %r8
/ M_CMP 16777215 r8 ULT _L1
cmpq $16777215, %r8
ja _L1
/ M_BIM 65535 r8 r8
andq $65535, %r8
.....
Note:
- each abstract machine instruction translates to resonably
predictable sequence of x86_64 instructions (the M_...
stuff in comments gives you abstract machine instructions)
- the sequence of abstract machine instruction is derived
in rather strightforward way from HLL code using infix
syntax (but stack is still visible in higher level,
different HLL using the same lower level tachnology could
hide stack).
- the code is quite inefficient (and ARM output is much
worse than the above...).
- some instruction are to make sure that runtime support
sees well-formed data structure in memory (this is low
end of system that offers some quite high-level features
at the other end).
>
> Now such a language as I've described, can match several actual
> languages including C. But my complaint was that C seems to want to go
> beyond that, especially with all these fancy notions of 'undefined
> behaviour' which the poor guy who just wants an easier, more productive
> language than ASM, isn't interested in.
>
> I called C a trumped-up assembler, which wasn't a criticism; it's just
> how I want to use such a language.
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)
Generaly, I see little space for something between C and assembly.
Namely, when speed is not an issue than desired effect can by
obtained in HLL (possibly calling to C for hardware/OS things).
When speed is an issue, then good optimizer is a must and
with modern technology going lower level interferes with
optimization. So I my wish higher level than C. At lower
level I may wish fancier macros in assembler, but that is
all: in such case I need control that only real assembler
can give.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-24 19:44 +0000 |
| Message-ID | <x6RlE.311897$7F3.31387@fx30.am4> |
| In reply to | #142360 |
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. > > 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 - Firmware (boot code/monitor code) for microcomputers - Text and graphics display drivers - Basic graphics libraries - Frame grabbing - Basic image processing - 3D graphics - Software floating point - Maths libraries - Text editors - Assemblers - Compilers (a few of these) - Linkers - Interpreters - Printer and plotter drivers - Interfacing to mice, and [digitising] tablets - Whole applications (mainly low-end 2D and 3D CAD) - GUI libraries - Arbitrary precision arithmetic - File format conversion (read/write image files, dxf, eps, 3ds etc) - Later interfacing to OSes like you, and to 3rd party APIs - etc In early days of using bare microprocessor board, I has to use binary machine code. Then I moved on to assembly (and using an actual keyboard and screen editor), and /then/ on to using a primitive HLL, but one I would still class as a proper HLL. That was a luxury! None of this involved C, and it never needed the concept of C's UB (nor of C's 'const'). 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! > optimization. So I my wish higher level than C. At lower > level I may wish fancier macros in assembler, but that is > all: in such case I need control that only real assembler > can give. Now, for more control, I use inline assembly, but inline assembly with an easy interface to the host language. Compare the same thing in gcc.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-24 22:55 +0100 |
| Message-ID | <q78uda$he3$1@dont-email.me> |
| In reply to | #142367 |
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.) >> 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", you don't need any undefined behaviour of "assembler" features for that. You usually need target-specific and implementation specific features. > - Firmware (boot code/monitor code) for microcomputers You might need some assembly mixed in there, but real C (rather than your imagined C) will otherwise be fine. > - Text and graphics display drivers For drivers, you usually need a bit of "volatile", but C is fine with that. > - Basic graphics libraries > - Frame grabbing > - Basic image processing > - 3D graphics > - Software floating point > - Maths libraries > - Text editors > - Assemblers > - Compilers (a few of these) > - Linkers > - Interpreters > - Printer and plotter drivers > - Interfacing to mice, and [digitising] tablets > - Whole applications (mainly low-end 2D and 3D CAD) > - GUI libraries > - Arbitrary precision arithmetic > - File format conversion (read/write image files, dxf, eps, 3ds etc) > - Later interfacing to OSes like you, and to 3rd party APIs > - etc None of this needs to rely on any undefined behaviour in C. None of it needs signed integers to wrap. None of it requires C to be a "trumped up assembler". Some of it will need target-specific or implementation dependent features. But that is part of normal C. > > In early days of using bare microprocessor board, I has to use binary > machine code. Then I moved on to assembly (and using an actual keyboard > and screen editor), and /then/ on to using a primitive HLL, but one I > would still class as a proper HLL. That was a luxury! > > None of this involved C, and it never needed the concept of C's UB (nor > of C's 'const'). None of it needed to rely on any behaviour that is undefined in C. None of it needed to rely on any behaviour that is not defined in the C standards or implementations. (To be fair here, some of your programs will have been from before the days of C standards - and you may only have had very limited tools.) Like many features in all programming languages, "const" in C is about making it easier to write correct, efficient code, and to help identify some kinds of errors as early as possible. There are no programs that can be written with "const" that can't be written without it - that means it is not necessary, but it is very far from useless. > > 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, 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. > >> optimization. So I my wish higher level than C. At lower >> level I may wish fancier macros in assembler, but that is >> all: in such case I need control that only real assembler >> can give. > > Now, for more control, I use inline assembly, but inline assembly with > an easy interface to the host language. Compare the same thing in gcc. gcc inline assembly is not designed to be easy to write - that would not be a necessary feature, since it is so rarely needed. It is designed to interface closely and efficiently with the compiler. (I am not going to pretend it could not be neater or easier - it certainly could.)
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-24 20:37 -0700 |
| Message-ID | <1d54b052-49e7-4aee-a4cc-a394a0a77886@googlegroups.com> |
| In reply to | #142376 |
On Sunday, March 24, 2019 at 9:56:02 PM UTC, David Brown wrote: > On 24/03/2019 20:44, Bart wrote: > > - Basic graphics libraries > > - Frame grabbing > > - Basic image processing > > - 3D graphics > > - Software floating point > > - Maths libraries > > - Text editors > > - Assemblers > > - Compilers (a few of these) > > - Linkers > > - Interpreters > > - Printer and plotter drivers > > - Interfacing to mice, and [digitising] tablets > > - Whole applications (mainly low-end 2D and 3D CAD) > > - GUI libraries > > - Arbitrary precision arithmetic > > - File format conversion (read/write image files, dxf, eps, 3ds etc) > > - Later interfacing to OSes like you, and to 3rd party APIs > > - etc > > None of this needs to rely on any undefined behaviour in C. None of it > needs signed integers to wrap. None of it requires C to be a "trumped > up assembler". Some of it will need target-specific or implementation > dependent features. But that is part of normal C. 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. Or this was a recently fixed spec bug. Sorry for the hazy memory. 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. 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-24 21:54 -0700 |
| Message-ID | <lnva07blkj.fsf@kst-u.example.com> |
| In reply to | #142392 |
Howard Chu <highlandsun@gmail.com> writes:
[...]
> 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. 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 might be *implemented* as a single character array, but it's
not an object as far as C is concerned. This code fragment:
char *a = malloc(1);
char *b = malloc(1);
a < b;
has undefined behavior (unless, I think, one of the pointers happens
to point just past the object pointed to by the other pointer) --
regardless of how malloc is implemented.
> 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.
>
> 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.
I'm not sure it was ever possible to implement the entire standard
library in *portable* C. You can implement it in *non-portable* C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-25 06:11 +0000 |
| Message-ID | <GdfBdz5pbHcBscNMHR0FFjXOarp0b@bongo-ra.co> |
| In reply to | #142393 |
On Sun, 24 Mar 2019 21:54:36 -0700 Keith Thompson <kst-u@mib.org> wrote: > Howard Chu <highlandsun@gmail.com> writes: > > 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. > > I'm not sure it was ever possible to implement the entire standard > library in *portable* C. You can implement it in *non-portable* C. Obviously you couldn't. How would you implement the I/O functions portably ? You'd need operating system specific functionality. And come to think of it , without access to the underlying assembly , it would be hopeless to implement setjmp() and longjmp() .But if you were writing an interpreter for C then you could.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-25 07:59 -0400 |
| Message-ID | <bo3mE.351328$cx5.56556@fx46.iad> |
| In reply to | #142393 |
On 3/25/19 12:54 AM, Keith Thompson wrote: > Howard Chu <highlandsun@gmail.com> writes: > [...] >> 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. 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 might be *implemented* as a single character array, but it's > not an object as far as C is concerned. This code fragment: > > char *a = malloc(1); > char *b = malloc(1); > a < b; > > has undefined behavior (unless, I think, one of the pointers happens > to point just past the object pointed to by the other pointer) -- > regardless of how malloc is implemented. > The behavior is defined IF the heap did start as a single array, so that the pointers are all part of a single object. Since we, as users of the implementation, don't know that for sure, we can't depend on it. The implementer of malloc, might know that it is true, and could then depend on that fact. You CAN write malloc and family in portable C (at least if you are using a recent enough version of C to get the alignment right, or use knowledge of what is the strictest alignment type). >> 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. >> >> 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. > > I'm not sure it was ever possible to implement the entire standard > library in *portable* C. You can implement it in *non-portable* C. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-25 14:26 +0100 |
| Message-ID | <q7aktb$q90$1@dont-email.me> |
| In reply to | #142404 |
On 25/03/2019 12:59, Richard Damon wrote: > On 3/25/19 12:54 AM, Keith Thompson wrote: >> Howard Chu <highlandsun@gmail.com> writes: >> [...] >>> 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. 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 might be *implemented* as a single character array, but it's >> not an object as far as C is concerned. This code fragment: >> >> char *a = malloc(1); >> char *b = malloc(1); >> a < b; >> >> has undefined behavior (unless, I think, one of the pointers happens >> to point just past the object pointed to by the other pointer) -- >> regardless of how malloc is implemented. >> > > The behavior is defined IF the heap did start as a single array, so that > the pointers are all part of a single object. Since we, as users of the > implementation, don't know that for sure, we can't depend on it. The > implementer of malloc, might know that it is true, and could then depend > on that fact. > > You CAN write malloc and family in portable C (at least if you are using > a recent enough version of C to get the alignment right, or use > knowledge of what is the strictest alignment type). > Modern C will let you control alignment, and if your heap starts as a single array, pointer comparisons are safe. That is two issues out of the way. But as far as I know (and I'm happy to be shown wrong here), there are two more points that are somewhat related. Suppose the heap is defined as an array of unsigned char (an obvious choice) with the required alignment. When you call my_malloc(), you convert the returned void* into a pointer to a concrete type and use that to access the memory. If that new pointer type is not compatible with the type used in the definition of your heap, will that not break the "strict aliasing" rule? (i.e., 6.5p7). You can use a pointer-to-char to access any data, but you can't use a pointer-to-something-else to access a char array. And the effective type rules that let you change the effect type of an object are dependent on the memory originally having no "declared type". That is the case for the standard malloc(), but the pointer returned by my_malloc() is to an object of declared type array of char. (Real malloc implementations can always use implementation-specific features or extensions to get around this.)
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-25 15:59 +0000 |
| Message-ID | <JCmMbw9xfDPImMmM@bongo-ra.co> |
| In reply to | #142407 |
On Mon, 25 Mar 2019 14:26:02 +0100
David Brown <david.brown@hesbynett.no> wrote:
> Modern C will let you control alignment, and if your heap starts as a
> single array, pointer comparisons are safe. That is two issues out of
> the way.
>
> But as far as I know (and I'm happy to be shown wrong here), there are
> two more points that are somewhat related. Suppose the heap is defined
> as an array of unsigned char (an obvious choice) with the required
> alignment. When you call my_malloc(), you convert the returned void*
> into a pointer to a concrete type and use that to access the memory. If
> that new pointer type is not compatible with the type used in the
> definition of your heap, will that not break the "strict aliasing" rule?
> (i.e., 6.5p7). You can use a pointer-to-char to access any data, but
> you can't use a pointer-to-something-else to access a char array. And
> the effective type rules that let you change the effect type of an
> object are dependent on the memory originally having no "declared type".
> That is the case for the standard malloc(), but the pointer returned by
> my_malloc() is to an object of declared type array of char.
>
> (Real malloc implementations can always use implementation-specific
> features or extensions to get around this.)
What's wrong with
int *p = (int *) my_malloc(2 * sizeof(int)) ;
? p already has a declared type , int * , so I don't see how paragraph 7 of
6.5 is relevant. The only issue is whether the return value of my_malloc()
is correctly aligned for a pointer to int .If it is then the above fragment
is fine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-25 22:04 +0100 |
| Message-ID | <q7bfo6$8md$1@dont-email.me> |
| In reply to | #142413 |
On 25/03/2019 16:59, Spiros Bousbouras wrote:
> On Mon, 25 Mar 2019 14:26:02 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> Modern C will let you control alignment, and if your heap starts as a
>> single array, pointer comparisons are safe. That is two issues out of
>> the way.
>>
>> But as far as I know (and I'm happy to be shown wrong here), there are
>> two more points that are somewhat related. Suppose the heap is defined
>> as an array of unsigned char (an obvious choice) with the required
>> alignment. When you call my_malloc(), you convert the returned void*
>> into a pointer to a concrete type and use that to access the memory. If
>> that new pointer type is not compatible with the type used in the
>> definition of your heap, will that not break the "strict aliasing" rule?
>> (i.e., 6.5p7). You can use a pointer-to-char to access any data, but
>> you can't use a pointer-to-something-else to access a char array. And
>> the effective type rules that let you change the effect type of an
>> object are dependent on the memory originally having no "declared type".
>> That is the case for the standard malloc(), but the pointer returned by
>> my_malloc() is to an object of declared type array of char.
>>
>> (Real malloc implementations can always use implementation-specific
>> features or extensions to get around this.)
>
> What's wrong with
> int *p = (int *) my_malloc(2 * sizeof(int)) ;
>
> ? p already has a declared type , int * , so I don't see how paragraph 7 of
> 6.5 is relevant. The only issue is whether the return value of my_malloc()
> is correctly aligned for a pointer to int .If it is then the above fragment
> is fine.
>
I don't think that is correct, if my_malloc() works by returning a
pointer to part of a declared array - hence my question.
Suppose you had something like:
enum { heap_size = 0x10000 };
static _Alignas(16) uint8_t heap[heap_size];
static size_t top_of_heap = 0;
void * my_malloc(size_t x) {
size_t y = (x + 0x0f) & ~0x0f; // Increase to nearest block
size_t z = top_of_heap;
top_of_heap += y;
if (top_of_heap > heap_size) panic();
return &heap[z];
}
void * my_free(void * p) {
(void) p;
}
That is a rather simple heap implementation. It might seem useless, but
something like that is often used in small embedded systems where
dynamic allocation is only used at startup.
The problem with this:
int *p = (int *) my_malloc(2 * sizeof(int)) ;
is that "p" points to a uint8_t array, cast to an int*. The object
pointed to by the pointer returned by my_malloc has a declared type,
even though the returned pointer is a void*.
(As I say, I will be happy to be shown wrong here. But I need convincing.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-25 14:54 -0700 |
| Message-ID | <bc352493-a0b0-4280-aa29-d9b86ed2ee69@googlegroups.com> |
| In reply to | #142413 |
On Monday, March 25, 2019 at 11:59:18 AM UTC-4, Spiros Bousbouras wrote: > On Mon, 25 Mar 2019 14:26:02 +0100 > David Brown <david.brown@hesbynett.no> wrote: > > Modern C will let you control alignment, and if your heap starts as a > > single array, pointer comparisons are safe. That is two issues out of > > the way. > > > > But as far as I know (and I'm happy to be shown wrong here), there are > > two more points that are somewhat related. Suppose the heap is defined > > as an array of unsigned char (an obvious choice) with the required > > alignment. When you call my_malloc(), you convert the returned void* > > into a pointer to a concrete type and use that to access the memory. If > > that new pointer type is not compatible with the type used in the > > definition of your heap, will that not break the "strict aliasing" rule? > > (i.e., 6.5p7). You can use a pointer-to-char to access any data, but > > you can't use a pointer-to-something-else to access a char array. And > > the effective type rules that let you change the effect type of an > > object are dependent on the memory originally having no "declared type". > > That is the case for the standard malloc(), but the pointer returned by > > my_malloc() is to an object of declared type array of char. > > > > (Real malloc implementations can always use implementation-specific > > features or extensions to get around this.) > > What's wrong with > int *p = (int *) my_malloc(2 * sizeof(int)) ; > > ? p already has a declared type , int * , so I don't see how paragraph 7 of > 6.5 is relevant. The only issue is whether the return value of my_malloc() > is correctly aligned for a pointer to int .If it is then the above fragment > is fine. p has a declared type, but p could point at any location in memory correctly aligned for an 'int' - that doesn't mean that what it points at automatically has a declared type of 'int'. The key issue is the defining declaration of object containing the memory in question, and the declaration of p does not define that object (unless you set it using p = (int*)&p). Footnote 87 explicitly notes that "Allocated objects have no declared type.". If that weren't the case, there wouldn't be any examples of cases where an object has no declared type, and therefore no need for the rule (6.5p6) about how such memory acquires an effective type.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2019-03-25 22:35 +0000 |
| Message-ID | <MRUfBdz5pbHcBscNMHR0FFjXOarp@bongo-ra.co> |
| In reply to | #142443 |
On Mon, 25 Mar 2019 14:54:53 -0700 (PDT)
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On Monday, March 25, 2019 at 11:59:18 AM UTC-4, Spiros Bousbouras wrote:
> > What's wrong with
> > int *p = (int *) my_malloc(2 * sizeof(int)) ;
> >
> > ? p already has a declared type , int * , so I don't see how paragraph 7 of
> > 6.5 is relevant. The only issue is whether the return value of my_malloc()
> > is correctly aligned for a pointer to int .If it is then the above fragment
> > is fine.
>
> p has a declared type, but p could point at any location in memory
> correctly aligned for an 'int' - that doesn't mean that what it points
> at automatically has a declared type of 'int'.
Correct.
> The key issue is the
> defining declaration of object containing the memory in question, and
> the declaration of p does not define that object (unless you set it
> using p = (int*)&p).
No , the key issue is the type of p itself. For example if you write
*p = 19 ;
p has the correct type for such an expression (and we're assuming correct
alignment too).
> Footnote 87 explicitly notes that "Allocated objects have no declared
> type.". If that weren't the case, there wouldn't be any examples of
> cases where an object has no declared type, and therefore no need for
> the rule (6.5p6) about how such memory acquires an effective type.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-25 21:41 -0400 |
| Message-ID | <q7c006$t8m$1@dont-email.me> |
| In reply to | #142446 |
On 3/25/19 18:35, Spiros Bousbouras wrote:
> On Mon, 25 Mar 2019 14:54:53 -0700 (PDT)
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On Monday, March 25, 2019 at 11:59:18 AM UTC-4, Spiros Bousbouras wrote:
>>> What's wrong with
>>> int *p = (int *) my_malloc(2 * sizeof(int)) ;
>>>
>>> ? p already has a declared type , int * , so I don't see how paragraph 7 of
>>> 6.5 is relevant. The only issue is whether the return value of my_malloc()
>>> is correctly aligned for a pointer to int .If it is then the above fragment
>>> is fine.
>>
>> p has a declared type, but p could point at any location in memory
>> correctly aligned for an 'int' - that doesn't mean that what it points
>> at automatically has a declared type of 'int'.
>
> Correct.
>
>> The key issue is the
>> defining declaration of object containing the memory in question, and
>> the declaration of p does not define that object (unless you set it
>> using p = (int*)&p).
>
> No , the key issue is the type of p itself. For example if you write
> *p = 19 ;
>
> p has the correct type for such an expression (and we're assuming correct
> alignment too).
True, but if I have
long _Alignas(int) l=5;
p = (long*)l;
then writing *p=19 will not give l the effective type of "int". It's
simply an aliasing violation. It's only when p points at memory that has
no declared type that the effective type is permitted to be different
from the actual type.
The memory allocated by malloc is supposed to have allocated storage
duration, and therefore no declared type, and it's supposed to start out
with no effective type, either. That is a problem if you attempt to
emulate malloc() using standard C and a memory pool that does not have
allocated storage duration.
It could also be a problem even if you start out with allocated memory,
if your malloc-family emulation, or the code that uses it, uses
constructs that give parts of that memory pool an effective type. The
standard provides no way of "erasing" the effective type, only of
replacing it with a different effective type.
The standard library's implementation of the malloc() family doesn't
face the same problem - the effective type rules govern user code, not
standard library code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-26 09:44 +0100 |
| Message-ID | <q7cooh$7nj$2@dont-email.me> |
| In reply to | #142452 |
On 26/03/2019 02:41, James Kuyper wrote: > On 3/25/19 18:35, Spiros Bousbouras wrote: >> On Mon, 25 Mar 2019 14:54:53 -0700 (PDT) >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On Monday, March 25, 2019 at 11:59:18 AM UTC-4, Spiros Bousbouras wrote: >>>> What's wrong with >>>> int *p = (int *) my_malloc(2 * sizeof(int)) ; >>>> >>>> ? p already has a declared type , int * , so I don't see how paragraph 7 of >>>> 6.5 is relevant. The only issue is whether the return value of my_malloc() >>>> is correctly aligned for a pointer to int .If it is then the above fragment >>>> is fine. >>> >>> p has a declared type, but p could point at any location in memory >>> correctly aligned for an 'int' - that doesn't mean that what it points >>> at automatically has a declared type of 'int'. >> >> Correct. >> >>> The key issue is the >>> defining declaration of object containing the memory in question, and >>> the declaration of p does not define that object (unless you set it >>> using p = (int*)&p). >> >> No , the key issue is the type of p itself. For example if you write >> *p = 19 ; >> >> p has the correct type for such an expression (and we're assuming correct >> alignment too). > > True, but if I have > > long _Alignas(int) l=5; > p = (long*)l; > > then writing *p=19 will not give l the effective type of "int". It's > simply an aliasing violation. It's only when p points at memory that has > no declared type that the effective type is permitted to be different > from the actual type. > > The memory allocated by malloc is supposed to have allocated storage > duration, and therefore no declared type, and it's supposed to start out > with no effective type, either. That is a problem if you attempt to > emulate malloc() using standard C and a memory pool that does not have > allocated storage duration. > It could also be a problem even if you start out with allocated memory, > if your malloc-family emulation, or the code that uses it, uses > constructs that give parts of that memory pool an effective type. The > standard provides no way of "erasing" the effective type, only of > replacing it with a different effective type. > Yes, that is exactly what I am concerned about. > The standard library's implementation of the malloc() family doesn't > face the same problem - the effective type rules govern user code, not > standard library code. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-26 09:42 +0100 |
| Message-ID | <q7cokv$7nj$1@dont-email.me> |
| In reply to | #142443 |
On 25/03/2019 22:54, James Kuyper wrote: > On Monday, March 25, 2019 at 11:59:18 AM UTC-4, Spiros Bousbouras wrote: >> On Mon, 25 Mar 2019 14:26:02 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >>> Modern C will let you control alignment, and if your heap starts as a >>> single array, pointer comparisons are safe. That is two issues out of >>> the way. >>> >>> But as far as I know (and I'm happy to be shown wrong here), there are >>> two more points that are somewhat related. Suppose the heap is defined >>> as an array of unsigned char (an obvious choice) with the required >>> alignment. When you call my_malloc(), you convert the returned void* >>> into a pointer to a concrete type and use that to access the memory. If >>> that new pointer type is not compatible with the type used in the >>> definition of your heap, will that not break the "strict aliasing" rule? >>> (i.e., 6.5p7). You can use a pointer-to-char to access any data, but >>> you can't use a pointer-to-something-else to access a char array. And >>> the effective type rules that let you change the effect type of an >>> object are dependent on the memory originally having no "declared type". >>> That is the case for the standard malloc(), but the pointer returned by >>> my_malloc() is to an object of declared type array of char. >>> >>> (Real malloc implementations can always use implementation-specific >>> features or extensions to get around this.) >> >> What's wrong with >> int *p = (int *) my_malloc(2 * sizeof(int)) ; >> >> ? p already has a declared type , int * , so I don't see how paragraph 7 of >> 6.5 is relevant. The only issue is whether the return value of my_malloc() >> is correctly aligned for a pointer to int .If it is then the above fragment >> is fine. > > p has a declared type, but p could point at any location in memory > correctly aligned for an 'int' - that doesn't mean that what it points > at automatically has a declared type of 'int'. The key issue is the > defining declaration of object containing the memory in question, and > the declaration of p does not define that object (unless you set it > using p = (int*)&p). > Footnote 87 explicitly notes that "Allocated objects have no declared > type.". If that weren't the case, there wouldn't be any examples of > cases where an object has no declared type, and therefore no need for > the rule (6.5p6) about how such memory acquires an effective type. > Yes, I appreciate that. However, when you use the /standard/ malloc, you get an "allocated object" - a pointer to memory with no declared type. When you use your own allocator giving memory from an array, the pointer is to memory that /does/ have a declared type. If your "my_malloc" allocator got its memory from an OS call, or from memory allocated by linker script or assembly, or by simply knowing fixed addresses to use (applicable in small embedded systems), then the memory would have no declared type and everything would be fine (AFAICS). But it is different if the memory pool is from a declared array.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-04-10 08:32 -0700 |
| Message-ID | <864l75kh9j.fsf@mailhub.linuxsc.com> |
| In reply to | #142443 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> Footnote 87 explicitly notes that "Allocated objects have no declared
> type.". If that weren't the case, there wouldn't be any examples of
> cases where an object has no declared type, and therefore no need for
> the rule (6.5p6) about how such memory acquires an effective type.
Not so. An implementation is perfectly free to define conversion
of integer values less than, say, 4096, as referring to memory
not occupied by any declared object. In such an implementation,
a declaration like
int *foo = (void*) 100;
might be used to allow access to an object that has no declared
type.
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web