Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #104113 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-02-18 00:43 +0000 |
| Last post | 2017-02-25 13:13 -0800 |
| Articles | 20 on this page of 539 — 32 participants |
Back to article view | Back to comp.lang.c
Is this valid C? BartC <bc@freeuk.com> - 2017-02-18 00:43 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-18 02:41 +0000
Re: Is this valid C? Philip Lantz <prl@canterey.us> - 2017-02-20 18:00 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-20 18:46 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-18 11:47 +0100
Re: Is this valid C? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-18 10:08 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-18 23:30 +0000
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-18 15:50 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-19 00:53 +0000
Re: Is this valid C? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-18 16:01 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-18 19:20 -0800
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 09:41 +0100
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-19 09:14 +0000
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 10:30 +0100
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-19 07:21 -0800
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 17:28 +0100
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-19 11:53 -0500
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 18:12 +0100
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-19 13:10 -0500
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 20:24 +0100
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-19 11:51 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-19 12:26 -0800
Getting yourself killfiled (Was: Is this valid C?) gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-19 21:23 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-19 11:23 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-19 07:33 -0800
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-19 15:35 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-19 19:42 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-19 12:04 -0800
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-19 20:51 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-19 22:23 +0000
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-19 14:48 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 00:36 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-20 09:58 +0100
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-20 09:14 -0800
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-20 12:17 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-19 23:16 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 00:24 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-20 00:56 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 01:25 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 11:14 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-20 14:44 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 15:18 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-20 15:51 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 16:16 +0000
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-23 12:23 +0000
Re: Is this valid C? supercat@casperkitty.com - 2017-02-19 15:49 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 00:55 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-20 10:05 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 07:08 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-20 16:23 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-20 16:03 +0000
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 08:45 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-20 09:17 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 12:25 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-20 12:29 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 13:20 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-20 13:50 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 14:08 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-20 15:16 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 16:19 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-21 09:28 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-02-21 09:19 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-21 19:21 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-21 19:21 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-21 21:34 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-21 21:31 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-22 10:09 +0100
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-22 10:43 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-22 12:43 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-22 15:07 +0000
Re: Is this valid C? supercat@casperkitty.com - 2017-02-22 09:26 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-22 16:28 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-22 17:18 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-22 09:22 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-22 19:20 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-22 11:34 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-22 11:49 -0800
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-22 20:11 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-22 21:45 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-22 23:13 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-22 23:45 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-23 10:35 +0100
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-23 01:10 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 00:35 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-22 16:42 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-23 11:06 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 11:07 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-23 10:49 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 12:18 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-23 17:30 +0100
Re: Is this valid C? Gareth Owen <gwowen@gmail.com> - 2017-02-23 18:48 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-23 01:52 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 11:37 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-23 15:11 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-23 07:36 -0800
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-23 16:49 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-23 09:04 -0800
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-23 17:09 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 16:14 +0000
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-23 16:51 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-23 17:39 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-22 22:57 +0100
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-22 15:31 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-22 15:46 -0800
Re: Is this valid C? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-22 18:35 -0600
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 00:46 +0000
Re: Is this valid C? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-22 22:39 -0600
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 10:57 +0000
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-24 17:57 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-23 11:17 +0100
Re: Is this valid C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-02-23 19:03 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 20:11 +0000
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-23 20:36 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 21:20 +0000
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-24 18:28 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 18:45 +0000
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-24 19:53 +0000
Re: Is this valid C? supercat@casperkitty.com - 2017-02-24 12:06 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 20:38 +0000
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-25 10:11 +1300
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-25 10:15 +1300
Re: Is this valid C? supercat@casperkitty.com - 2017-02-24 15:02 -0800
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-25 12:10 +1300
Re: Is this valid C? Gareth Owen <gwowen@gmail.com> - 2017-02-25 10:33 +0000
Re: Is this valid C? supercat@casperkitty.com - 2017-02-25 13:25 -0800
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-24 21:27 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 22:00 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-28 20:17 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 01:22 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:40 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 11:06 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-25 12:43 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 21:32 +0000
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-26 10:39 +1300
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 21:53 +0000
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-26 11:07 +1300
Re: Is this valid C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-25 19:19 -0700
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-26 17:12 +1300
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-26 00:13 +0000
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-24 00:56 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 01:19 +0000
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-24 03:18 +0100
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 14:03 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 14:28 +0000
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-24 16:20 +0100
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 07:49 -0800
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-24 17:03 +0100
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 16:19 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 09:50 -0800
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 18:48 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-24 17:25 +0100
Re: Is this valid C? Gareth Owen <gwowen@gmail.com> - 2017-02-24 16:40 +0000
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 16:50 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-25 19:52 +0100
Re: Is this valid C? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-26 09:17 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 17:44 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 18:07 +0000
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 18:45 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-24 19:56 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-25 19:58 +0100
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 10:01 -0800
Re: Is this valid C? luser droog <luser.droog@gmail.com> - 2017-02-24 14:28 -0800
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-24 16:08 +0000
Re: Is this valid C? antispam@math.uni.wroc.pl - 2017-02-24 18:18 +0000
Re: Is this valid C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-02-25 15:37 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-21 10:56 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-27 05:18 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-02-27 08:46 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-27 11:26 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-02-27 13:57 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-27 14:06 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-28 04:25 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-02-28 15:45 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-01 03:46 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 06:30 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-01 16:31 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 08:37 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-01 19:02 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 10:49 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-01 21:00 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 14:02 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-03-01 12:28 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 12:17 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-03-07 14:53 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-03-01 09:10 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 09:51 -0800
Re: Is this valid C? Nathan Wagner <nw@hydaspes.if.org> - 2017-03-02 19:44 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-03-02 12:05 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-02 04:19 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-03-02 06:06 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-02 10:16 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-03-02 15:32 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-03 04:20 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-03-03 05:19 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-03-03 08:22 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-02 19:34 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-03-02 08:02 -0800
Re: Is this valid C? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-02 10:54 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-03-02 16:35 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 18:30 -0700
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 07:52 -0800
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-20 13:53 -0800
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-20 12:58 -0800
Re: Is this valid C? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-20 17:28 -0600
Re: Is this valid C? supercat@casperkitty.com - 2017-02-20 16:03 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-21 09:14 +0100
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 05:10 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-23 07:43 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-26 07:07 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-26 09:17 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 08:17 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-23 09:11 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-23 09:46 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-23 09:55 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-23 10:27 -0800
Re: Is this valid C? Ike Naar <ike@iceland.freeshell.org> - 2017-02-23 20:32 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-23 12:54 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-26 10:06 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-26 13:13 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-17 11:56 -0700
Re: Is this valid C? supercat@casperkitty.com - 2017-04-17 12:32 -0700
Re: Is this valid C? supercat@casperkitty.com - 2017-02-26 14:36 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 08:30 -0700
Re: Is this valid C? supercat@casperkitty.com - 2017-05-01 09:34 -0700
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-19 15:54 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 13:02 -0800
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-23 14:53 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 18:33 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 10:58 -0800
Re: Is this valid C? Ike Naar <ike@iceland.freeshell.org> - 2017-02-19 09:06 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-19 10:53 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-19 09:06 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-19 16:25 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-19 11:42 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-19 17:45 +0000
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 11:57 -0800
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-23 21:27 +0000
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 05:03 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-23 13:39 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 17:42 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-23 16:41 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-24 10:04 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 08:43 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-24 14:53 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 12:57 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-24 20:04 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 15:35 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 12:37 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 16:18 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 15:21 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-24 16:09 -0800
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 17:45 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-25 14:44 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 20:08 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-25 14:15 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 21:48 -0500
Re: Is this valid C? Gareth Owen <gwowen@gmail.com> - 2017-02-25 10:35 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-25 09:12 -0500
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 14:24 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-25 15:59 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 18:03 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 21:50 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 19:04 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 23:20 -0500
Re: Is this valid C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-25 21:26 -0700
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-26 10:09 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-26 17:41 +0000
Re: Is this valid C? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-02-26 12:56 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 00:23 +0000
Re: Is this valid C? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-26 19:02 +0100
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-26 13:49 -0500
Re: Is this valid C? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-26 19:55 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-02-26 12:05 -0800
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 00:52 +0000
Re: Is this valid C? James Kuyper <jameskuyper@verizon.net> - 2017-02-26 22:01 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 10:42 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 08:51 -0500
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-27 13:59 +0000
Re: Is this valid C? Ike Naar <ike@iceland.freeshell.org> - 2017-02-27 15:36 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-27 10:01 -0800
Re: Is this valid C? Ike Naar <ike@iceland.freeshell.org> - 2017-02-27 18:57 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 10:47 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 16:35 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 15:14 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 21:05 +0000
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 21:26 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:12 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:12 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 23:20 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 18:45 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 00:05 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 19:48 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 02:32 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:27 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-28 17:55 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 12:23 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 05:09 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 12:27 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-28 10:06 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:16 -0500
Re: Is this valid C? James Kuyper <jameskuyper@verizon.net> - 2017-03-02 15:54 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-03 11:26 +0100
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-03 10:33 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-03 12:30 +0100
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-03 11:32 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-03 13:48 +0100
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-03 12:41 +0000
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-03 12:47 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-03 12:57 +0000
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-03 13:12 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-03 13:57 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-03-03 05:23 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-03 15:58 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-03-03 07:13 -0800
Re: Is this valid C? James Kuyper <jameskuyper@verizon.net> - 2017-03-03 12:53 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-03 19:33 +0000
Re: Is this valid C? James Kuyper <jameskuyper@verizon.net> - 2017-03-03 21:18 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-03 21:23 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-28 19:58 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:21 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 21:07 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:22 -0500
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-28 21:09 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:24 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:23 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-28 09:01 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 12:30 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 18:05 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:27 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 19:01 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:26 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 21:13 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:28 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-28 20:12 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:38 -0500
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-28 20:46 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:29 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 21:15 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:30 -0500
Re: Is this valid C? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-28 23:08 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:34 -0500
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-28 13:40 -0800
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-28 19:14 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:39 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 21:17 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:36 -0500
Re: Is this valid C? scott@slp53.sl.home (Scott Lurndal) - 2017-02-27 17:19 +0000
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-27 17:52 +0000
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-27 19:20 +0100
Re: Is this valid C? supercat@casperkitty.com - 2017-02-26 10:15 -0800
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-26 14:12 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-26 15:50 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 00:50 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-26 20:12 -0500
Re: Is this valid C? Ralf Damaschke <rwspam@gmx.de> - 2017-02-27 16:59 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 19:35 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-27 12:12 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 11:36 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-23 16:43 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 12:22 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 15:39 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 13:26 -0800
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-24 18:53 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 20:14 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 20:13 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 18:33 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 21:58 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 19:38 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 23:21 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-25 06:57 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-25 16:08 -0500
Re: Is this valid C? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-24 15:03 -0800
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-25 12:12 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 20:20 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 20:19 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-19 08:42 -0800
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-19 08:58 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-23 16:45 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 11:43 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 15:42 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 13:40 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 20:23 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-24 18:54 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-24 23:17 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-25 19:15 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-25 23:10 -0500
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-26 12:00 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-26 15:57 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-26 21:54 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-26 19:45 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 01:29 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 10:52 -0500
Re: Is this valid C? Ike Naar <ike@iceland.freeshell.org> - 2017-02-27 16:04 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 11:16 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 20:42 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:18 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-28 01:34 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-27 17:55 -0800
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-28 02:16 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-28 10:09 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:28 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-28 10:16 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 12:31 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-28 20:17 +0100
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 19:26 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:42 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-28 23:30 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 08:37 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 09:19 +0000
Re: Is this valid C? James Kuyper <jameskuyper@verizon.net> - 2017-02-27 09:14 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 11:00 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 16:24 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 10:58 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 16:39 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 15:19 -0500
Re: Is this valid C? Ike Naar <ike@iceland.freeshell.org> - 2017-02-27 20:57 +0000
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 21:52 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:21 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 23:33 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 18:49 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 16:06 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 19:52 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 17:10 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:31 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-28 06:44 -0800
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 00:14 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 20:00 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 02:37 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:37 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:20 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 21:21 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:29 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 15:04 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 18:58 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 16:18 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 20:03 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 17:17 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:40 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 02:57 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:46 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 00:01 +0000
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-27 19:23 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 20:05 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 17:51 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 00:00 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-28 09:23 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:32 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-03-01 07:36 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:43 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 21:21 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 11:39 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-01 16:56 +0000
Re: Is this valid C? supercat@casperkitty.com - 2017-03-01 09:12 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-01 19:07 +0100
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 08:34 -0700
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-03-01 18:00 +0100
Re: Is this valid C? jameskuyper@verizon.net - 2017-03-01 09:49 -0800
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 20:52 -0700
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-03-01 14:26 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 11:40 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-01 16:57 +0000
Re: Is this valid C? me <crisdunbar@gmail.com> - 2017-03-01 10:19 -0800
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-28 20:25 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:45 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-03-01 14:28 +1300
Re: Is this valid C? cross@spitfire.i.gajendra.net (Dan Cross) - 2017-03-01 03:17 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 11:43 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-03-01 10:28 -0800
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-28 11:35 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:46 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 03:07 +0000
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-27 23:56 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 20:18 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 18:05 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 00:02 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 21:36 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:32 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-28 01:29 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 00:09 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 05:22 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 12:36 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 18:10 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:35 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 18:56 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:46 -0500
Re: Is this valid C? Gareth Owen <gwowen@gmail.com> - 2017-02-28 19:39 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:48 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-28 10:46 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 12:43 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-01 02:08 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 11:52 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-01 16:58 +0000
Re: Is this valid C? jameskuyper@verizon.net - 2017-03-01 09:32 -0800
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-01 21:50 +0000
Re: Is this valid C? jameskuyper@verizon.net - 2017-03-01 09:18 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-26 19:47 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-26 19:24 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 11:08 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 10:15 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 15:08 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 13:26 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:40 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-27 15:37 -0800
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-27 18:54 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 19:02 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 00:35 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 19:44 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 02:27 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 23:20 -0500
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-28 04:45 +0000
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-28 17:57 +1300
Re: Is this valid C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-28 11:27 +0100
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:06 -0500
Re: Is this valid C? jameskuyper@verizon.net - 2017-02-28 06:26 -0800
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:09 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-28 17:36 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 13:10 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-03-01 07:28 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-28 15:49 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-03-01 14:30 +1300
Re: Is this valid C? Richard Heathfield <rjh@cpax.org.uk> - 2017-03-01 01:38 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 11:54 -0500
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 11:53 -0500
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-03-02 07:35 +1300
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-01 16:50 -0500
Re: Is this valid C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-27 21:45 +0000
Re: Is this valid C? Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-27 17:43 -0500
Re: Is this valid C? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-24 16:59 -0500
Re: Is this valid C? David Brown <david.brown@hesbynett.no> - 2017-02-19 11:03 +0100
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-19 12:10 +0000
Re: Is this valid C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 10:34 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-23 22:39 +0000
Re: Is this valid C? Ian Collins <ian-news@hotmail.com> - 2017-02-24 11:49 +1300
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-23 15:25 -0800
Re: Is this valid C? supercat@casperkitty.com - 2017-02-23 15:09 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 14:29 +0000
Re: Is this valid C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-25 07:04 -0800
Re: Is this valid C? BartC <bc@freeuk.com> - 2017-02-25 15:27 +0000
Re: Is this valid C? Keith Thompson <kst-u@mib.org> - 2017-02-25 13:13 -0800
Page 11 of 27 — ← Prev page 1 … 9 10 [11] 12 13 … 27 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-01 07:52 -0800 |
| Message-ID | <d5416a99-9455-4cb6-8d3f-78ceda225f42@googlegroups.com> |
| In reply to | #105225 |
On Wednesday, March 1, 2017 at 3:46:15 AM UTC-6, Andrew Haley wrote:
> Consider a compilation unit with this function:
>
> long f(long *a, double *b) {
> long result = *a;
> g(b);
> return result;
> }
Upon further consideration, I'm not quite sure what my rule would require
compilers to know about g() to be able to safely move the write to *a across
it, but it's no worse than the existing rules in that regard. Both of the
evil1() and evil2() below would have defined behavior under C99 and C11 if
used with your function f() and the function g() below.
long evil1(void)
{
double *dp = malloc(8);
long *lp = (long*)dp;
*lp = 1234;
return f(lp, dp);
}
long evil2(void)
{
long *lp = malloc(8);
*lp = 1234;
double *dp = (double*)lp;
return f(lp, dp);
}
void g(double *gdp)
{
*gdp = 1.0;
}
Under existing C99 rules, the Effective Type of *lp would be "long" until the
call to g*(), which would set its Effective Type to "double". Behavior would
thus be defined in a fashion that would forbid the compiler from moving the
write to "*a" [within f()] across the call to g().
Under the rules I was suggesting, evil1() would be allowed to return an
arbitrary value because "lp" would only be readable as type "long" until
the start of a function wherein the underlying storage is written via
lvalue of contrary type which isn't derived from lp. Since f() is such a
function, use of the pointer as type "long" within it would yield arbitrary
values.
Further, under my rules, evil2() would be allowed to return an arbitrary
value because "dp" would only be writable as type "double" until the start
of a function wherein the underlying storage is accessed via lvalue of
contrary type which isn't derived from dp. Since f() is such a function,
use of the pointer as type "double" within it would cause other accesses of
the same storage to yield arbitrary values.
Compilers should of course uphold c99's effective type guarantees unless a
programmer specifies otherwise because there definitely exists code that
relies upon them. If one needed to have a version of f() under my rules
which would behave in C99 fashion, in the absence of other compiler
directives it might be necessary to do something like:
long f(long *a, double *b) {
long result = *a;
if ((void*)a == (void*)b)
b=(double*)a;
g(b);
return result;
}
or--depending upon the exact semantics of void* conversions:
long f(long *a, double *b) {
a=(long*)(void*)a;
long result = *a;
b=(double*)(void*)b;
g(b);
return result;
}
The latter form would ensure that the cast necessary to use *a as a "long"
occurred after the last event that could make "a" unusable as that type, and
likewise with the cast of "b". The former version of the code would avoid
requiring the compiler to allow for aliasing other than between "a" and "b";
it would be helpful to write the rules so that the casts could be expressed
as (long*)(double*)a and (double*)(long*)b to indicate that a compiler would
only be required to provide for aliasing between those specific two types,
rather than having to provide for it across all types, but I'm not sure how
to write concise rules that would allow for that.
I would not expect that existing code would include the casts placed as above
because neither C99 nor C11 would require them. On the other hand, if a
programmer knows that such casts have been included everywhere they would be
required under alternate aliasing rules that permit more optimizations, the
programmer could enable the use of such rules to enable optimizations that
would not be possible under C99 nor C11.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-20 13:53 -0800 |
| Message-ID | <6969bc01-5544-4645-87ce-dad053fcbfac@googlegroups.com> |
| In reply to | #104292 |
On Monday, February 20, 2017 at 4:20:10 PM UTC-5, supe...@casperkitty.com wrote: ... > I thought that conforming programs were required to be well formed if they > don't contain any #pragma directives or reserved identifiers for which the > Standard defines no meaning. Why did you think that? Did you even bother to read the standard's definition of a conforming program? "A conforming program is one that is acceptable to a conforming implementation." (4p7). That's the complete definition. Note that there is one and only one thing that requires a conforming implementation of C to reject a program: a #error directive that survives conditional compilation. Therefore, a conforming implementation could be designed which accepts all other programs. I've no idea whether any such implementation has yet been created, but it would be trivial to create one as a minor modification to an open-source compiler such as gcc. Therefore, a #error directive that survives conditional compilation is the only feature that could ever disqualify something from being a conforming program. ... > > Yes. So use the compiler in non-conforming mode if you want to use the > > extension. > > That would be possible, but for whatever reason compiler writers have been > extremely loath to extend the language via any means other than by defining > reserved identifiers--among other things because they have no way of knowing That's also a good idea. However, in my experience, most compilers extend the language in ways other than just using reserved identifiers. Most of them do not fully conform to the standard unless you choose the right options, and even then, only if you don't choose any of the non-conforming options.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-20 12:58 -0800 |
| Message-ID | <90289668-d1e0-45dc-8588-bc76e22b018f@googlegroups.com> |
| In reply to | #104287 |
On Monday, February 20, 2017 at 3:25:10 PM UTC-5, supe...@casperkitty.com wrote: ... > The Standard would regard any program that uses such a feature as > "non-conforming" and would mandate that any conforming implementation > output a diagnostic upon receipt of such a construct, even if the > implementation supported the feature in question. You're right about the diagnostic, at least. However, after issuing the required diagnostic (which could consist of a single message unconditionally generated at the start of processing saying "Thank you for using our compiler"), it could then go on to accept the program, and still qualify as a fully conforming implementation of C. Review the standard's definition of "conforming program", and then explain to me how a program that is actually accepted by a fully conforming implementation of C could qualify as "non-conforming".
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-20 17:28 -0600 |
| Message-ID | <c8umac9cao9e9l0visib743s9t3vkstau0@4ax.com> |
| In reply to | #104287 |
On Mon, 20 Feb 2017 12:25:04 -0800 (PST), supercat@casperkitty.com wrote: >On Monday, February 20, 2017 at 11:17:33 AM UTC-6, Keith Thompson wrote: >> supercat writes: >> > It would be a heavy feature to *mandate*. Some processors, however, do have >> > instructions which accept an address in one register, a sub-word index in >> > another, and can easily load or store a value from a portion of a word, and >> > it would seem useful to have a standard syntax which, if accepted, would have >> > a consistent meaning. Even if all implementations supported it, there would >> > likely be some where it was used often and some where it never got used, so >> > allowing implementers to support it or not based upon customer requirements >> > would seem better than mandating support everywhere. >> >> Great. That's exactly the current situation. Implementations are >> free to support general bit and bitfield types *as an extension*. >> They can even collaborate to settle on consistent syntax and >> semantics, and perhaps document it as a secondary standard. >> There's no particular need to change the C stndaard itself. > >The Standard would regard any program that uses such a feature as >"non-conforming" and would mandate that any conforming implementation >output a diagnostic upon receipt of such a construct, even if the >implementation supported the feature in question. > >Further, if the Standard defines a behavior for an optional construct, >that would offer some assurance that neither the Standard nor other >implementations will define a construct which is incompatible with it, >which could help overcome chicken-and-egg friction. > >How many features in C11 offer a systems programmer any useful semantics >that weren't available in some C implementations even prior to the >publication of the C89 Standard? There have been some things like >"restrict" which allow programmers to invite compilers to make useful >optimizations, and variadic macros and generics could be useful, and >64-bit integer types are nice on hardware that supports them but making >those mandatory rather than optional (and of course strongly recommended) >makes the language less suitable for use on smaller platforms. > >If the authors of the Standard were more open to recognizing optional >features that would be useful on some platforms but not others, that >would facilitate useful innovation. As it is, the language really seems >quite stagnant. While they have recognized some optional features, some of them are pretty puzzling. I can understand threading being optional (it may well not apply to a given platform), but why complex? The only overhead complex imposes is that the compiler deal with the new types, and implement the basic operations. There's some additional library code, but it's quite standalone (it doesn't even impact printf). There is no runtime overhead, except for actual complex usage. OTOH, making all of FP (including complex) optional would make sense, since that *is* an issue on very small systems. Having a standardized, but optional, facility would go a long way towards making those functions commonly available on platforms where it matters. OTOH, it doesn't have to be the C committee. For C++, Boost does that to some extent, but there's nothing really similar for C, except maybe (if you squint some) Posix.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-20 16:03 -0800 |
| Message-ID | <eedefe70-b4b8-4440-bfc0-7fdb4de87339@googlegroups.com> |
| In reply to | #104301 |
On Monday, February 20, 2017 at 5:28:12 PM UTC-6, robert...@yahoo.com wrote:
> While they have recognized some optional features, some of them are
> pretty puzzling. I can understand threading being optional (it may
> well not apply to a given platform), but why complex? The only
> overhead complex imposes is that the compiler deal with the new types,
> and implement the basic operations. There's some additional library
> code, but it's quite standalone (it doesn't even impact printf). There
> is no runtime overhead, except for actual complex usage. OTOH, making
> all of FP (including complex) optional would make sense, since that
> *is* an issue on very small systems.
Agree with regard to floating-point. I'd also suggest that the minimum
requirement for double precision should be reduced so that a 32-bit
significant would be sufficient. Code that needs better precision than
that could test the values in limits.h and refuse compilation on systems
that don't meet its needs, but on many microcontrollers working with
a significand of 32 bits or less would be much faster than working with
a larger one. Even if using a 32-bit significand didn't save any space
compared with an IEEE double, it could offer better precision than a
"float" while allowing computations that were as fast or faster [since
the significand could be kept in a register separate from the sign+exponent,
avoiding the need for packing/unpacking steps].
> Having a standardized, but optional, facility would go a long way
> towards making those functions commonly available on platforms where
> it matters. OTOH, it doesn't have to be the C committee. For C++,
> Boost does that to some extent, but there's nothing really similar for
> C, except maybe (if you squint some) Posix.
POSIX may help on hosted systems, but it's pretty meaningless on
freestanding implementations. So far as I can tell, some of the
memory barriers in C11 should be useful for systems programming, but
I don't think the Standard allows an implementation to promise support
for any "atomics" features unless it can support atomic 64-bit operations,
something which will be impractical or impossible in many freestanding
implementations. In a hosted implementation that supports locking
primitives there might be no problem, but most freestanding implementations
would make no such primitives available to a compiler. If an implementation
were to implement 64-bit atomics using something like:
while(!cpu_test_and_set_instruction(&atomic_busy_flag))
;
the64bitVariable = whatever;
cpu_reset_flag_instruction(&atomic_busy_flag);
many applications would be likely to deadlock except in cases where code
would have worked without the lock [e.g. if an interrupt occurs while the
main-line is doing a 64-bit operation, and the interrupt tries to do its
own 64-bit operation, the main-line would be blocked until the interrupt
completes, but the interrupt couldn't complete until the main-line releases
the lock].
It might be possible to set up some tricky data structures so that the
main line would set up a data structure indicating what it needs to do, use
a 32-bit compare-and-swap to update a global update-descriptor pointer,
and then either perform the update (if no other operations were pending) or
else complete any other pending operations and then perform its own. Making
even that work, however, would require that all code anywhere in the system
use the same global-update procedure; quality freestanding implementations
should avoid imposing such requirements.
I see no reason all compilers should not be required to support a memory
barrier which is at least equivalent to calling an outside function whose
behavior the compiler knows nothing about, which would among other things
require that a compiler provide for the possibility that any storage to
which that outside function could have acquired a pointer may have be read
out using a character pointer and had a coincidentally-identical bit pattern
written back, also using a character pointer. Any compiler which has any
means of calling outside functions would need to be capable of supporting
such semantics, and no useful purpose would be served by forcing a programmer
to call a useless function and to jump through hoops to prevent the compiler
from seeing into it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-21 09:14 +0100 |
| Message-ID | <o8gspi$h4l$1@dont-email.me> |
| In reply to | #104287 |
On 20/02/17 21:25, supercat@casperkitty.com wrote: > On Monday, February 20, 2017 at 11:17:33 AM UTC-6, Keith Thompson wrote: >> supercat writes: >>> It would be a heavy feature to *mandate*. Some processors, however, do have >>> instructions which accept an address in one register, a sub-word index in >>> another, and can easily load or store a value from a portion of a word, and >>> it would seem useful to have a standard syntax which, if accepted, would have >>> a consistent meaning. Even if all implementations supported it, there would >>> likely be some where it was used often and some where it never got used, so >>> allowing implementers to support it or not based upon customer requirements >>> would seem better than mandating support everywhere. >> >> Great. That's exactly the current situation. Implementations are >> free to support general bit and bitfield types *as an extension*. >> They can even collaborate to settle on consistent syntax and >> semantics, and perhaps document it as a secondary standard. >> There's no particular need to change the C stndaard itself. > > The Standard would regard any program that uses such a feature as > "non-conforming" and would mandate that any conforming implementation > output a diagnostic upon receipt of such a construct, even if the > implementation supported the feature in question. > That is the nature of C extensions. They have existed for as long as there were C standards to extend. An embedded compiler might support a "flash" storage class specified to put data into flash instead of ram. A PC compiler might support "case 1 .. 10 :" as an abbreviation for "case 1: case 2: ..." in switches. Another compiler might support vector types. And so on. These are considered useful by the implementers and the users, but could certainly be counter to the rules of C - and a fully compliant compiler that does not have those extensions would see them as syntax errors or constraint violations.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-23 05:10 -0800 |
| Message-ID | <kfnr32puk7l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104243 |
supercat@casperkitty.com writes: > the Standard requires implementations to accept code which > attempts to access members of register-qualified arrays, No, it doesn't. Implementations are free to reject any program that has an expression where an array type would be converted to the corresponding pointer type, even if that code could never be executed.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-23 07:43 -0800 |
| Message-ID | <2318e216-3744-42ef-806f-f431e0a54b91@googlegroups.com> |
| In reply to | #104489 |
On Thursday, February 23, 2017 at 7:10:14 AM UTC-6, Tim Rentsch wrote:
> No, it doesn't. Implementations are free to reject any
> program that has an expression where an array type would
> be converted to the corresponding pointer type, even if
> that code could never be executed.
From N1570 6.3.2.1 [Lvalues, arrays, and function designators]
3 Except when it is the operand of the sizeof operator, the _Alignof
operator, or the unary & operator, or is a string literal used to
initialize an array, an expression that has type ``array of type''
is converted to an expression with type ``pointer to type'' that
points to the initial element of the array object and is not an
lvalue. **If the array object has register storage class, the behavior
is undefined.**
To what situation is the marked text referring? If such usage were a
constraint violation, declaring it undefined would be superfluous, would
it not? The only way I could see that such a thing would make sense would
be to say that while use of the "&" operator with an object of register
storage class is a constraint violation, use of a register-qualified array
in contexts not involving that operator is not.
Personally, I think what would make most sense--and the Standard allows this
but does not require it--would be for a compiler to accept attempts to
access a register-qualified array using [] syntax, but assume that it will
not alias any pointer expressions not involving that named array. Especially
in the days before "restrict" that could allow even single-pass compilers to
make some useful optimizations.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-26 07:07 -0800 |
| Message-ID | <kfnbmtpq9c4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104496 |
supercat@casperkitty.com writes: > On Thursday, February 23, 2017 at 7:10:14 AM UTC-6, Tim Rentsch wrote: >> No, it doesn't. Implementations are free to reject any >> program that has an expression where an array type would >> be converted to the corresponding pointer type, even if >> that code could never be executed. [..and with the >> understanding that the expression identifies an object >> with register class..] > > From N1570 6.3.2.1 [Lvalues, arrays, and function designators] > > 3 Except when it is the operand of the sizeof operator, the _Alignof > operator, or the unary & operator, or is a string literal used to > initialize an array, an expression that has type ``array of type'' > is converted to an expression with type ``pointer to type'' that > points to the initial element of the array object and is not an > lvalue. **If the array object has register storage class, the behavior > is undefined.** > > To what situation is the marked text referring? It refers to a compiler encountering a certain syntactic form having some particular semantic properties. More specifically, this occurs when translating encounters an expression that (a) is of array type, and (b) identifies an object with register storage class, but (c) is not directly an operand of a sizeof, _Alignof, or & operator. > If such usage were a constraint violation, declaring it undefined > would be superfluous, would it not? There are different points of view on that question, but in any case it is irrelevant to what I said above. > The only way I could see that such a thing would make sense would > be to say that while use of the "&" operator with an object of > register storage class is a constraint violation, use of a > register-qualified array in contexts not involving that operator > is not. The cases in question certainly could have been made constraint violations if that had been desired, but again that is irrelevant to what I said above. > Personally, I think what would make most sense [...] My earlier statement is only about what the Standard requires, not about what you think would make the most sense. In general, anyone who wants to understand what the Standard requires is well advised to focus on what the text in the Standard expresses, and not on what they think would make the most sense.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-26 09:17 -0800 |
| Message-ID | <1ad7cd6c-6ba3-4b42-ac2b-522d73fdd34b@googlegroups.com> |
| In reply to | #104762 |
On Sunday, February 26, 2017 at 9:07:59 AM UTC-6, Tim Rentsch wrote:
> supercat writes:
>
> > On Thursday, February 23, 2017 at 7:10:14 AM UTC-6, Tim Rentsch wrote:
> >> No, it doesn't. Implementations are free to reject any
> >> program that has an expression where an array type would
> >> be converted to the corresponding pointer type, even if
> >> that code could never be executed. [..and with the
> >> understanding that the expression identifies an object
> >> with register class..]
> >
> > From N1570 6.3.2.1 [Lvalues, arrays, and function designators]
> >
> > 3 Except when it is the operand of the sizeof operator, the _Alignof
> > operator, or the unary & operator, or is a string literal used to
> > initialize an array, an expression that has type ``array of type''
> > is converted to an expression with type ``pointer to type'' that
> > points to the initial element of the array object and is not an
> > lvalue. **If the array object has register storage class, the behavior
> > is undefined.**
> >
> > To what situation is the marked text referring?
>
> It refers to a compiler encountering a certain syntactic form
> having some particular semantic properties. More specifically,
> this occurs when translating encounters an expression that (a) is
> of array type, and (b) identifies an object with register storage
> class, but (c) is not directly an operand of a sizeof, _Alignof,
> or & operator.
If I understood you correctly, you were saying that an implementation would be
free to reject a program like the following:
#include <stdio.h>
int main(int argc, char **argv)
{ register int arr[4];
if (argc > 2) arr[0]=3;
return printf("Hello\n");
}
What basis would a conforming implementation have for doing so? If argc
is 2 or less, I see nothing(*) that would justify a conforming implementation
doing anything other than outputting Hello\n and exiting with the return
value from that printf.
(*) Capricious application of the One Program Rule could justify almost any
behavior, but the Standard can only be expected to have meaning on
implementations which don't apply the OPR capriciously.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-23 08:17 -0800 |
| Message-ID | <kfnmvdcvq2x.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104489 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > supercat@casperkitty.com writes: > >> the Standard requires implementations to accept code which >> attempts to access members of register-qualified arrays, > > No, it doesn't. Implementations are free to reject any > program that has an expression where an array type would > be converted to the corresponding pointer type, even if > that code could never be executed. Of course I meant an array type for something with register as its storage class.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-23 09:11 -0800 |
| Message-ID | <ln4lzkkf2o.fsf@kst-u.example.com> |
| In reply to | #104489 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> supercat@casperkitty.com writes:
>> the Standard requires implementations to accept code which
>> attempts to access members of register-qualified arrays,
>
> No, it doesn't. Implementations are free to reject any
> program that has an expression where an array type would
> be converted to the corresponding pointer type, even if
> that code could never be executed.
That doesn't agree with my reading of the standard.
An example:
int main(void) {
if (0) {
register char arr[1];
arr;
}
}
N1570 6.3.2.1p3, which specifies the conversion of array expressions to
pointer expressions, says "If the array object has register storage
class, the behavior is undefined." There is no constraint violation
(unless I'm missing something). Evaluating the expression `arr` would
have undefined behavior, but since the expression is never actually
evaluated, there is no behavior, defined or not. (IMHO it would make
sense for the expression `arr` to be a constraint violation, but that's
not what the standard says.)
(FWIW, gcc treats this as a fatal error, while clang merely warns
"expression result unused".)
I believe the same reasoning applies to this:
int main(void) {
if (0) {
1/0;
}
}
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-23 09:46 -0800 |
| Message-ID | <54b54bc1-1f0d-40d8-b87d-5a18e95bb0d0@googlegroups.com> |
| In reply to | #104508 |
On Thursday, February 23, 2017 at 11:11:06 AM UTC-6, Keith Thompson wrote:
> N1570 6.3.2.1p3, which specifies the conversion of array expressions to
> pointer expressions, says "If the array object has register storage
> class, the behavior is undefined." There is no constraint violation
> (unless I'm missing something). Evaluating the expression `arr` would
> have undefined behavior, but since the expression is never actually
> evaluated, there is no behavior, defined or not. (IMHO it would make
> sense for the expression `arr` to be a constraint violation, but that's
> not what the standard says.)
What would you think of the idea that a quality implementation should
process an expression like arr[n] in the natural sensible fashion
regardless of whether it would usefully process any other form of
expression that would take the address of "arr"? Making all operations
that take the address of "arr" a constraint violation would forbid the
one construct where that would likely be useful, and allowing code to
use the address of "arr" without restriction would prevent what should
be useful optimizations based upon the "register" qualifier.
I don't think any useful purpose is served by forbidding compilers from
treating as fatal errors any the use of "arr"'s address in any context
other than a [] expression, but I think the authors of the Standard
saw that they had to do one of four things:
1. Treat arr[n] as different from *(arr+n)
2. Allow some implementations to regard something as violating a
constraint without requiring that all implementations do so.
3. Brand the useful construct arr[n] as a constraint violation.
4. Require conforming implementations to accept a syntax that may
have no meaning.
Personally, I think they should have gone with #1 and/or #2, but the authors
of the Standard seem to have been averse to either of those as a matter of
principle, which left #4 as the least-evil alternative.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-23 09:55 -0800 |
| Message-ID | <lnzihciyfp.fsf@kst-u.example.com> |
| In reply to | #104510 |
supercat@casperkitty.com writes:
> On Thursday, February 23, 2017 at 11:11:06 AM UTC-6, Keith Thompson wrote:
>> N1570 6.3.2.1p3, which specifies the conversion of array expressions to
>> pointer expressions, says "If the array object has register storage
>> class, the behavior is undefined." There is no constraint violation
>> (unless I'm missing something). Evaluating the expression `arr` would
>> have undefined behavior, but since the expression is never actually
>> evaluated, there is no behavior, defined or not. (IMHO it would make
>> sense for the expression `arr` to be a constraint violation, but that's
>> not what the standard says.)
>
> What would you think of the idea that a quality implementation should
> process an expression like arr[n] in the natural sensible fashion
> regardless of whether it would usefully process any other form of
> expression that would take the address of "arr"?
[...]
That isn't what I was talking about, but I'll answer anyway.
I think that the [] operator is defined in terms of the & and +
operators, and breaking that equivalence for the sake of an obscure
and useless corner case would be a bad idea. Of course compiler
implementers are free to implement an extension that does that,
but my personal preference would be for them to spend their time
doing something more useful.
I also think that the diagnostic message for an attempt to index
a register-qualified array should advise removing the useless
"register" keyword from the array object's definition.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-23 10:27 -0800 |
| Message-ID | <62312bb4-1f47-41df-896a-a45f3bef6c1f@googlegroups.com> |
| In reply to | #104511 |
On Thursday, February 23, 2017 at 11:55:32 AM UTC-6, Keith Thompson wrote:
> I also think that the diagnostic message for an attempt to index
> a register-qualified array should advise removing the useless
> "register" keyword from the array object's definition.
Knowing that an array won't be aliased by any other pointers of the
element type may enable some useful and easy optimizations. While it
would be possible for a compiler start by making a pass over each
function to identify which objects have their addresses used in ways
which might create persistent pointers, many language-design decisions
appear to have been predicated upon the idea of facilitating single-pass
compilation. I can't think of any other reason, for example, to require
void process_array(int rows, int cols, double arr[static rows][cols]);
rather than
void process_array(double arr[static rows][cols], int rows, int cols);
given that the prevailing practice would have strongly favored the latter
pattern.
Further, if the constraint violations associated with registers were
replaced with rules somewhat tighter than those associated with "restrict",
that would add additional situations where programmers could invite
optimizations that would not otherwise be possible. For example, given:
int foo;
unsigned char *dat;
void update_sum(void)
{
foo += *dat++;
}
even if "test" were in-lined within a loop, a compiler would be required
to store "foo" and "dat" within each loop iteration. If a register
qualifier were allowed, such redundant stores could be eliminated.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-02-23 20:32 +0000 |
| Message-ID | <slrn3vfsoauhpd.41f.ike@iceland.freeshell.org> |
| In reply to | #104511 |
On 2017-02-23, Keith Thompson <kst-u@mib.org> wrote: > I think that the [] operator is defined in terms of the & and + > operators Did you mean the * and + operators?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-23 12:54 -0800 |
| Message-ID | <lnvas0iq69.fsf@kst-u.example.com> |
| In reply to | #104525 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2017-02-23, Keith Thompson <kst-u@mib.org> wrote:
>> I think that the [] operator is defined in terms of the & and +
>> operators
>
> Did you mean the * and + operators?
Yes, I was sloppy, sorry.
Given an array object arr, the expression arr[i] involves, among other
things, the usual conversion of the array expression arr to a pointer
expression. That conversion has undefined behavior if arr was defined
with the "register" keyword.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-26 10:06 -0800 |
| Message-ID | <kfn7f4crfn0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104508 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> supercat@casperkitty.com writes:
>>> the Standard requires implementations to accept code which
>>> attempts to access members of register-qualified arrays,
>>
>> No, it doesn't. Implementations are free to reject any
>> program that has an expression where an array type would
>> be converted to the corresponding pointer type, even if
>> that code could never be executed. [..and with the
>> understanding that the expression identifies an object
>> with register class..]
>
> That doesn't agree with my reading of the standard.
>
> An example:
>
> int main(void) {
> if (0) {
> register char arr[1];
> arr;
> }
> }
>
> N1570 6.3.2.1p3, which specifies the conversion of array expressions
> to pointer expressions, says "If the array object has register
> storage class, the behavior is undefined." There is no constraint
> violation (unless I'm missing something). Evaluating the expression
> `arr` would have undefined behavior, but since the expression is
> never actually evaluated, there is no behavior, defined or not. [..]
I understand your reaction but I believe it is not applicable in
the case of register-array-conversion. Please continue below...
> (FWIW, gcc treats this as a fatal error, while clang merely warns
> "expression result unused".)
>
> I believe the same reasoning applies to this:
>
> int main(void) {
> if (0) {
> 1/0;
> }
> }
I agree that the second case does not have undefined behavior. I
will argue that the reasoning followed in the second case does
not apply to the register-array-conversion case. First let me
ask you to refer to section 6.3.2.1 in N1256. Paragraph 3 in
that section is the same as what's in C11 except it doesn't
mention the _Alignof operator. So far so good.
Now let's look at N1256 section 6.3.2.1 paragraph 2. Here we
have another case of undefined behavior, namely, when there is an
lvalue-to-value conversion with the lvalue being of incomplete
type. Here is an example of that situation:
#include <stdlib.h>
typedef struct foo Foo;
extern void takes_foo( Foo );
int main(void) {
if (0) {
Foo *p = malloc( 100 );
takes_foo( *p );
}
return 0;
}
Asked to compile this code, gcc gives an error with all of the
roughly one dozen combinations of options settings that I tried,
both with and without -pedantic, including just plain gcc with no
options, gcc -ansi, gcc -std=c99, and gcc -std=c11. Not even a
warning but an error. Here is a typical diagnostic line (wrapped
after the "error:" to keep line length down):
lvalue-conversion.c:10:20: error:
dereferencing pointer to incomplete type 'Foo {aka struct foo}'
I expect no one is surprised by this result. The reason is
pretty obvious: because the size of *p is not known, there is no
way to generate code for the expression 'foo( *p )'. A similar
situation might occur with an array object having register
storage class. If at the declaration of said object, a simple
one-pass compiler had (rather pointlessly) assigned a register to
hold the object, then when it later arrives at an expression that
needs the object's address, there is no way to generate code that
does that. Registers usually just don't have addresses in the
normal C sense of the word.
Now let's look at N1256 section 6.3.2.1 paragraph 1. Here we
have a third case of undefined behavior, namely, when an lvalue
does not designate an object. But note: here there is an
explicit qualifying phrase (emphasis added):
if an lvalue does not designate an object _when it is
evaluated_, the behavior is undefined.
Again I expect no one is surprised, and again I think the reason
is fairly obvious: the cases of paragraphs 2 and 3 are known at
compile time, but the circumstances of paragraph 1 cannot (in the
general case) be known until run time. The paragraph 1 case is
analogous to the divide-by-zero example, and applies only when
such an expression is evaluated.
Taking all of the above into consideration, I conclude that the
provisions of 6.3.2.1 are meant to apply at compile time unless
there is an explicit "when it is evaluated" qualification.
Returning now to C11 (and N1570), paragraph 2 adds a new case of
undefined behavior, namely, reading an uninitialized object (of
automatic storage duration, and some other qualifiers). This
case too cannot be known in general until run time, so why isn't
there a "when it is evaluated" qualifier? Very probably, just
an editorial oversight.
So, there you have it. What do you think?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-26 13:13 -0800 |
| Message-ID | <ln8toshd0j.fsf@kst-u.example.com> |
| In reply to | #104776 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Now let's look at N1256 section 6.3.2.1 paragraph 2. Here we
> have another case of undefined behavior, namely, when there is an
> lvalue-to-value conversion with the lvalue being of incomplete
> type. Here is an example of that situation:
>
> #include <stdlib.h>
>
> typedef struct foo Foo;
>
> extern void takes_foo( Foo );
>
> int main(void) {
> if (0) {
> Foo *p = malloc( 100 );
> takes_foo( *p );
> }
> return 0;
> }
Which raises a question: *why* is this undefined behavior rather than a
constraint violation?
N1570 6.3.2.1p2 says that lvalue conversion has undefined behavior
if the lvalue has a non-array incomplete type. p3 says that
array-to-pointer conversion has undefined behavior if the array
object has register storage class.
Are there any cases where either of these conditions cannot be easily
detected at compile time? Is there any potential benefit in allowing
implementations to define the behavior of either conversion? Is there
any sensible behavior that could be implemented? (Neither the C89 nor
the C99 Rationale sheds any light on this.)
[...]
> Taking all of the above into consideration, I conclude that the
> provisions of 6.3.2.1 are meant to apply at compile time unless
> there is an explicit "when it is evaluated" qualification.
>
> Returning now to C11 (and N1570), paragraph 2 adds a new case of
> undefined behavior, namely, reading an uninitialized object (of
> automatic storage duration, and some other qualifiers). This
> case too cannot be known in general until run time, so why isn't
> there a "when it is evaluated" qualifier? Very probably, just
> an editorial oversight.
>
> So, there you have it. What do you think?
I think that the oversight was making those constructs undefined
behavior rather than constraint violations.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-17 11:56 -0700 |
| Message-ID | <kfny3uy6exg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104790 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> Now let's look at N1256 section 6.3.2.1 paragraph 2. Here we
>> have another case of undefined behavior, namely, when there is an
>> lvalue-to-value conversion with the lvalue being of incomplete
>> type. Here is an example of that situation:
>>
>> #include <stdlib.h>
>>
>> typedef struct foo Foo;
>>
>> extern void takes_foo( Foo );
>>
>> int main(void) {
>> if (0) {
>> Foo *p = malloc( 100 );
>> takes_foo( *p );
>> }
>> return 0;
>> }
>
> Which raises a question: *why* is this undefined behavior rather
> than a constraint violation?
>
> N1570 6.3.2.1p2 says that lvalue conversion has undefined behavior
> if the lvalue has a non-array incomplete type. p3 says that
> array-to-pointer conversion has undefined behavior if the array
> object has register storage class.
>
> Are there any cases where either of these conditions cannot be
> easily detected at compile time? Is there any potential benefit
> in allowing implementations to define the behavior of either
> conversion? Is there any sensible behavior that could be
> implemented? (Neither the C89 nor the C99 Rationale sheds any
> light on this.)
To my way of thinking a better question is Why do you think
they /should/ be constraint violations? Or to say that a bit
differently, what reasons might you offer that would convince
other (presumably skeptical) people they should be constraint
violations? FWIW I myself am on the side of undefined
behavior.
>> Taking all of the above into consideration, I conclude that the
>> provisions of 6.3.2.1 are meant to apply at compile time unless
>> there is an explicit "when it is evaluated" qualification.
>>
>> Returning now to C11 (and N1570), paragraph 2 adds a new case of
>> undefined behavior, namely, reading an uninitialized object (of
>> automatic storage duration, and some other qualifiers). This
>> case too cannot be known in general until run time, so why isn't
>> there a "when it is evaluated" qualifier? Very probably, just
>> an editorial oversight.
>>
>> So, there you have it. What do you think?
>
> I think that the oversight was making those constructs undefined
> behavior rather than constraint violations.
I don't think so. I fully expect the older cases being made
undefined behavior (ie, rather than constraint violations) was a
deliberate decision, not an oversight. The only oversight was in
forgetting to add a qualifying phrase for the case added in C11.
[toc] | [prev] | [next] | [standalone]
Page 11 of 27 — ← Prev page 1 … 9 10 [11] 12 13 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web