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 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-25 12:53 -0700 |
| Message-ID | <7499c550-d259-4c17-8e99-d88c51cfd83a@googlegroups.com> |
| In reply to | #142404 |
On Monday, March 25, 2019 at 11:59:12 AM UTC, 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. The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. > > 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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-25 13:20 -0700 |
| Message-ID | <3e9332ae-c618-4f67-8e3f-14dabbc4e643@googlegroups.com> |
| In reply to | #142431 |
On Monday, March 25, 2019 at 3:53:54 PM UTC-4, Howard Chu wrote: > On Monday, March 25, 2019 at 11:59:12 AM UTC, 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. > > The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. ... The standard is written on the assumption that there's a single implementation that translates source code, provides the standard libraries that the code links to, and links them all together. The fact that many implementations consist of a compiler, a linker, and a standard library provided by three different vendors is not directly acknowledged by the standard. For best results, an implementor of any one of those parts should test to confirm that his implementation is conforming with particular combinations of other vendor's implementations of the other two parts - and to publicly document which combinations have passed such testing. I would not recommended using such a mixed implementation without such documentation. > ... The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. If you can afford to restrict the portability of your code to implementations where such comparisons are perfectly valid, you can reasonably assume that sane implementors will implement such comparisons in the way that you want them to. If they don't, you can complain - not on the grounds that such behavior is non-conforming - it isn't. But because it's not useful, at least for you, and possibly for many other people like you. That's part of the purpose of "undefined behavior" - to give implementors the freedom to do what's most convenient for a given platform. Defining the behavior for all platforms would force implementations targeting platforms where such comparisons are natively meaningless, to emulate, in some horribly inefficient fashion, the behavior of platforms where it was meaningful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-25 13:40 -0700 |
| Message-ID | <lnef6ubsd7.fsf@kst-u.example.com> |
| In reply to | #142431 |
Howard Chu <highlandsun@gmail.com> writes:
> On Monday, March 25, 2019 at 11:59:12 AM UTC, 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.
>
> The compiler can't know at compile time either, if whatever malloc
> implementation you choose to use does this or not. The spec is wrong
> to unconditionally declare this as undefined behavior, thus forcing
> users to avoid pointer comparisons that could be perfectly valid on a
> given implementation.
The compiler is part of the implementation, and it can make
assumptions about the rest of the implementation. The user generally
doesn't get to choose which runtime library implementation is used.;
That's up to whoever creates the C implementation and that person
or group has the responsibility of making the whole thing conforming.
A compiler *could* take advantage of knowledge that malloc allocates
from a single static array, and therefore that `a < b` won't do
something strange. Since the behavior of `a < b` is undefined by
the standard, the compiler can do anything it likes -- including
behaving sensibly.
An implementation's documentation could state that the `a < b`,
where a and b are both values returned by malloc, will always
yield 0 or 1 in a consistent manner (a < b && b < c implies a < c,
for example). That's not something that the standard requires
the implementation to document. A user of that implementation can
reasonably rely on that guarantee *when using that implementation*
-- but if the documentation lies, the user's quarrel is with the
implementer; it doesn't make the implementation non-conforming.
[...]
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-26 07:28 -0400 |
| Message-ID | <q1omE.437781$YR5.202154@fx45.iad> |
| In reply to | #142431 |
On 3/25/19 3:53 PM, Howard Chu wrote: > The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. Actually, the implementation CAN know, because malloc is provided by the implementation, and any replacement by the user creates undefined behavior. Implementations don't need to support 'separate compilation' either (though it is commonly done). Ultimately, all the translation units have to be provided to the implementation to make and run the final program (The Linker, OS, and the actual machine are technically part of the implementation). The user CAN know enough to know if it is safe, and then they can do so, and in a real sense there is nothing wrong with that. If the implementation explicitly documents behavior that the Standard leaves as undefined, then the programmer can use that behavior, and as long as they continue to use implementation that document that behavior the same way, the program will continue to work. If the implementation doesn't document the behavior, as long as the implementation continues to behave in the expected way, the program will 'work'. Depending on how the programmer confirmed what is the behavior, will affect how much confidence they can have in the continuing of the behavior (inspecting the source of the implementation is one of the surer way), but there is always the risk that a new version will change undocumented behavior (even documented behavior can change, but then the changes will be documented or can be called a bug in the implementation).
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-26 09:42 -0700 |
| Message-ID | <9e62ad3d-5691-4fc2-bc9d-f842f06e2393@googlegroups.com> |
| In reply to | #142466 |
On Tuesday, March 26, 2019 at 11:28:30 AM UTC, Richard Damon wrote: > On 3/25/19 3:53 PM, Howard Chu wrote: > > The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. > > Actually, the implementation CAN know, because malloc is provided by the > implementation, and any replacement by the user creates undefined behavior. > > Implementations don't need to support 'separate compilation' either > (though it is commonly done). Ultimately, all the translation units have > to be provided to the implementation to make and run the final program > (The Linker, OS, and the actual machine are technically part of the > implementation). And this highlights another flaw in the specification. The standard libraries aren't magic, there's no reason for them to be more "special" than any libraries a user may write for themselves. It's common practice now to use drop-in replacement malloc libraries, which have better performance/ fragmentation-resistance/other properties than a default library's implementation. Having been the author of a couple C library implementations myself - the C compiler has no way to know that the file it's compiling is "for the implementation" and thus can be compiled with different rules than for peasant users' code. The rules against naming your own functions with the same names as functions within the standard library is also misguided. (Replacement malloc libraries already break this rule anyway...) There is no reason the standard library's code should be better/more magical/more special than code an independent party wrote. The special status of stdio in particular is misguided. The C language was explicitly designed *without* I/O statements, to avoid burdening the language with system-dependent features. This was an extremely unusual choice at the time, as major languages of the era (e.g. Fortran, Cobol, etc) all have I/O built in to the language syntax. I/O was never meant to be part of the C language specification, but here we are today and stdio is part of the spec. And while a C programmer may choose not to use stdio, they aren't free to reimplement it - that violates the namespace rules. These rules made no sense in 1999 and they make even less sense today when multiple compilers can produce binary-compatible code for a single OS. Saying "malloc is part of the implementation and the implementation is specially privileged" is totally bogus. It means 3rd party mallocs are non-conforming merely because they are 3rd party code, independent of the actual code they contain. Totally ludicrous. > > The user CAN know enough to know if it is safe, and then they can do so, > and in a real sense there is nothing wrong with that. If the > implementation explicitly documents behavior that the Standard leaves as > undefined, then the programmer can use that behavior, and as long as > they continue to use implementation that document that behavior the same > way, the program will continue to work. If the implementation doesn't > document the behavior, as long as the implementation continues to behave > in the expected way, the program will 'work'. Depending on how the > programmer confirmed what is the behavior, will affect how much > confidence they can have in the continuing of the behavior (inspecting > the source of the implementation is one of the surer way), but there is > always the risk that a new version will change undocumented behavior > (even documented behavior can change, but then the changes will be > documented or can be called a bug in the implementation).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-26 13:08 -0400 |
| Message-ID | <q7dm9o$pja$1@dont-email.me> |
| In reply to | #142477 |
On 3/26/19 12:42, Howard Chu wrote: > On Tuesday, March 26, 2019 at 11:28:30 AM UTC, Richard Damon wrote: >> On 3/25/19 3:53 PM, Howard Chu wrote: >>> The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. >> >> Actually, the implementation CAN know, because malloc is provided by the >> implementation, and any replacement by the user creates undefined behavior. >> >> Implementations don't need to support 'separate compilation' either >> (though it is commonly done). Ultimately, all the translation units have >> to be provided to the implementation to make and run the final program >> (The Linker, OS, and the actual machine are technically part of the >> implementation). > > And this highlights another flaw in the specification. The standard libraries > aren't magic, there's no reason for them to be more "special" than any > libraries a user may write for themselves. You might think that, but it's permitted for the standard libraries to be "magic", and to do things that ordinary user code can't do. For instance, printf() existed long before it became possible for users to write functions that could take a variable number of arguments, and the <tgmath.h> functions were defined long before _Generic() was added, allowing user code to do write generic functions. > It's common practice now to use > drop-in replacement malloc libraries, which have better performance/ > fragmentation-resistance/other properties than a default library's > implementation. And that's fine, if your implementation allows it - but as far as the standard is concerned providing your own malloc() replacement has undefined behavior. Some real-world implementations have integrated the standard library and compiler together more tightly than you seem to believe is possible. > Having been the author of a couple C library implementations myself - the > C compiler has no way to know that the file it's compiling is "for the > implementation" and thus can be compiled with different rules than for > peasant users' code. A C standard library can be more tightly integrated with the compiler than you think. The standard library might be provided only as a library, and not as source code. If the source code is in C (and it need not be), it still might take special handling to get it to compile correctly, which is how the compiler can "know it's compiling for the implementation". Note, in particular, that since everything the standard says about such things treats the compiler, linker, and standard library as a single entity called the "implementation", that it's perfectly legal for your compiler to inline calls to standard library functions, without linking to a separately provided standard library. It knows what those calls are supposed to do, and that it's undefined behavior to provide alternatives, so it can arrange to never actually call those alternatives. This is not hypothetical - it's a common real-world optimization, especially for the smaller mem*(), str*() and math library functions. > The rules against naming your own functions with the same names as functions > within the standard library is also misguided. It reflects the real-world existence of implementations quite different from the ones you're used to.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-27 08:57 +1300 |
| Message-ID | <gfvegfFar11U4@mid.individual.net> |
| In reply to | #142478 |
On 27/03/2019 06:08, James Kuyper wrote: > On 3/26/19 12:42, Howard Chu wrote: >> On Tuesday, March 26, 2019 at 11:28:30 AM UTC, Richard Damon wrote: >>> On 3/25/19 3:53 PM, Howard Chu wrote: >>>> The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. >>> >>> Actually, the implementation CAN know, because malloc is provided by the >>> implementation, and any replacement by the user creates undefined behavior. >>> >>> Implementations don't need to support 'separate compilation' either >>> (though it is commonly done). Ultimately, all the translation units have >>> to be provided to the implementation to make and run the final program >>> (The Linker, OS, and the actual machine are technically part of the >>> implementation). >> >> And this highlights another flaw in the specification. The standard libraries >> aren't magic, there's no reason for them to be more "special" than any >> libraries a user may write for themselves. > > You might think that, but it's permitted for the standard libraries to > be "magic", and to do things that ordinary user code can't do. For > instance, printf() existed long before it became possible for users to > write functions that could take a variable number of arguments, and the > <tgmath.h> functions were defined long before _Generic() was added, > allowing user code to do write generic functions. > >> It's common practice now to use >> drop-in replacement malloc libraries, which have better performance/ >> fragmentation-resistance/other properties than a default library's >> implementation. > > And that's fine, if your implementation allows it - but as far as the > standard is concerned providing your own malloc() replacement has > undefined behavior. Some real-world implementations have integrated the > standard library and compiler together more tightly than you seem to > believe is possible. Another example is the now common practice of inlining some library functions such as memset. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-03-26 22:53 -0400 |
| Message-ID | <CABmE.142550$cD4.38866@fx07.iad> |
| In reply to | #142477 |
On 3/26/19 12:42 PM, Howard Chu wrote: > On Tuesday, March 26, 2019 at 11:28:30 AM UTC, Richard Damon wrote: >> On 3/25/19 3:53 PM, Howard Chu wrote: >>> The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. >> >> Actually, the implementation CAN know, because malloc is provided by the >> implementation, and any replacement by the user creates undefined behavior. >> >> Implementations don't need to support 'separate compilation' either >> (though it is commonly done). Ultimately, all the translation units have >> to be provided to the implementation to make and run the final program >> (The Linker, OS, and the actual machine are technically part of the >> implementation). > > And this highlights another flaw in the specification. The standard libraries > aren't magic, there's no reason for them to be more "special" than any > libraries a user may write for themselves. It's common practice now to use > drop-in replacement malloc libraries, which have better performance/ > fragmentation-resistance/other properties than a default library's > implementation. But the ARE allowed to be magic. One reason to put something into the standard library is that there are aspects that can be done better if you don't have to live within all the constraints of the language. Take malloc(), the simple malloc you can write with only standard C is based on a static array, with a fixed size, that has to be set at compilation time. The array size has to be small enough for the program to fit on the smallest machine you want to run it on, and on a bigger machine, you can't use more memory. The implementation library, knowing details of the implementation, can let the heap expand. Using a 'drop-in replacement malloc' IS undefined behavior, UNLESS the implementation documents the rules to allow you to do it, and for very good reason. I know of implementations where malloc and family are just thin wrappers over another layer of memory allocation. For efficiency, other parts of the standard library get 'malloced' memory directly from that lower layer, and returns pointers to it as if is was from malloc. If the user just replaces malloc/free/etc, that doesn't know of how that implementation works, the replacement free will get memory that it doesn't know where it came from. > > Having been the author of a couple C library implementations myself - the > C compiler has no way to know that the file it's compiling is "for the > implementation" and thus can be compiled with different rules than for > peasant users' code. It isn't that it is compiled under different rules (but it COULD be), but that the library is allowed to know details about how the implementation works that a portable user program isn't allowed to (but a user program based on knowing how the implementation works could). It is knowing, and perhaps controlling, how undefined behavior acts that allows the library to do things hard to do in portable code. The standard also allows the compiler to perhaps know details of the implementation of the functions and do something special with them. > > The rules against naming your own functions with the same names as functions > within the standard library is also misguided. (Replacement malloc libraries > already break this rule anyway...) There is no reason the standard library's > code should be better/more magical/more special than code an independent > party wrote. > > The special status of stdio in particular is misguided. The C language was > explicitly designed *without* I/O statements, to avoid burdening the language > with system-dependent features. This was an extremely unusual choice at the > time, as major languages of the era (e.g. Fortran, Cobol, etc) all have I/O > built in to the language syntax. I/O was never meant to be part of the C > language specification, but here we are today and stdio is part of the spec. > And while a C programmer may choose not to use stdio, they aren't free to > reimplement it - that violates the namespace rules. The user is total free to re-implement it. You just need to follow a couple of rules. One option is to just use new names, then everything if fine. The second is to accept responsibility to be the implementation, and using the knowledge you have of the implementation (which better be enough to do it) > > These rules made no sense in 1999 and they make even less sense today when > multiple compilers can produce binary-compatible code for a single OS. > > Saying "malloc is part of the implementation and the implementation is > specially privileged" is totally bogus. It means 3rd party mallocs are > non-conforming merely because they are 3rd party code, independent of the > actual code they contain. Totally ludicrous. > IF the 3rd party malloc can't make the representation that it IS part of the implementation, and take responsibility for defining the undefined behavior that it is creating, then yes, that 3rd party code is totally bogus and non-conforming. 3rd party code, using implementation provided information can 'work' (and if the implementation formally documents that information, that code could be considered conforming for that implementation) It should be pointed out that at least one of the more popular C compilers ISN'T an implementation, because it doesn't contain a full standard library. To make a conforming implementation, you need to combine that compiler with a library that was designed to work with it, and use that combination according to the documentation, and THEN you have a C implementation. You can do exactly the same thing with ANY C compiler, strip off the library (or a part of it) and combine it with another library that was designed to work with the compiler, and you have an implementation (hopefully conforming if you did it right). One result of this is now that YOU are the 'implementer' and if problem occur, the buck starts with you. To put the blame on the compiler for a problem, you need to show that you followed the implementation rules (that may or may not have been clearly documented). Remember, Undefined Behavior just means the Standard provides no definition of what should happen. Since computers are generally deterministic machines, it is at least theoritically possible to define the results of ANY Undefined Behavior, but this definition may need as an input, the total state of the machine. To the level that you know what the implementation will do with a given input, you can use that knowledge. >> >> The user CAN know enough to know if it is safe, and then they can do so, >> and in a real sense there is nothing wrong with that. If the >> implementation explicitly documents behavior that the Standard leaves as >> undefined, then the programmer can use that behavior, and as long as >> they continue to use implementation that document that behavior the same >> way, the program will continue to work. If the implementation doesn't >> document the behavior, as long as the implementation continues to behave >> in the expected way, the program will 'work'. Depending on how the >> programmer confirmed what is the behavior, will affect how much >> confidence they can have in the continuing of the behavior (inspecting >> the source of the implementation is one of the surer way), but there is >> always the risk that a new version will change undocumented behavior >> (even documented behavior can change, but then the changes will be >> documented or can be called a bug in the implementation).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-27 10:27 +0100 |
| Message-ID | <q7ffmg$hda$1@dont-email.me> |
| In reply to | #142505 |
On 27/03/2019 03:53, Richard Damon wrote: > On 3/26/19 12:42 PM, Howard Chu wrote: >> On Tuesday, March 26, 2019 at 11:28:30 AM UTC, Richard Damon wrote: >>> On 3/25/19 3:53 PM, Howard Chu wrote: >>>> The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. >>> >>> Actually, the implementation CAN know, because malloc is provided by the >>> implementation, and any replacement by the user creates undefined behavior. >>> >>> Implementations don't need to support 'separate compilation' either >>> (though it is commonly done). Ultimately, all the translation units have >>> to be provided to the implementation to make and run the final program >>> (The Linker, OS, and the actual machine are technically part of the >>> implementation). >> >> And this highlights another flaw in the specification. The standard libraries >> aren't magic, there's no reason for them to be more "special" than any >> libraries a user may write for themselves. It's common practice now to use >> drop-in replacement malloc libraries, which have better performance/ >> fragmentation-resistance/other properties than a default library's >> implementation. > > But the ARE allowed to be magic. One reason to put something into the > standard library is that there are aspects that can be done better if > you don't have to live within all the constraints of the language. > A fine example is the <tgmath.h> functions in C99. These cannot be implemented using standard C99. So a C99 standard library /must/ use special compiler features in that header. There is no way around it. (With C11, you can use _Generic - but not in C99.) But that's okay, as the library is tied with the implementation, and can use extensions and extra features. However, these extensions and features don't have to be documented or made convenient for users. It's fine for the compiler to say that they are only allowed in a file called "tgmath.h". I don't think it is common to have such restrictions, but it is certainly common not to document the extensions - then it is easy for the compiler to change details in later versions, without breaking user code.
[toc] | [prev] | [next] | [standalone]
| From | Howard Chu <highlandsun@gmail.com> |
|---|---|
| Date | 2019-03-28 08:04 -0700 |
| Message-ID | <4eed0f40-5dfa-4599-9cec-a1ca49232c7e@googlegroups.com> |
| In reply to | #142505 |
On Wednesday, March 27, 2019 at 2:53:30 AM UTC, Richard Damon wrote: > On 3/26/19 12:42 PM, Howard Chu wrote: > > On Tuesday, March 26, 2019 at 11:28:30 AM UTC, Richard Damon wrote: > >> On 3/25/19 3:53 PM, Howard Chu wrote: > >>> The compiler can't know at compile time either, if whatever malloc implementation you choose to use does this or not. The spec is wrong to unconditionally declare this as undefined behavior, thus forcing users to avoid pointer comparisons that could be perfectly valid on a given implementation. > >> > >> Actually, the implementation CAN know, because malloc is provided by the > >> implementation, and any replacement by the user creates undefined behavior. > >> > >> Implementations don't need to support 'separate compilation' either > >> (though it is commonly done). Ultimately, all the translation units have > >> to be provided to the implementation to make and run the final program > >> (The Linker, OS, and the actual machine are technically part of the > >> implementation). > > > > And this highlights another flaw in the specification. The standard libraries > > aren't magic, there's no reason for them to be more "special" than any > > libraries a user may write for themselves. It's common practice now to use > > drop-in replacement malloc libraries, which have better performance/ > > fragmentation-resistance/other properties than a default library's > > implementation. > > But the ARE allowed to be magic. One reason to put something into the > standard library is that there are aspects that can be done better if > you don't have to live within all the constraints of the language. C is a system programming language. If there are things that can't be done within the constraints of the language, those constraints are wrong.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-28 09:03 -0700 |
| Message-ID | <9b57badb-ec59-42a3-8060-318ac233fe37@googlegroups.com> |
| In reply to | #142545 |
On Thursday, March 28, 2019 at 11:04:34 AM UTC-4, Howard Chu wrote: > On Wednesday, March 27, 2019 at 2:53:30 AM UTC, Richard Damon wrote: ... > > But the ARE allowed to be magic. One reason to put something into the > > standard library is that there are aspects that can be done better if > > you don't have to live within all the constraints of the language. > > C is a system programming language. If there are things that can't be > done within the constraints of the language, those constraints are wrong. OK - so how, using only the C language, and not anything from the C standard library (after all, we're talking about why it's necessary to write C standard library functions) do you: 1. Open a file 2. Read from the keyboard 3. Display something on the screen. 4. Access floating point flags 5. setjmp()/longjmp() 6. Open a new thread. 7. Using only C code with strictly conforming behavior, provide a definition for the offsetof() macro. The reality is that everything described above requires the use of either non-portable C constructs, or calls to functions defined in languages other than C. C doesn't match your concept of what a system programming language should be; despite which it's one of the most widely popular languages, especially for doing systems programming in. You might want to think a bit about that paradox. I personally have been writting C code for four decades now, and have done very little systems programming in it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-28 16:26 +0000 |
| Message-ID | <yA6nE.561273$uD1.39854@fx33.am4> |
| In reply to | #142548 |
On 28/03/2019 16:03, James Kuyper wrote:
> On Thursday, March 28, 2019 at 11:04:34 AM UTC-4, Howard Chu wrote:
>> On Wednesday, March 27, 2019 at 2:53:30 AM UTC, Richard Damon wrote:
> ...
>>> But the ARE allowed to be magic. One reason to put something into the
>>> standard library is that there are aspects that can be done better if
>>> you don't have to live within all the constraints of the language.
>>
>> C is a system programming language. If there are things that can't be
>> done within the constraints of the language, those constraints are wrong.
>
> OK - so how, using only the C language, and not anything from the C
> standard library (after all, we're talking about why it's necessary to
> write C standard library functions) do you:
>
> 1. Open a file
> 2. Read from the keyboard
> 3. Display something on the screen.
> 4. Access floating point flags
> 5. setjmp()/longjmp()
> 6. Open a new thread.
>
> 7. Using only C code with strictly conforming behavior, provide a
> definition for the offsetof() macro.
>
> The reality is that everything described above requires the use of
> either non-portable C constructs, or calls to functions defined in
> languages other than C.
And, so what?
Why can't C simply acknowledge that things such as foreign functions exist?
A runtime library for one implementation of C may necessarily have to be
non-portable to anything else.
This is what I use in my language if I want to use C's printf:
importlib cstd =
clang function printf(ref char, ...)int32
end
While the 'clang' call convention, the printf implementation (and
variadic parameters) are all outside of the language, the language
doesn't try and pretend none of them exist.
> C doesn't match your concept of what a system programming language
> should be; despite which it's one of the most widely popular languages,
Yeah, and most system headers are horrible ugly messes consisting of
endless hacks using #ifdefs everywhere and with innumerable variations
of the same system types.
(Remember the six levels of macros, conditionals and typedefs I
demonstrated in order to figure out what the hell a clock_t actually was?)
> especially for doing systems programming in. You might want to think a
> bit about that paradox. I personally have been writting C code for four
> decades now, and have done very little systems programming in it.
Exactly. You don't understand the problems.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-28 13:02 -0700 |
| Message-ID | <30d4e240-fff7-479e-939e-34dc6e88280a@googlegroups.com> |
| In reply to | #142550 |
On Thursday, March 28, 2019 at 12:26:14 PM UTC-4, Bart wrote: > On 28/03/2019 16:03, James Kuyper wrote: > > On Thursday, March 28, 2019 at 11:04:34 AM UTC-4, Howard Chu wrote: > >> On Wednesday, March 27, 2019 at 2:53:30 AM UTC, Richard Damon wrote: > > ... > >>> But the ARE allowed to be magic. One reason to put something into the > >>> standard library is that there are aspects that can be done better if > >>> you don't have to live within all the constraints of the language. > >> > >> C is a system programming language. If there are things that can't be > >> done within the constraints of the language, those constraints are wrong. > > > > OK - so how, using only the C language, and not anything from the C > > standard library (after all, we're talking about why it's necessary to > > write C standard library functions) do you: > > > > 1. Open a file > > 2. Read from the keyboard > > 3. Display something on the screen. > > 4. Access floating point flags > > 5. setjmp()/longjmp() > > 6. Open a new thread. > > > > 7. Using only C code with strictly conforming behavior, provide a > > definition for the offsetof() macro. > > > > The reality is that everything described above requires the use of > > either non-portable C constructs, or calls to functions defined in > > languages other than C. > > And, so what? > > Why can't C simply acknowledge that things such as foreign functions exist? What exactly do you want C to do about that? The behavior of code written in other languages is outside the scope of the C standard. You could, with equal justification, complain that the US constitution fails to provide rules governing what happens to US citizens while under the jurisdiction of the Russian government. There are documents that lay out such rules - but the US Constitution isn't one of them - that's outside the scope of that document. How C interfaces with other languages is outside the scope of the C standard. C has a feature, frequently reviled in this forum, allowing you to call a function with only a declaration of that function in scope, without having any definition of that function available to confirm that it has been declared correctly. It also allows translation units to be linked together to form programs. As a practical matter, a function declared in C code can be implemented in some entirely different language, and the implementation of that function can be linked to the caller of the function. The C standard says nothing about how this should work, but in practical fact, it is extremely common and ordinary thing for C compilers and linkers to work together with compilers for other languages to make it work. I explicitly referred to such functions in the message you're responding to. What more do you want of C?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-04-09 04:25 -0700 |
| Message-ID | <86y34jju96.fsf@mailhub.linuxsc.com> |
| In reply to | #142466 |
Richard Damon <Richard@Damon-Family.org> writes: > On 3/25/19 3:53 PM, Howard Chu wrote: > >> The compiler can't know at compile time either, if whatever malloc >> implementation you choose to use does this or not. The spec is >> wrong to unconditionally declare this as undefined behavior, thus >> forcing users to avoid pointer comparisons that could be perfectly >> valid on a given implementation. > > Actually, the implementation CAN know, because malloc is provided > by the implementation, and any replacement by the user creates > undefined behavior. > > Implementations don't need to support 'separate compilation' > either (though it is commonly done). Ultimately, all the > translation units have to be provided to the implementation to > make and run the final program (The Linker, OS, and the actual > machine are technically part of the implementation). I must disagree with the last comment. The linker is part of the implementation. The operating system and the actual machine are not: they are (part of?) a data processing system, which is a separate entity supporting a conforming implementation and is explicitly called out by the ISO C standard as something the standard does not address.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-04-09 07:03 -0700 |
| Message-ID | <7a4762a2-9104-4a9a-af30-58f45f4827d4@googlegroups.com> |
| In reply to | #142466 |
On Tuesday, March 26, 2019 at 7:28:30 AM UTC-4, Richard Damon wrote: ... > (The Linker, OS, and the actual machine are technically part of the > implementation). The standard defines an implementation as a "particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment" (3.12). The actual machine is hardware, not software, so it counts as part of the execution environment, not as part of the implementation. The OS is not directly concerned with translation of programs, it's merely used the the software that is concerned with such things, so it also should be considered part of the environment.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-04-09 14:31 +0000 |
| Message-ID | <912rE.266031$7C4.97615@fx33.iad> |
| In reply to | #142920 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On Tuesday, March 26, 2019 at 7:28:30 AM UTC-4, Richard Damon wrote:
>...
>> (The Linker, OS, and the actual machine are technically part of the
>> implementation).
>
>The standard defines an implementation as a "particular set of software, ru=
>nning in a particular translation environment under particular control opti=
>ons, that performs translation of programs for, and supports execution of f=
>unctions in, a particular execution environment" (3.12). The actual machine=
> is hardware, not software, so it counts as part of the execution environme=
>nt, not as part of the implementation. The OS is not directly concerned wit=
>h translation of programs, it's merely used the the software that is concer=
>ned with such things, so it also should be considered part of the environme=
>nt.
"and supports execution of functions in"
would seem to imply that the operating system is part of the EE.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-04-10 08:27 -0700 |
| Message-ID | <868swhkhiv.fsf@mailhub.linuxsc.com> |
| In reply to | #142921 |
scott@slp53.sl.home (Scott Lurndal) writes: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> On Tuesday, March 26, 2019 at 7:28:30 AM UTC-4, Richard Damon wrote: >> ... >> >>> (The Linker, OS, and the actual machine are technically part of the >>> implementation). >> >> The standard defines an implementation as a "particular set of >> software, running in a particular translation environment under >> particular control options, that performs translation of programs >> for, and supports execution of functions in, a particular execution >> environment" (3.12). The actual machineis hardware, not software, so >> it counts as part of the execution environment, not as part of the >> implementation. The OS is not directly concerned with translation of >> programs, it's merely used the the software that is concerned with >> such things, so it also should be considered part of the environment. > > "and supports execution of functions in" > > would seem to imply that the operating system is part of the EE. Part of the execution environment but not part of the implementation. The software that "supports execution of functions in" an execution environment is stuff like the C standard library or C runtime glue (e.g., crtn.o). The operating system is part of "a data-processing system that is capable of supporting a conforming implementation", and is explicitly excluded from what the C standard addresses.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-25 13:05 -0700 |
| Message-ID | <lnr2aubtze.fsf@kst-u.example.com> |
| In reply to | #142404 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 3/25/19 12:54 AM, Keith Thompson wrote:
> [...]
>> 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.
I don't believe that's correct. I don't think that the definedness
of `a < b` depends on how malloc is implemented.
If I write my own "my_malloc()" function that returns pointers
to chunks of a single static array, then `a < b` is well defined.
But if that same code is used *by the implementation* to implement
`malloc`, then that code is not part of the program, and the behavior
of `a < b` is undefined (meaning it's not defined by the language).
> 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).
Agreed.
[...]
--
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:06 +0000 |
| Message-ID | <FdfBdz5pbHcBscNMHR0FFjXOarp0b@bongo-ra.co> |
| In reply to | #142392 |
On Sun, 24 Mar 2019 20:37:16 -0700 (PDT) Howard Chu <highlandsun@gmail.com> 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. Or this was a recently fixed > spec bug. Sorry for the hazy memory. Regarding malloc() , before C2011 I don't think you could portably determine what the minimum alignment required for various objects was. Apart from that , you could write it. And of course you could write it calling the standard malloc() , for example if you wanted to experiment with different algorithms. You can trivially write your own memcpy() ; the problem is memmove() and it has nothing to do with effective types. The problem with memmove() is that you cannot portably apply any of the relational operators to pairs of pointers to distinct objects and therefore you cannot determine if the copying has to happen moving upwards or downwards. So you would have to allocate as temporary storage a separate memory region distinct from the two which get copied. > The rule that pointers from different objects can't be compared is somewhat > meaningless. Do you have suggestions on what additional guarantees the standard ought to provide so that you can apply the relational operators to pointers to distinct objects ? Why would you want to write your own memmove() anyway ? > 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. If you mean portably , no you couldn't. net.lang.c was the precursor of comp.lang.c and if you check some archive , you'll see it has questions which would seem ridiculous now (or any time after the 1989 standard became established) exactly because there were fewer guarantees back then. So you could try all kinds of stuff , like you can now , but you had no guarantees they would work. -- It would be difficult to do this without a suitably powerful replacement. Imagine the headlines: "Scheme backtracks on call/cc" ;-) Andy Wingo http://lists.scheme-reports.org/pipermail/scheme-reports/2012-February/001830.html
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-25 09:39 +0100 |
| Message-ID | <q7a447$rai$1@dont-email.me> |
| In reply to | #142392 |
On 25/03/2019 04:37, Howard Chu wrote: > 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. That is, I think, correct (but I am not certain). There is nothing wrong with that - there is no requirement that the C library be implementable in standard C. Most C libraries are written /mostly/ in standard C, with a smaller amount written in implementation-specific C, and assembly for bit that are best done in assembly. For example, there is nothing to stop an implementation having a type "__memoryblock" that is specific to the implementation, has alignment and size matching the biggest alignment needed on the target, and with the special property that it can alias anything and anything can alias it. Then a heap can be made using an array of that type. And there is nothing stopping a compiler treating pointer comparisons specially as long as the source file is called "memmove.c". > > The rule that pointers from different objects can't be compared is somewhat > meaningless. Why? Why would you want to do that, except for implementing a C standard library (which can be done using implementation-specific techniques and extensions)? In most implementations, you have a "uintptr_t" type. You can cast your pointers to that, and compare them, if you really need this feature. > 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. > That was never an "essential trait" of C. It was certainly an aim that /most/ of the library could be written in C - that has always been true, and still is true.
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web