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 26 of 27 — ← Prev page 1 … 24 25 [26] 27 Next page →
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-27 13:26 -0800 |
| Message-ID | <c9004836-4f06-4b67-ae6e-880545e00a06@googlegroups.com> |
| In reply to | #104921 |
On Monday, February 27, 2017 at 3:07:58 PM UTC-5, Jerry Stuckle wrote: > On 2/27/2017 1:15 PM, jameskuyper@verizon.net wrote: > > On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle wrote: ... > >> Please show three independent and respected resources which contradict > >> these. And no, your incorrect interpretation of the standards does not > >> count. > > > > The standard itself is the most authoritative and precisely expressed > > source I could cite, more authoritative than any of the sources you cited. > > I see no reason to cite any other source. Since you've shown yourself as > > being fully capable of misinterpreting the words of the standard, why > > should I expect you to be any less capable of misinterpreting the words of > > any other, less authoritative, source I could cite? > > > > I cited three independent, reliable sources for my point. I can get > hundreds more, if I need to. I've no doubt about that. Yours is a popular misconception, and as I demonstrated in a previous message, one that can never get you into trouble with actual programs, because it never imposes any actual constraints on the observable behavior. None of your sources are sufficiently authoritative to override the fact that the standard says nothing to support that interpretation. All you need to do to prove me wrong is quote the exact text of the relevant clause in the standard that imposes an order of evaluation of expressions that is determined by operator precedence. If you're too lazy to cut-and-paste the text, a citation would be sufficient - I can copy the words for you if you're too lazy to copy them yourself. > Can you show even ONE independent source which supports your > interpretation? And while the standard is authoritative, your > interpretation of it is not. Earlier, you asked for "respected" sources - I was sure that you'd disrespect any source that disagreed with you, so I didn't even bother looking for one. Since you've removed that requirement, I'm willing to comply. Here's the first four that I found from a quick google search: http://en.cppreference.com/w/c/language/operator_precedence "Precedence and associativity are independent from order of evaluation. The C language standard doesn't specify operator precedence. It specifies the language grammar, and the precedence table is derived from it to simplify understanding." https://www.eskimo.com/~scs/cclass/krnotes/sx5l.html "Note that precedence is not the same thing as order of evaluation, ..." https://www.eskimo.com/~scs/cclass/notes/sx7c.html "... parentheses don't dictate overall evaluation order any more than precedence does." I admit that those two are not independent of each other, since both were written by Steve Summit, the maintainer of the comp.lang.c FAQ. I can assure you that he, at least, is generally well respected. http://www.cs.fsu.edu/~xyuan/cop4020/exp_assgn.ppt: "Precedence and associativity state the rules for grouping operators in expressions, but do not determine the operand evaluation order!" I make no claim that this proves anything more than that there are other people who share this "delusion" with me, which is why I didn't bother paying any attention to your sources. But I am, in fact, not alone in that "delusion", if that fact matters to you (it certainly doesn't matter to me).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 17:40 -0500 |
| Message-ID | <o929pi$ks2$1@jstuckle.eternal-september.org> |
| In reply to | #104937 |
On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: > On Monday, February 27, 2017 at 3:07:58 PM UTC-5, Jerry Stuckle wrote: >> On 2/27/2017 1:15 PM, jameskuyper@verizon.net wrote: >>> On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle wrote: > ... >>>> Please show three independent and respected resources which contradict >>>> these. And no, your incorrect interpretation of the standards does not >>>> count. >>> >>> The standard itself is the most authoritative and precisely expressed >>> source I could cite, more authoritative than any of the sources you cited. >>> I see no reason to cite any other source. Since you've shown yourself as >>> being fully capable of misinterpreting the words of the standard, why >>> should I expect you to be any less capable of misinterpreting the words of >>> any other, less authoritative, source I could cite? >>> >> >> I cited three independent, reliable sources for my point. I can get >> hundreds more, if I need to. > > I've no doubt about that. Yours is a popular misconception, and as I > demonstrated in a previous message, one that can never get you into trouble > with actual programs, because it never imposes any actual constraints on the > observable behavior. > It is a "popular misconception" held by millions of programmers world wide. > None of your sources are sufficiently authoritative to override the fact that > the standard says nothing to support that interpretation. All you need to do to > prove me wrong is quote the exact text of the relevant clause in the standard > that imposes an order of evaluation of expressions that is determined by > operator precedence. If you're too lazy to cut-and-paste the text, a citation would be sufficient - I can copy the words > for you if you're too lazy to copy them yourself. > So you're saying you know more than these resources? All you need to do is to provide even one respected independent link that supports your interpretation of the standard. >> Can you show even ONE independent source which supports your >> interpretation? And while the standard is authoritative, your >> interpretation of it is not. > > Earlier, you asked for "respected" sources - I was sure that you'd disrespect > any source that disagreed with you, so I didn't even bother looking for one. > Since you've removed that requirement, I'm willing to comply. Here's the first > four that I found from a quick google search: > You don't know that. > http://en.cppreference.com/w/c/language/operator_precedence > "Precedence and associativity are independent from order of evaluation. > The C language standard doesn't specify operator precedence. It specifies the > language grammar, and the precedence table is derived from it to simplify > understanding." > This is a single person - not a respected organization. Hardly the same as a major university or Microsoft. > https://www.eskimo.com/~scs/cclass/krnotes/sx5l.html > "Note that precedence is not the same thing as order of evaluation, ..." > Ditto. > https://www.eskimo.com/~scs/cclass/notes/sx7c.html > "... parentheses don't dictate overall evaluation order any more than precedence does." > Same as above. > I admit that those two are not independent of each other, since both were > written by Steve Summit, the maintainer of the comp.lang.c FAQ. I can assure > you that he, at least, is generally well respected. > They are also run by a single person - not a respected organization. > http://www.cs.fsu.edu/~xyuan/cop4020/exp_assgn.ppt: > "Precedence and associativity state the rules for grouping operators in > expressions, but do not determine the operand evaluation order!" > At last - a respected organization. And it echos what I have been saying. And I agree it does not determine the OPERAND (not operator) evaluation order. > I make no claim that this proves anything more than that there are other people > who share this "delusion" with me, which is why I didn't bother paying any > attention to your sources. But I am, in fact, not alone in that "delusion", if > that fact matters to you (it certainly doesn't matter to me). > You had one respected resource, which agreed with what I said. You had two other sites run by unknown individuals - not respected organizations. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-27 15:37 -0800 |
| Message-ID | <8874f1f0-56fa-42c3-b753-cc3b0b8fb0ea@googlegroups.com> |
| In reply to | #104955 |
On Monday, February 27, 2017 at 5:40:56 PM UTC-5, Jerry Stuckle wrote: > On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: > > On Monday, February 27, 2017 at 3:07:58 PM UTC-5, Jerry Stuckle wrote: > >> On 2/27/2017 1:15 PM, jameskuyper@verizon.net wrote: > >>> On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle wrote: > > ... > >>>> Please show three independent and respected resources which ... > It is a "popular misconception" held by millions of programmers world wide. I've no doubt of it. It's an easy misconception to have - loosing that misconception requires careful reading of the standard without being blinded by conflicting preconceptions. And, as I pointed out earlier, it's a misconception that reality seldom punishes you for being wrong about. ... > So you're saying you know more than these resources? Why not? Are you claiming that's impossible? I know more than a lot of people do, about a wide variety of topics, including some people who have made careers in the corresponding fields. Have you ever taken a look at the course notes that have been published on the net from various universities for classes covering topics that you're already an expert in? An occasional subtle mistake is the norm, not the exception. They say that "those who can't do, teach" - which is an exaggeration, and a disservice to teachers, but has a significant element of truth in it. The people who know the very most about a subject often don't have good teaching skills, and the people who have the best teaching skills often don't have very best knowledge of their topic. ... > > Earlier, you asked for "respected" sources - I was sure that you'd > > disrespect any source that disagreed with you, so I didn't even bother > > looking for one. Since you've removed that requirement, I'm willing > > to comply. Here's the first four that I found from a quick google > > search: > > > > You don't know that. It's a reasonable guess, based upon your previous behavior. Have you ever expressed or displayed any respect on this newsgroup for anyone who ever disagreed with you? Steve Summit is someone well known and respected in ... > This is a single person - not a respected organization. ... > Ditto. ... > Same as above. ... > They are also run by a single person - not a respected organization. You dropped the "respected" requirement, which was the only reason I bothered responding to your request. And before you dropped that requirement, you never specified that it had to be an organization. > > http://www.cs.fsu.edu/~xyuan/cop4020/exp_assgn.ppt: > > "Precedence and associativity state the rules for grouping operators in > > expressions, but do not determine the operand evaluation order!" > > > > At last - a respected organization. And it echos what I have been > > saying. And I agree it does not determine the OPERAND (not operator) > evaluation order.Steve Summit is someone well known and respected in True - but in C, operators aren't evaluated, only expressions are evaluated, and operands are expressions. By definition, the only expressions that aren't operands are full-expressions. The order in which full-expressions are evaluated is determined by what you would consider control-flow rules, so the only thing that operator precedence could control the order of evaluation of is expressions that are operands. It doesn't, but it could, if the standard actually said so.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-27 18:54 -0500 |
| Message-ID | <26f72483-008a-9e9e-470e-41b596711e0f@verizon.net> |
| In reply to | #104964 |
On 02/27/2017 06:37 PM, jameskuyper@verizon.net wrote: > On Monday, February 27, 2017 at 5:40:56 PM UTC-5, Jerry Stuckle wrote: ... > It's a reasonable guess, based upon your previous behavior. Have you > ever expressed or displayed any respect on this newsgroup for anyone who > ever disagreed with you? > Steve Summit is someone well known and respected in ... >> saying. And I agree it does not determine the OPERAND (not operator) >> evaluation order.Steve Summit is someone well known and respected in I originally had a comment about Steve, which I later removed when I decided there was no chance of ever convincing Jerry to respect Steve. However, I can only respond to Jerry's messages when using Google Groups, and while I'm composing my response it often randomly pastes strings I had previously cut into the location my cursor is currently pointed at. It was never my intention to deceive anyone into thinking that Jerry had actually endorsed Steve.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 19:02 -0500 |
| Message-ID | <o92eiu$81r$1@jstuckle.eternal-september.org> |
| In reply to | #104964 |
On 2/27/2017 6:37 PM, jameskuyper@verizon.net wrote: > On Monday, February 27, 2017 at 5:40:56 PM UTC-5, Jerry Stuckle wrote: >> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >>> On Monday, February 27, 2017 at 3:07:58 PM UTC-5, Jerry Stuckle wrote: >>>> On 2/27/2017 1:15 PM, jameskuyper@verizon.net wrote: >>>>> On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle wrote: >>> ... >>>>>> Please show three independent and respected resources which > ... >> It is a "popular misconception" held by millions of programmers world wide. > > I've no doubt of it. It's an easy misconception to have - loosing that misconception requires careful reading of the standard without being blinded by conflicting preconceptions. And, as I pointed out earlier, it's a misconception that reality seldom punishes you for being wrong about. > And you think you know more than well-respected resources? > ... >> So you're saying you know more than these resources? > > Why not? Are you claiming that's impossible? I know more than a lot of people do, about a wide variety of topics, including some people who have made careers in the corresponding fields. Have you ever taken a look at the course notes that have been published on the net from various universities for classes covering topics that you're already an expert in? An occasional subtle mistake is the norm, not the exception. They say that "those who can't do, teach" - which is an exaggeration, and a disservice to teachers, but has a significant element of truth in it. The people who know the very most about a subject often don't have good teaching skills, and the people who have the best teaching skills often don't have very best knowledge of their topic. > For you, yes, as you have repeatedly proven. > ... >>> Earlier, you asked for "respected" sources - I was sure that you'd >>> disrespect any source that disagreed with you, so I didn't even bother >>> looking for one. Since you've removed that requirement, I'm willing >>> to comply. Here's the first four that I found from a quick google >>> search: >>> >> >> You don't know that. > > It's a reasonable guess, based upon your previous behavior. Have you ever expressed or displayed any respect on this newsgroup for anyone who ever disagreed with you? > Steve Summit is someone well known and respected in > I disagree with idiots who have no idea what they are talking about but claim they do, yes. > ... >> This is a single person - not a respected organization. > ... >> Ditto. > ... >> Same as above. > ... >> They are also run by a single person - not a respected organization. > > You dropped the "respected" requirement, which was the only reason I bothered responding to your request. And before you dropped that > requirement, you never specified that it had to be an organization. > No, I didn't. I said an independent, respected resource. A site run by a single, unknown person does not qualify. >>> http://www.cs.fsu.edu/~xyuan/cop4020/exp_assgn.ppt: >>> "Precedence and associativity state the rules for grouping operators in >>> expressions, but do not determine the operand evaluation order!" >>> >> >> At last - a respected organization. And it echos what I have been >> >> saying. And I agree it does not determine the OPERAND (not operator) >> evaluation order.Steve Summit is someone well known and respected in > > > True - but in C, operators aren't evaluated, only expressions are > evaluated, and operands are expressions. By definition, the only > expressions that aren't operands are full-expressions. The order in which > full-expressions are evaluated is determined by what you would consider > control-flow rules, so the only thing that operator precedence could > control the order of evaluation of is expressions that are operands. It doesn't, but it could, if the standard actually said so. > That is correct. And expressions are evaluated in the order of their operators. The order of operand evaluation is not defined. They are two different things. But the fact there is a difference between operators and operands seems to escape you ability to understand. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-28 00:35 +0000 |
| Message-ID | <o92ghc$dd5$1@dont-email.me> |
| In reply to | #104971 |
On 28/02/17 00:02, Jerry Stuckle wrote: > On 2/27/2017 6:37 PM, jameskuyper@verizon.net wrote: >> On Monday, February 27, 2017 at 5:40:56 PM UTC-5, Jerry Stuckle wrote: >>> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >>>> On Monday, February 27, 2017 at 3:07:58 PM UTC-5, Jerry Stuckle wrote: >>>>> On 2/27/2017 1:15 PM, jameskuyper@verizon.net wrote: >>>>>> On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle wrote: >>>> ... >>>>>>> Please show three independent and respected resources which >> ... >>> It is a "popular misconception" held by millions of programmers world wide. >> >> I've no doubt of it. It's an easy misconception to have - loosing that misconception requires careful reading of the standard without being blinded by conflicting preconceptions. And, as I pointed out earlier, it's a misconception that reality seldom punishes you for being wrong about. >> > > And you think you know more than well-respected resources? > >> ... >>> So you're saying you know more than these resources? >> >> Why not? Are you claiming that's impossible? I know more than a lot of people do, about a wide variety of topics, including some people who have made careers in the corresponding fields. Have you ever taken a look at the course notes that have been published on the net from various universities for classes covering topics that you're already an expert in? An occasional subtle mistake is the norm, not the exception. They say that "those who can't do, teach" - which is an exaggeration, and a disservice to teachers, but has a significant element of truth in it. The people who know the very most about a subject often don't have good teaching skills, and the people who have the best teaching skills often don't have very best knowledge of their topic. >> > > For you, yes, as you have repeatedly proven. > >> ... >>>> Earlier, you asked for "respected" sources - I was sure that you'd >>>> disrespect any source that disagreed with you, so I didn't even bother >>>> looking for one. Since you've removed that requirement, I'm willing >>>> to comply. Here's the first four that I found from a quick google >>>> search: >>>> >>> >>> You don't know that. >> >> It's a reasonable guess, based upon your previous behavior. Have you ever expressed or displayed any respect on this newsgroup for anyone who ever disagreed with you? >> Steve Summit is someone well known and respected in >> > > I disagree with idiots who have no idea what they are talking about but > claim they do, yes. > >> ... >>> This is a single person - not a respected organization. >> ... >>> Ditto. >> ... >>> Same as above. >> ... >>> They are also run by a single person - not a respected organization. >> >> You dropped the "respected" requirement, which was the only reason I bothered responding to your request. And before you dropped that >> requirement, you never specified that it had to be an organization. >> > > No, I didn't. I said an independent, respected resource. A site run by > a single, unknown person does not qualify. The idea that Steve Summit is unknown or not respected is laughable. Never mind the fact that he maintains the C FAQ list. Never mind that he is a published author in his own right. Let us instead turn to W Richard Stevens, author of "Unix Network Programming", the definitive work on the subject. The second edition of this book is divided into two volumes. In the first of these, the Acknowledgements section lists thirteen people who "answered email questions of mine, sometimes lots of questions, which improved the accuracy and presentation of the text". Two of the thirteen names on this list are Brian Kernighan and Dennis Ritchie, which makes it a rather special list in a rather special book. And another of those thirteen names is... Steve Summit. Claiming that Steve Summit is not respected is almost like claiming that Chris Torek is not respected. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 19:44 -0500 |
| Message-ID | <o92h1c$emd$1@jstuckle.eternal-september.org> |
| In reply to | #104979 |
On 2/27/2017 7:35 PM, Richard Heathfield wrote: > On 28/02/17 00:02, Jerry Stuckle wrote: >> On 2/27/2017 6:37 PM, jameskuyper@verizon.net wrote: >>> On Monday, February 27, 2017 at 5:40:56 PM UTC-5, Jerry Stuckle wrote: >>>> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >>>>> On Monday, February 27, 2017 at 3:07:58 PM UTC-5, Jerry Stuckle wrote: >>>>>> On 2/27/2017 1:15 PM, jameskuyper@verizon.net wrote: >>>>>>> On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle >>>>>>> wrote: >>>>> ... >>>>>>>> Please show three independent and respected resources which >>> ... >>>> It is a "popular misconception" held by millions of programmers >>>> world wide. >>> >>> I've no doubt of it. It's an easy misconception to have - loosing >>> that misconception requires careful reading of the standard without >>> being blinded by conflicting preconceptions. And, as I pointed out >>> earlier, it's a misconception that reality seldom punishes you for >>> being wrong about. >>> >> >> And you think you know more than well-respected resources? >> >>> ... >>>> So you're saying you know more than these resources? >>> >>> Why not? Are you claiming that's impossible? I know more than a lot >>> of people do, about a wide variety of topics, including some people >>> who have made careers in the corresponding fields. Have you ever >>> taken a look at the course notes that have been published on the net >>> from various universities for classes covering topics that you're >>> already an expert in? An occasional subtle mistake is the norm, not >>> the exception. They say that "those who can't do, teach" - which is >>> an exaggeration, and a disservice to teachers, but has a significant >>> element of truth in it. The people who know the very most about a >>> subject often don't have good teaching skills, and the people who >>> have the best teaching skills often don't have very best knowledge of >>> their topic. >>> >> >> For you, yes, as you have repeatedly proven. >> >>> ... >>>>> Earlier, you asked for "respected" sources - I was sure that you'd >>>>> disrespect any source that disagreed with you, so I didn't even bother >>>>> looking for one. Since you've removed that requirement, I'm willing >>>>> to comply. Here's the first four that I found from a quick google >>>>> search: >>>>> >>>> >>>> You don't know that. >>> >>> It's a reasonable guess, based upon your previous behavior. Have you >>> ever expressed or displayed any respect on this newsgroup for anyone >>> who ever disagreed with you? >>> Steve Summit is someone well known and respected in >>> >> >> I disagree with idiots who have no idea what they are talking about but >> claim they do, yes. >> >>> ... >>>> This is a single person - not a respected organization. >>> ... >>>> Ditto. >>> ... >>>> Same as above. >>> ... >>>> They are also run by a single person - not a respected organization. >>> >>> You dropped the "respected" requirement, which was the only reason I >>> bothered responding to your request. And before you dropped that >>> requirement, you never specified that it had to be an organization. >>> >> >> No, I didn't. I said an independent, respected resource. A site run by >> a single, unknown person does not qualify. > > The idea that Steve Summit is unknown or not respected is laughable. > No, he is an individual, and not as well known or respected as Purdue University, University of Hawaii or Microsoft. Sorry. > Never mind the fact that he maintains the C FAQ list. Never mind that he > is a published author in his own right. Let us instead turn to W Richard > Stevens, author of "Unix Network Programming", the definitive work on > the subject. The second edition of this book is divided into two > volumes. In the first of these, the Acknowledgements section lists > thirteen people who "answered email questions of mine, sometimes lots of > questions, which improved the accuracy and presentation of the text". > Two of the thirteen names on this list are Brian Kernighan and Dennis > Ritchie, which makes it a rather special list in a rather special book. > And another of those thirteen names is... Steve Summit. > Maintaining an FAQ (there are many out there) list means nothing. And he has published little when compared to the organizations I sited. I've been referenced in books before also. It's no big thing. > Claiming that Steve Summit is not respected is almost like claiming that > Chris Torek is not respected. > He is a single individual, and not nearly as well known or respected as the organizations I referenced. Now how about someone who is really respected? And not by just a few programmers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-28 02:27 +0000 |
| Message-ID | <o92n2s$t4u$1@dont-email.me> |
| In reply to | #104980 |
On 28/02/17 00:44, Jerry Stuckle wrote:
> On 2/27/2017 7:35 PM, Richard Heathfield wrote:
<snip>
>> The idea that Steve Summit is unknown or not respected is laughable.
>>
>
> No, he is an individual,
So is everybody.
> and not as well known or respected as Purdue
> University, University of Hawaii or Microsoft. Sorry.
Universities don't write Web pages. /People/ write Web pages. Can you
name the people who wrote those reference materials you cited? We have
no idea who they are. So how do you know you can respect them?
<https://web.ics.purdue.edu/~cs240/misc/operators.html> - author
unknown. Contains errors.
But presumably the instructor for that course has at least looked at the
page, and may well be the one responsible for correcting any errors. He
is Professor Vernon Rego, of whom I've never heard. So who /does/ know
him? His students? Here are the available ratings from CS240 students:
poor, average, average, awful, awful, awful, awesome, poor. A
representative comment: "coding is not his forte."
Okay, students aren't noted for their objectivity where teaching staff
are concerned. But what else do we have to go on? The guy is totally
unknown. The only reference I could find to him online other than
ratings sites and the Purdue site was in a CV from one of his former
students, with whom he has co-written a number of papers, none of them
on the C language.
<https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html> -
author may be unknown. Contains errors.
Ah, but we /might/ be able to ascribe this one. If we click "up" a
couple of times, we find these names:
Bharat Kinariwala and Tep Dobry
These guys wrote a book called "Programming in C", back in 1993, which
is available online. The C doesn't kick off until Chapter 2 (in which,
by the way, the mistaken interpretation of precedence is repeated). And
*every single program* in that chapter exhibits undefined behaviour,
because of 4.1.6 of the ANSI C Standard (probably 7.1.6 of C90 -
remember, this book was published in 1993, so it must be judged by the
language definition pertaining at the time), which says that "If a
function that accepts a variable number of arguments is not declared
(explicitly or by including its associated header), the behavior is
undefined."
If they don't even know they have to include <stdio.h> before calling
printf, I'm not about to trust their views on operator precedence.
I'd rather trust Steve Summit. At least he knows about <stdio.h>
<https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx>
Author unknown. But maybe it's the same guy who wrote this:
<https://msdn.microsoft.com/en-us/library/4bftz997.aspx>
I'd rather trust Steve Summit. At least he knows about base cases, and
he knows how to write a condition properly.
>> Never mind the fact that he maintains the C FAQ list. Never mind that he
>> is a published author in his own right. Let us instead turn to W Richard
>> Stevens, author of "Unix Network Programming", the definitive work on
>> the subject. The second edition of this book is divided into two
>> volumes. In the first of these, the Acknowledgements section lists
>> thirteen people who "answered email questions of mine, sometimes lots of
>> questions, which improved the accuracy and presentation of the text".
>> Two of the thirteen names on this list are Brian Kernighan and Dennis
>> Ritchie, which makes it a rather special list in a rather special book.
>> And another of those thirteen names is... Steve Summit.
>>
>
> Maintaining an FAQ (there are many out there) list means nothing.
It means a lot when its contributors include Henry Spencer, Eric
Raymond, Doug Gwyn (check your K&R acknowledgements), Mark Brader, Larry
Jones, Peter Seebach, Dan Pop, Clive Feather, Lawrence Kirby, Bob Stout,
Andrew Koenig, and Chris Torek. You may never have heard of these
people, but there are plenty here who have.
> And
> he has published little when compared to the organizations I sited.
On the other hand, his publications (although presumably not perfect)
are not riddled with errors. But wait! I should justify "riddled" at
least a little bit. So here are a few errors spotted at random.
If I can go back to that Chapter 2 thing by the Hawai'i guys for a
moment, they call scanf immediately after a printf prompt with no
newline and no explicit flush, so the prompt may not appear before the
program blocks for input. They fail to return a value from main(), so
the termination status is undefined (not exactly an error, but not
exactly bright, either). In Chapter 6, they have this code:
main()
{ int x;
int iptr;
printf("***Testing Pointer Variables***\n");
x = 10;
iptr = &x;
printf("%d\n",iptr);
}
I guess they forgot to compile that one.
In Chapter 14, they claim that malloc is prototyped not only in
<stdlib.h> (which is correct) but also in <alloc.h> (which the Standard
doesn't even define!). In their example program, the return value of
malloc is routinely cast (which is poor style). What's more, the program
uses gets()!
Are you seriously holding these guys up as shining examples of C expertise?
This next one isn't actually an error from my point of view, but it
might be from yours. In Chapter 5, where they spend rather more time on
precedence than in Chapter 2, they list the function call operator as
having the highest precedence. Since you don't think that there is any
such operator, no doubt you will consider this an error. But who are
you, to disagree with somebody from a real live university? (Your
argument, not mine.)
> I've been referenced in books before also. It's no big thing.
I can't seem to find you anywhere. Perhaps you could name the book that
acknowledges you.
>
>> Claiming that Steve Summit is not respected is almost like claiming that
>> Chris Torek is not respected.
>>
>
> He is a single individual, and not nearly as well known or respected as
> the organizations I referenced.
I would argue that he is both vastly better-known and much more highly
respected as a C programmer than any of the authors of those pages. Do
you actually know any of the authors of the pages you cited? Do you know
what C credentials they have (other than being the authors of some
spectacular bugs)?
> Now how about someone who is really respected? And not by just a few
> programmers.
ISO/IEC 9899. We've been here before.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 23:20 -0500 |
| Message-ID | <o92tmm$6i8$1@jstuckle.eternal-september.org> |
| In reply to | #105008 |
On 2/27/2017 9:27 PM, Richard Heathfield wrote:
> On 28/02/17 00:44, Jerry Stuckle wrote:
>> On 2/27/2017 7:35 PM, Richard Heathfield wrote:
>
> <snip>
>
>>> The idea that Steve Summit is unknown or not respected is laughable.
>>>
>>
>> No, he is an individual,
>
> So is everybody.
>
>> and not as well known or respected as Purdue
>> University, University of Hawaii or Microsoft. Sorry.
>
> Universities don't write Web pages. /People/ write Web pages. Can you
> name the people who wrote those reference materials you cited? We have
> no idea who they are. So how do you know you can respect them?
>
That is correct. But universities don't just allow anyone to write
their pages. Content like this must be reviewed .
> <https://web.ics.purdue.edu/~cs240/misc/operators.html> - author
> unknown. Contains errors.
>
So YOU say. The experts at Purdue disagree, or the page would not be there.
> But presumably the instructor for that course has at least looked at the
> page, and may well be the one responsible for correcting any errors. He
> is Professor Vernon Rego, of whom I've never heard. So who /does/ know
> him? His students? Here are the available ratings from CS240 students:
> poor, average, average, awful, awful, awful, awesome, poor. A
> representative comment: "coding is not his forte."
>
And it's not just one professor who reviews the information. However,
even if that weren't the case, I would trust the knowledge of a
University Professor over anyone here - especially when that professor
agrees with other recognized experts.
> Okay, students aren't noted for their objectivity where teaching staff
> are concerned. But what else do we have to go on? The guy is totally
> unknown. The only reference I could find to him online other than
> ratings sites and the Purdue site was in a CV from one of his former
> students, with whom he has co-written a number of papers, none of them
> on the C language.
>
So what? Peer review says a lot.
> <https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html> -
> author may be unknown. Contains errors.
>
> Ah, but we /might/ be able to ascribe this one. If we click "up" a
> couple of times, we find these names:
>
> Bharat Kinariwala and Tep Dobry
>
> These guys wrote a book called "Programming in C", back in 1993, which
> is available online. The C doesn't kick off until Chapter 2 (in which,
> by the way, the mistaken interpretation of precedence is repeated). And
> *every single program* in that chapter exhibits undefined behaviour,
> because of 4.1.6 of the ANSI C Standard (probably 7.1.6 of C90 -
> remember, this book was published in 1993, so it must be judged by the
> language definition pertaining at the time), which says that "If a
> function that accepts a variable number of arguments is not declared
> (explicitly or by including its associated header), the behavior is
> undefined."
>
> If they don't even know they have to include <stdio.h> before calling
> printf, I'm not about to trust their views on operator precedence.
>
Once again, universities review content like this before it is posted on
their site. And this information agrees with the others.
> I'd rather trust Steve Summit. At least he knows about <stdio.h>
>
One person, not peer reviewed. Sorry.
> <https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx>
>
> Author unknown. But maybe it's the same guy who wrote this:
>
> <https://msdn.microsoft.com/en-us/library/4bftz997.aspx>
>
You're guessing, aren't you. And Microsoft doesn't let just anyone post
pages like this on their site, either. It is a group effort.
> I'd rather trust Steve Summit. At least he knows about base cases, and
> he knows how to write a condition properly.
>
One person, not peer reviewed. Sorry.
>>> Never mind the fact that he maintains the C FAQ list. Never mind that he
>>> is a published author in his own right. Let us instead turn to W Richard
>>> Stevens, author of "Unix Network Programming", the definitive work on
>>> the subject. The second edition of this book is divided into two
>>> volumes. In the first of these, the Acknowledgements section lists
>>> thirteen people who "answered email questions of mine, sometimes lots of
>>> questions, which improved the accuracy and presentation of the text".
>>> Two of the thirteen names on this list are Brian Kernighan and Dennis
>>> Ritchie, which makes it a rather special list in a rather special book.
>>> And another of those thirteen names is... Steve Summit.
>>>
>>
>> Maintaining an FAQ (there are many out there) list means nothing.
>
> It means a lot when its contributors include Henry Spencer, Eric
> Raymond, Doug Gwyn (check your K&R acknowledgements), Mark Brader, Larry
> Jones, Peter Seebach, Dan Pop, Clive Feather, Lawrence Kirby, Bob Stout,
> Andrew Koenig, and Chris Torek. You may never have heard of these
> people, but there are plenty here who have.
>
Not really. His pages are not peer reviewed by other experts.
>> And
>> he has published little when compared to the organizations I sited.
>
> On the other hand, his publications (although presumably not perfect)
> are not riddled with errors. But wait! I should justify "riddled" at
> least a little bit. So here are a few errors spotted at random.
>
> If I can go back to that Chapter 2 thing by the Hawai'i guys for a
> moment, they call scanf immediately after a printf prompt with no
> newline and no explicit flush, so the prompt may not appear before the
> program blocks for input. They fail to return a value from main(), so
> the termination status is undefined (not exactly an error, but not
> exactly bright, either). In Chapter 6, they have this code:
>
From 1993, I would say it worked on their system. And termination
status isn't important if you don't set normal/error responses.
> main()
> { int x;
> int iptr;
>
> printf("***Testing Pointer Variables***\n");
> x = 10;
> iptr = &x;
> printf("%d\n",iptr);
> }
>
> I guess they forgot to compile that one.
>
Did you check the errata? Every book I've ever seen has some errors.
> In Chapter 14, they claim that malloc is prototyped not only in
> <stdlib.h> (which is correct) but also in <alloc.h> (which the Standard
> doesn't even define!). In their example program, the return value of
> malloc is routinely cast (which is poor style). What's more, the program
> uses gets()!
>
There was an alloc.h in the early 90's, and it did contain the prototype
for malloc. As for casting the return type from malloc - that is a
style (one I agree with, BTW).
> Are you seriously holding these guys up as shining examples of C expertise?
>
A whole lot more than I do you.
> This next one isn't actually an error from my point of view, but it
> might be from yours. In Chapter 5, where they spend rather more time on
> precedence than in Chapter 2, they list the function call operator as
> having the highest precedence. Since you don't think that there is any
> such operator, no doubt you will consider this an error. But who are
> you, to disagree with somebody from a real live university? (Your
> argument, not mine.)
>
As I said in another update, I will agree there is a function operator -
although it isn't generally considered an operator.
>> I've been referenced in books before also. It's no big thing.
>
> I can't seem to find you anywhere. Perhaps you could name the book that
> acknowledges you.
>
I really don't care if you do or not.
>>
>>> Claiming that Steve Summit is not respected is almost like claiming that
>>> Chris Torek is not respected.
>>>
>>
>> He is a single individual, and not nearly as well known or respected as
>> the organizations I referenced.
>
> I would argue that he is both vastly better-known and much more highly
> respected as a C programmer than any of the authors of those pages. Do
> you actually know any of the authors of the pages you cited? Do you know
> what C credentials they have (other than being the authors of some
> spectacular bugs)?
>
You can argue all you want. You only show your depth of stoopidity.
>> Now how about someone who is really respected? And not by just a few
>> programmers.
>
> ISO/IEC 9899. We've been here before.
>
Yes, and you can't quote the standard to prove your understanding of the
standard is correct.
Show me any site from an independent, reputable source that supports
your claim. A copy of the standard does not support your
interpretation. And a site run by a single person with no peer review
is not reliable. Major developers, scientific organizations with peer
review, universities and so on are reputable.
But you can't, can you?
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-28 04:45 +0000 |
| Message-ID | <o92v4u$9ic$1@dont-email.me> |
| In reply to | #105014 |
On 28/02/17 04:20, Jerry Stuckle wrote:
> On 2/27/2017 9:27 PM, Richard Heathfield wrote:
>> On 28/02/17 00:44, Jerry Stuckle wrote:
>>> On 2/27/2017 7:35 PM, Richard Heathfield wrote:
>>
>> <snip>
>>
>>>> The idea that Steve Summit is unknown or not respected is laughable.
>>>>
>>>
>>> No, he is an individual,
>>
>> So is everybody.
>>
>>> and not as well known or respected as Purdue
>>> University, University of Hawaii or Microsoft. Sorry.
>>
>> Universities don't write Web pages. /People/ write Web pages. Can you
>> name the people who wrote those reference materials you cited? We have
>> no idea who they are. So how do you know you can respect them?
>>
>
> That is correct. But universities don't just allow anyone to write
> their pages. Content like this must be reviewed .
It's a shame they didn't do a better job, then.
>
>> <https://web.ics.purdue.edu/~cs240/misc/operators.html> - author
>> unknown. Contains errors.
>>
>
> So YOU say. The experts at Purdue disagree, or the page would not be there.
The experts at Purdue need to take a closer look, then.
<snip>
> And it's not just one professor who reviews the information.
So they have more than one professor who doesn't know C as well as they
might. So what?
> However,
> even if that weren't the case, I would trust the knowledge of a
> University Professor over anyone here - especially when that professor
> agrees with other recognized experts.
That's perfectly understandable, but in fact professors can make
mistakes, and many do. This is not a matter of opinion. This is a matter
of professors (or whoever writes those pages) failing to understand the
C Standard.
>
>> Okay, students aren't noted for their objectivity where teaching staff
>> are concerned. But what else do we have to go on? The guy is totally
>> unknown. The only reference I could find to him online other than
>> ratings sites and the Purdue site was in a CV from one of his former
>> students, with whom he has co-written a number of papers, none of them
>> on the C language.
>>
>
> So what? Peer review says a lot.
It says that whoever did the peer review hadn't read (or hadn't
understood) the Standard.
>> <https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html> -
>> author may be unknown. Contains errors.
>>
>> Ah, but we /might/ be able to ascribe this one. If we click "up" a
>> couple of times, we find these names:
>>
>> Bharat Kinariwala and Tep Dobry
>>
>> These guys wrote a book called "Programming in C", back in 1993, which
>> is available online. The C doesn't kick off until Chapter 2 (in which,
>> by the way, the mistaken interpretation of precedence is repeated). And
>> *every single program* in that chapter exhibits undefined behaviour,
>> because of 4.1.6 of the ANSI C Standard (probably 7.1.6 of C90 -
>> remember, this book was published in 1993, so it must be judged by the
>> language definition pertaining at the time), which says that "If a
>> function that accepts a variable number of arguments is not declared
>> (explicitly or by including its associated header), the behavior is
>> undefined."
>>
>> If they don't even know they have to include <stdio.h> before calling
>> printf, I'm not about to trust their views on operator precedence.
>>
>
> Once again, universities review content like this before it is posted on
> their site. And this information agrees with the others.
That doesn't make it correct.
>> I'd rather trust Steve Summit. At least he knows about <stdio.h>
>>
>
> One person, not peer reviewed. Sorry.
Steve Summit not peer reviewed? Are you serious? Steve Summit's FAQ
pages have been reviewed by many hundreds of programmers, including
several members of the ISO C Committee (Larry Jones, Clive Feather, Doug
Gwyn, and Peter Seebach, to name but four). I'd take a peer review by
acknowledged experts such as those guys over some anonymous professor
/any/ day. Nevertheless, peer review doesn't trump the Standard. If
Steve Summit's C FAQ is wrong in any respect, *show* me where it's
wrong, just as you've been shown where your university pages are wrong.
>> <https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx>
>>
>> Author unknown. But maybe it's the same guy who wrote this:
>>
>> <https://msdn.microsoft.com/en-us/library/4bftz997.aspx>
>>
>
> You're guessing, aren't you.
Of course. The pages are anonymous, so we don't know who wrote them. But
whoever wrote the ones we've been looking at did not know C as well as
he (or she, or they) should have done.
> And Microsoft doesn't let just anyone post
> pages like this on their site, either. It is a group effort.
You mean it took /several/ people to put all those bugs into the
recursion example? Okay...
>> I'd rather trust Steve Summit. At least he knows about base cases, and
>> he knows how to write a condition properly.
>>
>
> One person, not peer reviewed. Sorry.
One person, heavily peer reviewed.
>>>> Never mind the fact that he maintains the C FAQ list. Never mind that he
>>>> is a published author in his own right. Let us instead turn to W Richard
>>>> Stevens, author of "Unix Network Programming", the definitive work on
>>>> the subject. The second edition of this book is divided into two
>>>> volumes. In the first of these, the Acknowledgements section lists
>>>> thirteen people who "answered email questions of mine, sometimes lots of
>>>> questions, which improved the accuracy and presentation of the text".
>>>> Two of the thirteen names on this list are Brian Kernighan and Dennis
>>>> Ritchie, which makes it a rather special list in a rather special book.
>>>> And another of those thirteen names is... Steve Summit.
>>>>
>>>
>>> Maintaining an FAQ (there are many out there) list means nothing.
>>
>> It means a lot when its contributors include Henry Spencer, Eric
>> Raymond, Doug Gwyn (check your K&R acknowledgements), Mark Brader, Larry
>> Jones, Peter Seebach, Dan Pop, Clive Feather, Lawrence Kirby, Bob Stout,
>> Andrew Koenig, and Chris Torek. You may never have heard of these
>> people, but there are plenty here who have.
>>
>
> Not really. His pages are not peer reviewed by other experts.
You don't call Doug Gwyn a C expert? Or Henry Spencer? Or Clive Feather?
Or Lawrence Kirby? Or Chris Torek? Are you from another planet?
>>> And
>>> he has published little when compared to the organizations I sited.
>>
>> On the other hand, his publications (although presumably not perfect)
>> are not riddled with errors. But wait! I should justify "riddled" at
>> least a little bit. So here are a few errors spotted at random.
>>
>> If I can go back to that Chapter 2 thing by the Hawai'i guys for a
>> moment, they call scanf immediately after a printf prompt with no
>> newline and no explicit flush, so the prompt may not appear before the
>> program blocks for input. They fail to return a value from main(), so
>> the termination status is undefined (not exactly an error, but not
>> exactly bright, either). In Chapter 6, they have this code:
>>
>
> From 1993, I would say it worked on their system.
Yes, I'm sure it did. But "it worked on their system" and "correct" are
two very different things.
And termination
> status isn't important if you don't set normal/error responses.
>
>
>> main()
>> { int x;
>> int iptr;
>>
>> printf("***Testing Pointer Variables***\n");
>> x = 10;
>> iptr = &x;
>> printf("%d\n",iptr);
>> }
>>
>> I guess they forgot to compile that one.
>>
>
> Did you check the errata? Every book I've ever seen has some errors.
That's a perfectly reasonable point. (About bloody time.) Okay, let's
find out whether there are any errata. Well, I couldn't find any. But
you'd think that in an online book they would update the soft copy with
any corrections. They clearly haven't done that.
>
>> In Chapter 14, they claim that malloc is prototyped not only in
>> <stdlib.h> (which is correct) but also in <alloc.h> (which the Standard
>> doesn't even define!). In their example program, the return value of
>> malloc is routinely cast (which is poor style). What's more, the program
>> uses gets()!
>>
>
> There was an alloc.h in the early 90's, and it did contain the prototype
> for malloc.
Not in C, not in the early 90's. In particular implementations of C,
perhaps, as an extension - but not in the core language.
> As for casting the return type from malloc - that is a
> style (one I agree with, BTW).
Why doesn't that surprise me?
>> Are you seriously holding these guys up as shining examples of C expertise?
>>
>
> A whole lot more than I do you.
This isn't about me. This is about what is and what is not correct C.
The Web sites you have held up as examples are written by human beings,
and human beings make mistakes, and these people have written incorrect
stuff about what precedence means.
>
>> This next one isn't actually an error from my point of view, but it
>> might be from yours. In Chapter 5, where they spend rather more time on
>> precedence than in Chapter 2, they list the function call operator as
>> having the highest precedence. Since you don't think that there is any
>> such operator, no doubt you will consider this an error. But who are
>> you, to disagree with somebody from a real live university? (Your
>> argument, not mine.)
>>
>
> As I said in another update, I will agree there is a function operator -
> although it isn't generally considered an operator.
Maybe not by you. But those of us who base our understanding of C on the
definition of C are perfectly ready to consider the function call
operator to be an operator.
>>> I've been referenced in books before also. It's no big thing.
>>
>> I can't seem to find you anywhere. Perhaps you could name the book that
>> acknowledges you.
>>
>
> I really don't care if you do or not.
So it's just another unsubstantiated assertion to add to your long list.
And, like all unsubstantiated assertions, it can be disregarded.
<"stoopidity" jibe snipped>
>>> Now how about someone who is really respected? And not by just a few
>>> programmers.
>>
>> ISO/IEC 9899. We've been here before.
>>
>
> Yes, and you can't quote the standard to prove your understanding of the
> standard is correct.
Oh, but I can. 6.5(3): "The grouping of operators and operands is
indicated by the syntax. Except as specified later, side effects and
value computations of subexpressions are unsequenced."
Job done.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-28 17:57 +1300 |
| Message-ID | <ehkeaaFmgnfU3@mid.individual.net> |
| In reply to | #105026 |
On 02/28/17 05:45 PM, Richard Heathfield wrote: > > You don't call Doug Gwyn a C expert? Or Henry Spencer? Or Clive Feather? > Or Lawrence Kirby? Or Chris Torek? Are you from another planet? Nailed it! :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-28 11:27 +0100 |
| Message-ID | <20170228112724.f7673d3d73040ca2a83363d5@gmail.com> |
| In reply to | #105029 |
On Tue, 28 Feb 2017 17:57:46 +1300 Ian Collins <ian-news@hotmail.com> wrote: > Nailed it! Not really. Collective work doesn't mean all contributors own the full expertise... that's why univerties people fail to make things by themselves and need to be grouped like sheeps. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 13:06 -0500 |
| Message-ID | <o94e28$2ap$1@jstuckle.eternal-september.org> |
| In reply to | #105026 |
On 2/27/2017 11:45 PM, Richard Heathfield wrote:
> On 28/02/17 04:20, Jerry Stuckle wrote:
>> On 2/27/2017 9:27 PM, Richard Heathfield wrote:
>>> On 28/02/17 00:44, Jerry Stuckle wrote:
>>>> On 2/27/2017 7:35 PM, Richard Heathfield wrote:
>>>
>>> <snip>
>>>
>>>>> The idea that Steve Summit is unknown or not respected is laughable.
>>>>>
>>>>
>>>> No, he is an individual,
>>>
>>> So is everybody.
>>>
>>>> and not as well known or respected as Purdue
>>>> University, University of Hawaii or Microsoft. Sorry.
>>>
>>> Universities don't write Web pages. /People/ write Web pages. Can you
>>> name the people who wrote those reference materials you cited? We have
>>> no idea who they are. So how do you know you can respect them?
>>>
>>
>> That is correct. But universities don't just allow anyone to write
>> their pages. Content like this must be reviewed .
>
> It's a shame they didn't do a better job, then.
>
So, there are a couple of typos from the guy who entered the web page.
That does not make the content invalid.
>>
>>> <https://web.ics.purdue.edu/~cs240/misc/operators.html> - author
>>> unknown. Contains errors.
>>>
>>
>> So YOU say. The experts at Purdue disagree, or the page would not be
>> there.
>
> The experts at Purdue need to take a closer look, then.
>
Maybe you can change their minds.
> <snip>
>
>> And it's not just one professor who reviews the information.
>
> So they have more than one professor who doesn't know C as well as they
> might. So what?
>
Or a bunch of professors who know it a lot better than you do. Much
more likely.
>> However,
>> even if that weren't the case, I would trust the knowledge of a
>> University Professor over anyone here - especially when that professor
>> agrees with other recognized experts.
>
> That's perfectly understandable, but in fact professors can make
> mistakes, and many do. This is not a matter of opinion. This is a matter
> of professors (or whoever writes those pages) failing to understand the
> C Standard.
>
Much more likely is YOUR inability to understand the C standard. It
isn't just professors at one university. Many other experts around the
world agree with them. I just posted three, but even your GNU C
compiler documents say the same thing:
https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Operator-Precedence
In case you have trouble finding it, it's Section 3.19.
But you have yet to post documentation from an independent, respected
source which supports your position. If you're correct, then it should
be quite easy.
>>
>>> Okay, students aren't noted for their objectivity where teaching staff
>>> are concerned. But what else do we have to go on? The guy is totally
>>> unknown. The only reference I could find to him online other than
>>> ratings sites and the Purdue site was in a CV from one of his former
>>> students, with whom he has co-written a number of papers, none of them
>>> on the C language.
>>>
>>
>> So what? Peer review says a lot.
>
> It says that whoever did the peer review hadn't read (or hadn't
> understood) the Standard.
>
Or it says they are right and YOU are wrong.
>>> <https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html> -
>>> author may be unknown. Contains errors.
>>>
>>> Ah, but we /might/ be able to ascribe this one. If we click "up" a
>>> couple of times, we find these names:
>>>
>>> Bharat Kinariwala and Tep Dobry
>>>
>>> These guys wrote a book called "Programming in C", back in 1993, which
>>> is available online. The C doesn't kick off until Chapter 2 (in which,
>>> by the way, the mistaken interpretation of precedence is repeated). And
>>> *every single program* in that chapter exhibits undefined behaviour,
>>> because of 4.1.6 of the ANSI C Standard (probably 7.1.6 of C90 -
>>> remember, this book was published in 1993, so it must be judged by the
>>> language definition pertaining at the time), which says that "If a
>>> function that accepts a variable number of arguments is not declared
>>> (explicitly or by including its associated header), the behavior is
>>> undefined."
>>>
>>> If they don't even know they have to include <stdio.h> before calling
>>> printf, I'm not about to trust their views on operator precedence.
>>>
>>
>> Once again, universities review content like this before it is posted on
>> their site. And this information agrees with the others.
>
> That doesn't make it correct.
>
It makes it more correct than your opinion.
>>> I'd rather trust Steve Summit. At least he knows about <stdio.h>
>>>
>>
>> One person, not peer reviewed. Sorry.
>
> Steve Summit not peer reviewed? Are you serious? Steve Summit's FAQ
> pages have been reviewed by many hundreds of programmers, including
> several members of the ISO C Committee (Larry Jones, Clive Feather, Doug
> Gwyn, and Peter Seebach, to name but four). I'd take a peer review by
> acknowledged experts such as those guys over some anonymous professor
> /any/ day. Nevertheless, peer review doesn't trump the Standard. If
> Steve Summit's C FAQ is wrong in any respect, *show* me where it's
> wrong, just as you've been shown where your university pages are wrong.
>
So? He has an FAQ. You claim it has been peer reviewed by several
members of the ISO C Committee, but provide no proof of that. An empty
claim.
Let's see you show proof by an independent, well-respected source. One
person, even if his name is Steve Summit, is one person. I provided
three (now 4) sources to back me up - all from respected organizations.
>>> <https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx>
>>>
>>> Author unknown. But maybe it's the same guy who wrote this:
>>>
>>> <https://msdn.microsoft.com/en-us/library/4bftz997.aspx>
>>>
>>
>> You're guessing, aren't you.
>
> Of course. The pages are anonymous, so we don't know who wrote them. But
> whoever wrote the ones we've been looking at did not know C as well as
> he (or she, or they) should have done.
>
Or maybe they know C much better than you do. That is much more likely,
especially when there are thousands of sites from respected
organizations which agree with them.
>> And Microsoft doesn't let just anyone post
>> pages like this on their site, either. It is a group effort.
>
> You mean it took /several/ people to put all those bugs into the
> recursion example? Okay...
>
No bugs. That provides a simplified example to get a point across.
That's exactly what it does. It is very common to have code like this
in courseware.
>>> I'd rather trust Steve Summit. At least he knows about base cases, and
>>> he knows how to write a condition properly.
>>>
>>
>> One person, not peer reviewed. Sorry.
>
> One person, heavily peer reviewed.
>
And your proof of the peer review? He is one person. No proof of a
peer review - and no backup to your claims.
>>>>> Never mind the fact that he maintains the C FAQ list. Never mind
>>>>> that he
>>>>> is a published author in his own right. Let us instead turn to W
>>>>> Richard
>>>>> Stevens, author of "Unix Network Programming", the definitive work on
>>>>> the subject. The second edition of this book is divided into two
>>>>> volumes. In the first of these, the Acknowledgements section lists
>>>>> thirteen people who "answered email questions of mine, sometimes
>>>>> lots of
>>>>> questions, which improved the accuracy and presentation of the text".
>>>>> Two of the thirteen names on this list are Brian Kernighan and Dennis
>>>>> Ritchie, which makes it a rather special list in a rather special
>>>>> book.
>>>>> And another of those thirteen names is... Steve Summit.
>>>>>
>>>>
>>>> Maintaining an FAQ (there are many out there) list means nothing.
>>>
>>> It means a lot when its contributors include Henry Spencer, Eric
>>> Raymond, Doug Gwyn (check your K&R acknowledgements), Mark Brader, Larry
>>> Jones, Peter Seebach, Dan Pop, Clive Feather, Lawrence Kirby, Bob Stout,
>>> Andrew Koenig, and Chris Torek. You may never have heard of these
>>> people, but there are plenty here who have.
>>>
>>
>> Not really. His pages are not peer reviewed by other experts.
>
> You don't call Doug Gwyn a C expert? Or Henry Spencer? Or Clive Feather?
> Or Lawrence Kirby? Or Chris Torek? Are you from another planet?
>
And your proof that these people have peer reviewed those pages?
>>>> And
>>>> he has published little when compared to the organizations I sited.
>>>
>>> On the other hand, his publications (although presumably not perfect)
>>> are not riddled with errors. But wait! I should justify "riddled" at
>>> least a little bit. So here are a few errors spotted at random.
>>>
>>> If I can go back to that Chapter 2 thing by the Hawai'i guys for a
>>> moment, they call scanf immediately after a printf prompt with no
>>> newline and no explicit flush, so the prompt may not appear before the
>>> program blocks for input. They fail to return a value from main(), so
>>> the termination status is undefined (not exactly an error, but not
>>> exactly bright, either). In Chapter 6, they have this code:
>>>
>>
>> From 1993, I would say it worked on their system.
>
> Yes, I'm sure it did. But "it worked on their system" and "correct" are
> two very different things.
>
It is not always necessary to call flush() after output. It depends on
the library and the OS. Not all buffer output - many of the systems I
work on do not, for instance, because they are highly memory
constrained. And needlessly calling flush() wastes CPU cycles (which
can be important). And if the program is not returning a meaningful set
of return codes, it doesn't matter if main() returns something or not.
Sorry, you are incorrect on both points.
>
> And termination
>> status isn't important if you don't set normal/error responses.
>>
>>
>>> main()
>>> { int x;
>>> int iptr;
>>>
>>> printf("***Testing Pointer Variables***\n");
>>> x = 10;
>>> iptr = &x;
>>> printf("%d\n",iptr);
>>> }
>>>
>>> I guess they forgot to compile that one.
>>>
>>
>> Did you check the errata? Every book I've ever seen has some errors.
>
> That's a perfectly reasonable point. (About bloody time.) Okay, let's
> find out whether there are any errata. Well, I couldn't find any. But
> you'd think that in an online book they would update the soft copy with
> any corrections. They clearly haven't done that.
>
It's not that easy. When a copyright is registered, a copy must be
supplied to the Library of Congress. If there are any changes to the
book (even typo fixes), the book must be copyrighted again. The
original copyright does not carry over.
>>
>>> In Chapter 14, they claim that malloc is prototyped not only in
>>> <stdlib.h> (which is correct) but also in <alloc.h> (which the Standard
>>> doesn't even define!). In their example program, the return value of
>>> malloc is routinely cast (which is poor style). What's more, the program
>>> uses gets()!
>>>
>>
>> There was an alloc.h in the early 90's, and it did contain the prototype
>> for malloc.
>
> Not in C, not in the early 90's. In particular implementations of C,
> perhaps, as an extension - but not in the core language.
>
So? It existed in many compilers:
https://en.wikibooks.org/wiki/C_Programming/Platform_Reference/alloc.h
>> As for casting the return type from malloc - that is a
>> style (one I agree with, BTW).
>
> Why doesn't that surprise me?
>
It's a matter of style. Some people do it, some don't. Just because
you don't doesn't mean there's a problem with it.
Please show me in the standard where it says NOT to cast the return type
of malloc(). If it's so bad, it must be in the standard.
>>> Are you seriously holding these guys up as shining examples of C
>>> expertise?
>>>
>>
>> A whole lot more than I do you.
>
> This isn't about me. This is about what is and what is not correct C.
> The Web sites you have held up as examples are written by human beings,
> and human beings make mistakes, and these people have written incorrect
> stuff about what precedence means.
>
Yes, it is. It is all about your interpretation of the standard vs. the
interpretation of millions of programmers around the world. I posted
three (now four) sites which all say the same thing, from independent,
respected organizations. All you have done is post one site from an
individual.
>>
>>> This next one isn't actually an error from my point of view, but it
>>> might be from yours. In Chapter 5, where they spend rather more time on
>>> precedence than in Chapter 2, they list the function call operator as
>>> having the highest precedence. Since you don't think that there is any
>>> such operator, no doubt you will consider this an error. But who are
>>> you, to disagree with somebody from a real live university? (Your
>>> argument, not mine.)
>>>
>>
>> As I said in another update, I will agree there is a function operator -
>> although it isn't generally considered an operator.
>
> Maybe not by you. But those of us who base our understanding of C on the
> definition of C are perfectly ready to consider the function call
> operator to be an operator.
>
It is not considered such by a lot of programmers.
>>>> I've been referenced in books before also. It's no big thing.
>>>
>>> I can't seem to find you anywhere. Perhaps you could name the book that
>>> acknowledges you.
>>>
>>
>> I really don't care if you do or not.
>
> So it's just another unsubstantiated assertion to add to your long list.
> And, like all unsubstantiated assertions, it can be disregarded.
>
> <"stoopidity" jibe snipped>
>
No, because it doesn't matter.
>>>> Now how about someone who is really respected? And not by just a few
>>>> programmers.
>>>
>>> ISO/IEC 9899. We've been here before.
>>>
>>
>> Yes, and you can't quote the standard to prove your understanding of the
>> standard is correct.
>
> Oh, but I can. 6.5(3): "The grouping of operators and operands is
> indicated by the syntax. Except as specified later, side effects and
> value computations of subexpressions are unsequenced."
>
> Job done.
>
That is your INTERPRETATION. Thousands of experts around the world
disagree with you.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-28 06:26 -0800 |
| Message-ID | <ee952c8f-b959-4809-89dc-015b481f7a80@googlegroups.com> |
| In reply to | #105014 |
On Monday, February 27, 2017 at 11:20:39 PM UTC-5, Jerry Stuckle wrote: > On 2/27/2017 9:27 PM, Richard Heathfield wrote: ... > > Universities don't write Web pages. /People/ write Web pages. Can you > > name the people who wrote those reference materials you cited? We have > > no idea who they are. So how do you know you can respect them? > > > > That is correct. But universities don't just allow anyone to write > their pages. ... True - you generally need to be either faculty or staff. > ... Content like this must be reviewed . You're not employed in academia, are you? It's been a while since I was academic employee, but my wife is. I can tell you from personal experience that there is very little review of such content. No one has the time to spare to perform such reviews - they generally just wait until someone reports a problem. The only reason my wife's work got reviewed is because she went out of her way to ask for a review (and the reviewer was reluctant to spend his time doing so). It occasionally gets reviewed to make sure it contains no offensive content and doesn't violate any laws or university regulations. However, it's generally not reviewed for accuracy. Furthermore, yours is such a widespread misconception that it's entirely possible that there's only one person (and possibly fewer) in any given university CS department that correctly understands the issue. The chance that it will be reviewed for accuracy by that particular person is pretty small.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 13:09 -0500 |
| Message-ID | <o94e8d$34i$1@jstuckle.eternal-september.org> |
| In reply to | #105101 |
On 2/28/2017 9:26 AM, jameskuyper@verizon.net wrote: > On Monday, February 27, 2017 at 11:20:39 PM UTC-5, Jerry Stuckle wrote: >> On 2/27/2017 9:27 PM, Richard Heathfield wrote: > ... >>> Universities don't write Web pages. /People/ write Web pages. Can you >>> name the people who wrote those reference materials you cited? We have >>> no idea who they are. So how do you know you can respect them? >>> >> >> That is correct. But universities don't just allow anyone to write >> their pages. ... > > True - you generally need to be either faculty or staff. > >> ... Content like this must be reviewed . > > You're not employed in academia, are you? It's been a while since I was academic employee, but my wife is. I can tell you from personal experience that there is very little review of such content. No one has the time to spare to perform such reviews - they generally just wait until someone reports a problem. The only reason my wife's work got reviewed is because she went out of her way to ask for a review (and the reviewer was reluctant to spend his time doing so). It occasionally gets reviewed to make sure it contains no offensive content and doesn't violate any laws or university regulations. However, it's generally not reviewed for accuracy. Furthermore, yours is such a widespread misconception that it's entirely possible that there's only one person (and possibly fewer) in any given university CS department that correctly understands the issue. The chance that it will be reviewed for accuracy by that particular person is pretty small. > I'm not currently employed in academics, no. But my wife is a professor. And there is significant review of anything which goes on the university's web site. It isn't just one person putting up a page. Respected institutions review everything before it is published - in paper or on the web. Those which publish things without review are not well respected in the academic community. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-28 17:36 +1300 |
| Message-ID | <ehkd2bFmgnfU1@mid.individual.net> |
| In reply to | #104955 |
On 02/28/17 11:40 AM, Jerry Stuckle wrote: > On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: > >> http://en.cppreference.com/w/c/language/operator_precedence >> "Precedence and associativity are independent from order of evaluation. >> The C language standard doesn't specify operator precedence. It specifies the >> language grammar, and the precedence table is derived from it to simplify >> understanding." >> > > This is a single person - not a respected organization. Hardly the same > as a major university or Microsoft. No it isn't a single person. It is a well respected, frequently reviewed (by many contributors) and referenced site. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 13:10 -0500 |
| Message-ID | <o94eac$34i$2@jstuckle.eternal-september.org> |
| In reply to | #105022 |
On 2/27/2017 11:36 PM, Ian Collins wrote: > On 02/28/17 11:40 AM, Jerry Stuckle wrote: >> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >> >>> http://en.cppreference.com/w/c/language/operator_precedence >>> "Precedence and associativity are independent from order of evaluation. >>> The C language standard doesn't specify operator precedence. It >>> specifies the >>> language grammar, and the precedence table is derived from it to >>> simplify >>> understanding." >>> >> >> This is a single person - not a respected organization. Hardly the same >> as a major university or Microsoft. > > No it isn't a single person. It is a well respected, frequently > reviewed (by many contributors) and referenced site. > Your proof that it has been reviewed by many contributors? And if your claims are true, you should be able to come up with lots of sites which say the same thing. Sites from respected organizations. I can come up with lots of them. Why can't you? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-01 07:28 +1300 |
| Message-ID | <ehltpiF60oU1@mid.individual.net> |
| In reply to | #105126 |
On 03/ 1/17 07:10 AM, Jerry Stuckle wrote: > On 2/27/2017 11:36 PM, Ian Collins wrote: >> On 02/28/17 11:40 AM, Jerry Stuckle wrote: >>> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >>> >>>> http://en.cppreference.com/w/c/language/operator_precedence >>>> "Precedence and associativity are independent from order of evaluation. >>>> The C language standard doesn't specify operator precedence. It >>>> specifies the >>>> language grammar, and the precedence table is derived from it to >>>> simplify >>>> understanding." >>>> >>> >>> This is a single person - not a respected organization. Hardly the same >>> as a major university or Microsoft. >> >> No it isn't a single person. It is a well respected, frequently >> reviewed (by many contributors) and referenced site. >> > > Your proof that it has been reviewed by many contributors? The edit history. > And if your claims are true, you should be able to come up with lots of > sites which say the same thing. Sites from respected organizations. > > I can come up with lots of them. Why can't you? There's no need, the standard is good enough. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 15:49 -0500 |
| Message-ID | <o94nld$4g2$9@jstuckle.eternal-september.org> |
| In reply to | #105133 |
On 2/28/2017 1:28 PM, Ian Collins wrote: > On 03/ 1/17 07:10 AM, Jerry Stuckle wrote: >> On 2/27/2017 11:36 PM, Ian Collins wrote: >>> On 02/28/17 11:40 AM, Jerry Stuckle wrote: >>>> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >>>> >>>>> http://en.cppreference.com/w/c/language/operator_precedence >>>>> "Precedence and associativity are independent from order of >>>>> evaluation. >>>>> The C language standard doesn't specify operator precedence. It >>>>> specifies the >>>>> language grammar, and the precedence table is derived from it to >>>>> simplify >>>>> understanding." >>>>> >>>> >>>> This is a single person - not a respected organization. Hardly the >>>> same >>>> as a major university or Microsoft. >>> >>> No it isn't a single person. It is a well respected, frequently >>> reviewed (by many contributors) and referenced site. >>> >> >> Your proof that it has been reviewed by many contributors? > > The edit history. > >> And if your claims are true, you should be able to come up with lots of >> sites which say the same thing. Sites from respected organizations. >> >> I can come up with lots of them. Why can't you? > > There's no need, the standard is good enough. > "No need" because you can't come up with any independent, respected source which supports your incorrect interpretation of the standard. You guys are hopeless. I'm tired of trying to teach the pigs to sing. I've quoted multiple independent, respected resources and you've argued with every one of them. No wonder the real experts on the C language left this group long ago. You spend so much time trying to count the hairs on a gnat's ass tat you fail to see the dog it's sitting on. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-01 14:30 +1300 |
| Message-ID | <ehmmi3F60pU4@mid.individual.net> |
| In reply to | #105168 |
On 03/ 1/17 09:49 AM, Jerry Stuckle wrote: > On 2/28/2017 1:28 PM, Ian Collins wrote: >> On 03/ 1/17 07:10 AM, Jerry Stuckle wrote: >>> On 2/27/2017 11:36 PM, Ian Collins wrote: >>>> On 02/28/17 11:40 AM, Jerry Stuckle wrote: >>>>> On 2/27/2017 4:26 PM, jameskuyper@verizon.net wrote: >>>>> >>>>>> http://en.cppreference.com/w/c/language/operator_precedence >>>>>> "Precedence and associativity are independent from order of >>>>>> evaluation. >>>>>> The C language standard doesn't specify operator precedence. It >>>>>> specifies the >>>>>> language grammar, and the precedence table is derived from it to >>>>>> simplify >>>>>> understanding." >>>>>> >>>>> >>>>> This is a single person - not a respected organization. Hardly the >>>>> same >>>>> as a major university or Microsoft. >>>> >>>> No it isn't a single person. It is a well respected, frequently >>>> reviewed (by many contributors) and referenced site. >>>> >>> >>> Your proof that it has been reviewed by many contributors? >> >> The edit history. >> >>> And if your claims are true, you should be able to come up with lots of >>> sites which say the same thing. Sites from respected organizations. >>> >>> I can come up with lots of them. Why can't you? >> >> There's no need, the standard is good enough. >> > > "No need" because you can't come up with any independent, respected > source which supports your incorrect interpretation of the standard. cppreference.com is an independent, respected source which supports our correct interpretation of the standard. -- Ian
[toc] | [prev] | [next] | [standalone]
Page 26 of 27 — ← Prev page 1 … 24 25 [26] 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web