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 25 of 27 — ← Prev page 1 … 23 24 [25] 26 27 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 12:36 -0500 |
| Message-ID | <o94cbe$rq8$1@jstuckle.eternal-september.org> |
| In reply to | #105034 |
On 2/28/2017 12:22 AM, Richard Heathfield wrote: > On 28/02/17 05:09, Jerry Stuckle wrote: > <snip> > >> This is more than "a table to help the students...". It is part of >> their public site. And being public, it was peer-reviewed before being >> published. It looks like the problem with sizeof was caused by the >> person who actually keyed in the page and wasn't caught. > > You see, they /can/ make mistakes. Now, a quick question for you. Since > these Universities are normally so careful, would I be right in saying > that they exercise great care in selecting external sites that offer > further advice on C? > > For example, if a reliable, reputable, respected University's reliable, > reputable, respected and peer-reviewed C pages cite <X> as being a > usefull [sic] document, would you consider <X> to be a reliable, > reputable, respected, peer-reviewed site? > Yes, they can make typos. But the concept is still there, and other than a minor typo or two, it is correct. As for selecting external sites - I have no idea what you are talking about. And you have yet to provide any documentation from an independent, respected organization which supports your interpretation. If you are so correct, it should be quite easy. So instead of trying to argue an independent, respected university is incorrect (a losing argument), prove your position is correct. Show the documentation. But you can't, because it doesn't exist. Because you are wrong. Even your precious GNU compiler says the same thing: https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Operator-Precedence -- ================== 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 18:10 +0000 |
| Message-ID | <o94eao$3ff$1@dont-email.me> |
| In reply to | #105119 |
On 28/02/17 17:36, Jerry Stuckle wrote: > On 2/28/2017 12:22 AM, Richard Heathfield wrote: >> On 28/02/17 05:09, Jerry Stuckle wrote: >> <snip> >> >>> This is more than "a table to help the students...". It is part of >>> their public site. And being public, it was peer-reviewed before being >>> published. It looks like the problem with sizeof was caused by the >>> person who actually keyed in the page and wasn't caught. >> >> You see, they /can/ make mistakes. Now, a quick question for you. Since >> these Universities are normally so careful, would I be right in saying >> that they exercise great care in selecting external sites that offer >> further advice on C? >> >> For example, if a reliable, reputable, respected University's reliable, >> reputable, respected and peer-reviewed C pages cite <X> as being a >> usefull [sic] document, would you consider <X> to be a reliable, >> reputable, respected, peer-reviewed site? >> > > Yes, they can make typos. But the concept is still there, and other > than a minor typo or two, it is correct. > > As for selecting external sites - I have no idea what you are talking about. I realise that. Nevertheless, would you agree that a well-respected and apparently almost infallible University would never dream of linking to an external site for the benefit of their C students unless that site were as reliable, reputable, respected, and peer-reviewed as the University site itself? If not, isn't that a dereliction of their duty? > > And you have yet to provide any documentation from an independent, > respected organization which supports your interpretation. If you are > so correct, it should be quite easy. Well, I have already cited the Standard, which is the most authoritative source that exists, so I see no reason to do any further work in that direction. BUT... since you mention > https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Operator-Precedence ..., I have now read that page, and I've posted a reply (just a few moments ago) in which I show how that gcc page agrees with me, with James, and with anyone else who's been arguing the toss with you over this - and, far more importantly, that it agrees *with the Standard*. -- 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-28 13:35 -0500 |
| Message-ID | <o94fp3$8c4$2@jstuckle.eternal-september.org> |
| In reply to | #105127 |
On 2/28/2017 1:10 PM, Richard Heathfield wrote: > On 28/02/17 17:36, Jerry Stuckle wrote: >> On 2/28/2017 12:22 AM, Richard Heathfield wrote: >>> On 28/02/17 05:09, Jerry Stuckle wrote: >>> <snip> >>> >>>> This is more than "a table to help the students...". It is part of >>>> their public site. And being public, it was peer-reviewed before being >>>> published. It looks like the problem with sizeof was caused by the >>>> person who actually keyed in the page and wasn't caught. >>> >>> You see, they /can/ make mistakes. Now, a quick question for you. Since >>> these Universities are normally so careful, would I be right in saying >>> that they exercise great care in selecting external sites that offer >>> further advice on C? >>> >>> For example, if a reliable, reputable, respected University's reliable, >>> reputable, respected and peer-reviewed C pages cite <X> as being a >>> usefull [sic] document, would you consider <X> to be a reliable, >>> reputable, respected, peer-reviewed site? >>> >> >> Yes, they can make typos. But the concept is still there, and other >> than a minor typo or two, it is correct. >> >> As for selecting external sites - I have no idea what you are talking >> about. > > I realise that. Nevertheless, would you agree that a well-respected and > apparently almost infallible University would never dream of linking to > an external site for the benefit of their C students unless that site > were as reliable, reputable, respected, and peer-reviewed as the > University site itself? If not, isn't that a dereliction of their duty? > I will not agree or disagree with a hypothetical example that is meaningless. >> >> And you have yet to provide any documentation from an independent, >> respected organization which supports your interpretation. If you are >> so correct, it should be quite easy. > > Well, I have already cited the Standard, which is the most authoritative > source that exists, so I see no reason to do any further work in that > direction. BUT... since you mention > And no documentation from an independent, well-respected source to back up your interpretation. If you are so right, it should be quite easy to find thousands of such sites. I can find them to back up my point. Why can't you? >> https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Operator-Precedence >> > > ..., I have now read that page, and I've posted a reply (just a few > moments ago) in which I show how that gcc page agrees with me, with > James, and with anyone else who's been arguing the toss with you over > this - and, far more importantly, that it agrees *with the Standard*. > And I responded to show how wrong you are. -- ================== 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 18:56 +0000 |
| Message-ID | <o94h13$d7q$1@dont-email.me> |
| In reply to | #105136 |
On 28/02/17 18:35, Jerry Stuckle wrote: > On 2/28/2017 1:10 PM, Richard Heathfield wrote: >> On 28/02/17 17:36, Jerry Stuckle wrote: >>> On 2/28/2017 12:22 AM, Richard Heathfield wrote: >>>> On 28/02/17 05:09, Jerry Stuckle wrote: >>>> <snip> >>>> >>>>> This is more than "a table to help the students...". It is part of >>>>> their public site. And being public, it was peer-reviewed before being >>>>> published. It looks like the problem with sizeof was caused by the >>>>> person who actually keyed in the page and wasn't caught. >>>> >>>> You see, they /can/ make mistakes. Now, a quick question for you. Since >>>> these Universities are normally so careful, would I be right in saying >>>> that they exercise great care in selecting external sites that offer >>>> further advice on C? >>>> >>>> For example, if a reliable, reputable, respected University's reliable, >>>> reputable, respected and peer-reviewed C pages cite <X> as being a >>>> usefull [sic] document, would you consider <X> to be a reliable, >>>> reputable, respected, peer-reviewed site? >>>> >>> >>> Yes, they can make typos. But the concept is still there, and other >>> than a minor typo or two, it is correct. >>> >>> As for selecting external sites - I have no idea what you are talking >>> about. >> >> I realise that. Nevertheless, would you agree that a well-respected and >> apparently almost infallible University would never dream of linking to >> an external site for the benefit of their C students unless that site >> were as reliable, reputable, respected, and peer-reviewed as the >> University site itself? If not, isn't that a dereliction of their duty? >> > > I will not agree or disagree with a hypothetical example that is > meaningless. It is neither hypothetical nor meaningless. Do you trust the University to provide good links on its Web pages? If you don't, then why would you trust anything else they do? <snip> -- 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-28 15:46 -0500 |
| Message-ID | <o94ng2$4g2$7@jstuckle.eternal-september.org> |
| In reply to | #105140 |
On 2/28/2017 1:56 PM, Richard Heathfield wrote: > On 28/02/17 18:35, Jerry Stuckle wrote: >> On 2/28/2017 1:10 PM, Richard Heathfield wrote: >>> On 28/02/17 17:36, Jerry Stuckle wrote: >>>> On 2/28/2017 12:22 AM, Richard Heathfield wrote: >>>>> On 28/02/17 05:09, Jerry Stuckle wrote: >>>>> <snip> >>>>> >>>>>> This is more than "a table to help the students...". It is part of >>>>>> their public site. And being public, it was peer-reviewed before >>>>>> being >>>>>> published. It looks like the problem with sizeof was caused by the >>>>>> person who actually keyed in the page and wasn't caught. >>>>> >>>>> You see, they /can/ make mistakes. Now, a quick question for you. >>>>> Since >>>>> these Universities are normally so careful, would I be right in saying >>>>> that they exercise great care in selecting external sites that offer >>>>> further advice on C? >>>>> >>>>> For example, if a reliable, reputable, respected University's >>>>> reliable, >>>>> reputable, respected and peer-reviewed C pages cite <X> as being a >>>>> usefull [sic] document, would you consider <X> to be a reliable, >>>>> reputable, respected, peer-reviewed site? >>>>> >>>> >>>> Yes, they can make typos. But the concept is still there, and other >>>> than a minor typo or two, it is correct. >>>> >>>> As for selecting external sites - I have no idea what you are talking >>>> about. >>> >>> I realise that. Nevertheless, would you agree that a well-respected and >>> apparently almost infallible University would never dream of linking to >>> an external site for the benefit of their C students unless that site >>> were as reliable, reputable, respected, and peer-reviewed as the >>> University site itself? If not, isn't that a dereliction of their duty? >>> >> >> I will not agree or disagree with a hypothetical example that is >> meaningless. > > It is neither hypothetical nor meaningless. Do you trust the University > to provide good links on its Web pages? If you don't, then why would you > trust anything else they do? > > <snip> > As I said. I will not agree or disagree with a hypothetical example that is meaningless. Period. 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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-02-28 19:39 +0000 |
| Message-ID | <87tw7eyuil.fsf@gmail.com> |
| In reply to | #105034 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 28/02/17 05:09, Jerry Stuckle wrote: > <snip> > >> This is more than "a table to help the students...". It is part of >> their public site. And being public, it was peer-reviewed before being >> published. It looks like the problem with sizeof was caused by the >> person who actually keyed in the page and wasn't caught. > > You see, they /can/ make mistakes. I speak from personal experience - anyone who says that faculty web pages and course notes are reviewed, peer reviewed, or even approved by the institution at large -- or even a line manager in most cases -- is an idiot, who has literally no idea how universities actually work. Mind you, anyone attempting to use facts and rational argument to change Jerry Stuckle's mind about anything is also an idiot.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 15:48 -0500 |
| Message-ID | <o94nji$4g2$8@jstuckle.eternal-september.org> |
| In reply to | #105149 |
On 2/28/2017 2:39 PM, Gareth Owen wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 28/02/17 05:09, Jerry Stuckle wrote: >> <snip> >> >>> This is more than "a table to help the students...". It is part of >>> their public site. And being public, it was peer-reviewed before being >>> published. It looks like the problem with sizeof was caused by the >>> person who actually keyed in the page and wasn't caught. >> >> You see, they /can/ make mistakes. > > I speak from personal experience - anyone who says that faculty web > pages and course notes are reviewed, peer reviewed, or even approved by > the institution at large -- or even a line manager in most cases -- is > an idiot, who has literally no idea how universities actually work. > > Mind you, anyone attempting to use facts and rational argument to change > Jerry Stuckle's mind about anything is also an idiot. > I speak from personal experience also, and with a wife who currently is a professor. Respected universities review everything that is made public. And anyone who thinks otherwise is an idiot - and if you have experience with a university that doesn't do that, they get very little respect from other academic institutions. 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-28 10:46 +0000 |
| Message-ID | <87varupp91.fsf@bsb.me.uk> |
| In reply to | #105032 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/27/2017 8:29 PM, Ben Bacarisse wrote: <snip> >> Anyway, the fact that that page has errors is incontrovertible. Try to >> work out what it says about >> >> sizeof x++ >> >> and you'll see. It claims that sizeof is only a C++ operator, and it >> says nothing about postfix increment. (Either that or it says that both >> ++ operators are right associative.) And if despite that you work out >> that the parse is > > Actually, I agree with you. It looks like an error in the building of > the page. They changed the font color one operator too soon. You also missed the other point of my example. The table don't show that -- and ++ can also be postfix operators. If both sizeof and ++ have the same precedence and are both right associative how you possibly parse sizeof x++? What does it even mean to have a right associative postfix operator? >> sizeof (x++) >> >> (and you take the text literally), you would conclude that the ++ is >> evaluated before the sizeof. Is it? And what does it mean to evaluate >> ++ first in this context? > > In this context it is immaterial which would be evaluated first, because > ++ does not change the size of the object. However, the increment > operator would be evaluated first, according to the rules. Compiler > optimization could change that, though, because the order is > immaterial. The ++ would be evaluated first according to the incorrect rules you keep citing, but it would not evaluated either first or second according to the rules of the C language. There is no ordering -- only one of the two operators is evaluated. >> But I don't want to be unkind. Someone wrote up a table to help the >> students and repeated the simplistic and potentially misleading trope >> about evaluation order. It what time-pressed academics do. I'm sure >> I've done exactly that in the past myself. But the course "info" pages >> also reference the comp.lang.c FAQ so the students are getting other >> sources as well. > > This is more than "a table to help the students...". It is part of > their public site. And being public, it was peer-reviewed before being > published. That's very unlikely. It might have been reviewed by the TAs, or maybe the TAs wrote it and the professor reviewed it, but the university won't have the time or the expertise to do that. >>>>> Microsoft: >>>>> https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx >>>> >>>> And this one appears to be about some other language not entirely unlike >>>> C. >>> >>> Yes, wrong link. The correct one is >>> https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx >>> >>> But it says the same thing, because C# was built to the same rules as >>> C. >> >> Is there anything you can't be wrong about? C# explicitly defines the >> exact order of evaluation of both operands and operators. It's one of >> the famous *differences* between C and C#. > > And I gave a link to the correct page, also. But you didn't look at > that, did you? Yes, I did. You, apparently, did not read my comments about it. If you want to, see Message-ID: <87d1e4alzc.fsf@bsb.me.uk>. > Hint: it says basically the same thing as the C# page > does because C# is just Microsoft's version of C. Funny! Can I have "C# is just Microsoft's version of C" as a sig line? (It's particularly funny in this context because C and C# differ radically in exactly this area of the language.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 12:43 -0500 |
| Message-ID | <o94cot$t8q$1@jstuckle.eternal-september.org> |
| In reply to | #105075 |
On 2/28/2017 5:46 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/27/2017 8:29 PM, Ben Bacarisse wrote: > <snip> >>> Anyway, the fact that that page has errors is incontrovertible. Try to >>> work out what it says about >>> >>> sizeof x++ >>> >>> and you'll see. It claims that sizeof is only a C++ operator, and it >>> says nothing about postfix increment. (Either that or it says that both >>> ++ operators are right associative.) And if despite that you work out >>> that the parse is >> >> Actually, I agree with you. It looks like an error in the building of >> the page. They changed the font color one operator too soon. > > You also missed the other point of my example. The table don't show > that -- and ++ can also be postfix operators. If both sizeof and ++ > have the same precedence and are both right associative how you possibly > parse sizeof x++? What does it even mean to have a right associative > postfix operator? > ++ can be either prefix or postfix. They did not differentiate between them because they have the same precedence and associativity. And you parse sizeof(x++) by parsing the increment operator first because it is in parens, then taking the size of the resulting object. However, since the increment operator does not change the type of the object, the size does not change and sizeof can actually be computed at compile time - and generally is. >>> sizeof (x++) >>> >>> (and you take the text literally), you would conclude that the ++ is >>> evaluated before the sizeof. Is it? And what does it mean to evaluate >>> ++ first in this context? >> >> In this context it is immaterial which would be evaluated first, because >> ++ does not change the size of the object. However, the increment >> operator would be evaluated first, according to the rules. Compiler >> optimization could change that, though, because the order is >> immaterial. > > The ++ would be evaluated first according to the incorrect rules you > keep citing, but it would not evaluated either first or second according > to the rules of the C language. There is no ordering -- only one of the > two operators is evaluated. > Both of the operators exist and MUST be evaluated. If this is the entire statement, however, the sizeof operator has no effect and can be optimized out of the code. >>> But I don't want to be unkind. Someone wrote up a table to help the >>> students and repeated the simplistic and potentially misleading trope >>> about evaluation order. It what time-pressed academics do. I'm sure >>> I've done exactly that in the past myself. But the course "info" pages >>> also reference the comp.lang.c FAQ so the students are getting other >>> sources as well. >> >> This is more than "a table to help the students...". It is part of >> their public site. And being public, it was peer-reviewed before being >> published. > > That's very unlikely. It might have been reviewed by the TAs, or maybe > the TAs wrote it and the professor reviewed it, but the university won't > have the time or the expertise to do that. > You don't know how universities work, obviously. >>>>>> Microsoft: >>>>>> https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx >>>>> >>>>> And this one appears to be about some other language not entirely unlike >>>>> C. >>>> >>>> Yes, wrong link. The correct one is >>>> https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx >>>> >>>> But it says the same thing, because C# was built to the same rules as >>>> C. >>> >>> Is there anything you can't be wrong about? C# explicitly defines the >>> exact order of evaluation of both operands and operators. It's one of >>> the famous *differences* between C and C#. >> >> And I gave a link to the correct page, also. But you didn't look at >> that, did you? > > Yes, I did. You, apparently, did not read my comments about it. If you > want to, see Message-ID: <87d1e4alzc.fsf@bsb.me.uk>. > Yes, I read your comments. I ignored them because they were just more of the same BS. >> Hint: it says basically the same thing as the C# page >> does because C# is just Microsoft's version of C. > > Funny! Can I have "C# is just Microsoft's version of C" as a sig line? > (It's particularly funny in this context because C and C# differ > radically in exactly this area of the language.) > That's exactly what it is. It was developed by Microsoft in an attempt to get a language they could control. It was heavily based on C, hence the name C#. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-01 02:08 +0000 |
| Message-ID | <87mvd5oiiy.fsf@bsb.me.uk> |
| In reply to | #105120 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/28/2017 5:46 AM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 2/27/2017 8:29 PM, Ben Bacarisse wrote: >> <snip> >>>> Anyway, the fact that that page has errors is incontrovertible. Try to >>>> work out what it says about >>>> >>>> sizeof x++ >>>> >>>> and you'll see. It claims that sizeof is only a C++ operator, and it >>>> says nothing about postfix increment. (Either that or it says that both >>>> ++ operators are right associative.) And if despite that you work out >>>> that the parse is >>> >>> Actually, I agree with you. It looks like an error in the building of >>> the page. They changed the font color one operator too soon. >> >> You also missed the other point of my example. The table don't show >> that -- and ++ can also be postfix operators. If both sizeof and ++ >> have the same precedence and are both right associative how you possibly >> parse sizeof x++? What does it even mean to have a right associative >> postfix operator? > > ++ can be either prefix or postfix. They did not differentiate between > them because they have the same precedence and associativity. No they don't. And you dodged the question of what it means for a postfix operator to be right associative. > And you parse sizeof(x++) by parsing the increment operator first > because it is in parens, My example was sizeof x++ with no parentheses. Yes, it parses the same way, but why? You can't explain it because if believe that erroneous table that says the sizeof and ++ have the same precedence and associative. Is that why you changed the example? <snip> >> The ++ would be evaluated first according to the incorrect rules you >> keep citing, but it would not evaluated either first or second according >> to the rules of the C language. There is no ordering -- only one of the >> two operators is evaluated. > > Both of the operators exist and MUST be evaluated. Have you tried it? The ++, despite having higher precedence is not evaluated. Of course, maybe you have some notion of evaluating an operator in which evaluating ++ has no effect. <snip> >>> Hint: it says basically the same thing as the C# page >>> does because C# is just Microsoft's version of C. >> >> Funny! Can I have "C# is just Microsoft's version of C" as a sig line? >> (It's particularly funny in this context because C and C# differ >> radically in exactly this area of the language.) > > That's exactly what it is. <snip> So I can use the quote then? -- Ben. "C# is just Microsoft's version of C" -- Jerry Stuckle
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-01 11:52 -0500 |
| Message-ID | <o96u4j$v43$1@jstuckle.eternal-september.org> |
| In reply to | #105203 |
On 2/28/2017 9:08 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/28/2017 5:46 AM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 2/27/2017 8:29 PM, Ben Bacarisse wrote: >>> <snip> >>>>> Anyway, the fact that that page has errors is incontrovertible. Try to >>>>> work out what it says about >>>>> >>>>> sizeof x++ >>>>> >>>>> and you'll see. It claims that sizeof is only a C++ operator, and it >>>>> says nothing about postfix increment. (Either that or it says that both >>>>> ++ operators are right associative.) And if despite that you work out >>>>> that the parse is >>>> >>>> Actually, I agree with you. It looks like an error in the building of >>>> the page. They changed the font color one operator too soon. >>> >>> You also missed the other point of my example. The table don't show >>> that -- and ++ can also be postfix operators. If both sizeof and ++ >>> have the same precedence and are both right associative how you possibly >>> parse sizeof x++? What does it even mean to have a right associative >>> postfix operator? >> >> ++ can be either prefix or postfix. They did not differentiate between >> them because they have the same precedence and associativity. > > No they don't. And you dodged the question of what it means for a > postfix operator to be right associative. > Ah, you're right. I missed the fact they didn't specify the different associativity. >> And you parse sizeof(x++) by parsing the increment operator first >> because it is in parens, > > My example was sizeof x++ with no parentheses. Yes, it parses the same > way, but why? You can't explain it because if believe that erroneous > table that says the sizeof and ++ have the same precedence and > associative. Is that why you changed the example? > Look back. I didn't change the example. But in either case, it is immaterial because the standard says whether the x++ is evaluated or not is unspecified. > <snip> >>> The ++ would be evaluated first according to the incorrect rules you >>> keep citing, but it would not evaluated either first or second according >>> to the rules of the C language. There is no ordering -- only one of the >>> two operators is evaluated. >> >> Both of the operators exist and MUST be evaluated. > > Have you tried it? The ++, despite having higher precedence is not > evaluated. Of course, maybe you have some notion of evaluating an > operator in which evaluating ++ has no effect. > See above. > <snip> >>>> Hint: it says basically the same thing as the C# page >>>> does because C# is just Microsoft's version of C. >>> >>> Funny! Can I have "C# is just Microsoft's version of C" as a sig line? >>> (It's particularly funny in this context because C and C# differ >>> radically in exactly this area of the language.) >> >> That's exactly what it is. > <snip> > > So I can use the quote then? > You can say whatever you want in your sig line. And if you try to deny it, people who know the history of C# will be laughing. Oh, wait. They are anyway. So nothing will change. -- ================== 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-03-01 16:58 +0000 |
| Message-ID | <o96ugq$vuk$3@dont-email.me> |
| In reply to | #105273 |
On 01/03/17 16:52, Jerry Stuckle wrote: > On 2/28/2017 9:08 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 2/28/2017 5:46 AM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 2/27/2017 8:29 PM, Ben Bacarisse wrote: >>>> <snip> >>>>>> Anyway, the fact that that page has errors is incontrovertible. Try to >>>>>> work out what it says about >>>>>> >>>>>> sizeof x++ >>>>>> >>>>>> and you'll see. It claims that sizeof is only a C++ operator, and it >>>>>> says nothing about postfix increment. (Either that or it says that both >>>>>> ++ operators are right associative.) And if despite that you work out >>>>>> that the parse is >>>>> >>>>> Actually, I agree with you. It looks like an error in the building of >>>>> the page. They changed the font color one operator too soon. >>>> >>>> You also missed the other point of my example. The table don't show >>>> that -- and ++ can also be postfix operators. If both sizeof and ++ >>>> have the same precedence and are both right associative how you possibly >>>> parse sizeof x++? What does it even mean to have a right associative >>>> postfix operator? >>> >>> ++ can be either prefix or postfix. They did not differentiate between >>> them because they have the same precedence and associativity. >> >> No they don't. And you dodged the question of what it means for a >> postfix operator to be right associative. >> > > Ah, you're right. I missed the fact they didn't specify the different > associativity. > >>> And you parse sizeof(x++) by parsing the increment operator first >>> because it is in parens, >> >> My example was sizeof x++ with no parentheses. Yes, it parses the same >> way, but why? You can't explain it because if believe that erroneous >> table that says the sizeof and ++ have the same precedence and >> associative. Is that why you changed the example? >> > > Look back. I didn't change the example. But in either case, it is > immaterial because the standard says whether the x++ is evaluated or not > is unspecified. See 6.5.3.4(2). -- 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 | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-01 09:32 -0800 |
| Message-ID | <c0a3275e-51fb-4418-b781-10175c62e623@googlegroups.com> |
| In reply to | #105273 |
On Wednesday, March 1, 2017 at 11:52:33 AM UTC-5, Jerry Stuckle wrote: > On 2/28/2017 9:08 PM, Ben Bacarisse wrote: > > Jerry Stuckle <jstucklex@attglobal.net> writes: > > > >> On 2/28/2017 5:46 AM, Ben Bacarisse wrote: > >>> Jerry Stuckle <jstucklex@attglobal.net> writes: > >>> > >>>> On 2/27/2017 8:29 PM, Ben Bacarisse wrote: ... > >>>>> sizeof x++ ... > >> And you parse sizeof(x++) by parsing the increment operator first ... > > My example was sizeof x++ with no parentheses. Yes, it parses the same > > way, but why? You can't explain it because if believe that erroneous > > table that says the sizeof and ++ have the same precedence and > > associative. Is that why you changed the example? > > > > Look back. I didn't change the example. I've looked back. I see liean example with no parentheses, followed by a response where you changed the example by adding parentheses to it. That change matters, because it's precisely the case without parentheses that presents the problem he's trying to point out. > But in either case, it is > immaterial because the standard says whether the x++ is evaluated or not > is unspecified. It says "If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated ...". There's nothing unspecified about that - it's very precisely specified. x++ requires that its operand be a modifiable lvalue, so x cannot have an array type of any kind, variable length or otherwise. The result of x++ has the same type as it's operand. So when x++ is the operand of the sizeof operator, it is NOT evaluated. ... > > Have you tried it? The ++, despite having higher precedence is not > > evaluated. Of course, maybe you have some notion of evaluating an > > operator in which evaluating ++ has no effect. > > > > See above. I looked above. I didn't see any example of you actually testing code containing the expression sizeof x++. Perhaps I missed it. Could you tell me what the results of that test were?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-01 21:50 +0000 |
| Message-ID | <87lgsomzto.fsf@bsb.me.uk> |
| In reply to | #105273 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/28/2017 9:08 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 2/28/2017 5:46 AM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 2/27/2017 8:29 PM, Ben Bacarisse wrote: >>>> <snip> >>>>>> Anyway, the fact that that page has errors is incontrovertible. Try to >>>>>> work out what it says about >>>>>> >>>>>> sizeof x++ >>>>>> >>>>>> and you'll see. It claims that sizeof is only a C++ operator, and it >>>>>> says nothing about postfix increment. (Either that or it says that both >>>>>> ++ operators are right associative.) And if despite that you work out >>>>>> that the parse is >>>>> >>>>> Actually, I agree with you. It looks like an error in the building of >>>>> the page. They changed the font color one operator too soon. >>>> >>>> You also missed the other point of my example. The table don't show >>>> that -- and ++ can also be postfix operators. If both sizeof and ++ >>>> have the same precedence and are both right associative how you possibly >>>> parse sizeof x++? What does it even mean to have a right associative >>>> postfix operator? >>> >>> ++ can be either prefix or postfix. They did not differentiate between >>> them because they have the same precedence and associativity. >> >> No they don't. And you dodged the question of what it means for a >> postfix operator to be right associative. >> > > Ah, you're right. I missed the fact they didn't specify the different > associativity. And they have different precedence as well. If they didn't you could not tell if sizeof x++ was to parsed as ((sizeof x)++) because sizeof is left associative or as (sizeof (x++)) because ++ is right as associative. All postfix operators in C have higher precedence than the prefix ones. >>> And you parse sizeof(x++) by parsing the increment operator first >>> because it is in parens, >> >> My example was sizeof x++ with no parentheses. Yes, it parses the same >> way, but why? You can't explain it because if believe that erroneous >> table that says the sizeof and ++ have the same precedence and >> associative. Is that why you changed the example? > > Look back. I didn't change the example. Yes, it's right there. My example was sizeof x++ and you explained how to parse sizeod (x++) "because it is in parens". > But in either case, it is > immaterial because the standard says whether the x++ is evaluated or not > is unspecified. No. It says it must not be evaluated whereas the erroneous "rule" says that ++ must be evaluated before sizeof because of the higher precedence. I think your remark about it being unspecified is due to your reading of a passage about sizeof in declarators for variable length arrays in C11. That's not relevant here. The pre-conditions for that clause to apply are complex but can't apply to the expression in question. The meaning of sizeof x++ goes way back. To summarise the state of this discussion... The oft-quoted "rule" that precedence and associativity determine the order in which operators are evaluated is overburdened with issues: 1) It is flat-out wrong in a number of cases. These exceptions have to be specifically addressed (like sizeof, && and so on). 2) In the cases where it's not flat-out wrong, it says too much and should be clarified with an "as if" clause. 3) It ties something the programmer cares about (what an expression means) to something they shouldn't care about (when an evaluation, within an expression, takes place). 4) Precedence and associativity are inadequate to describe the corner cases of the grammar (for example sizeof (int) + 42). Despite number 4, precedence and associativity are a very simple way to explain what operands are associated with what operators. This purely syntactic use of precedence and associativity is largely unproblematic and is vastly superior the usual rule. The rule is, none the less, ubiquitous. This is surely due to the fact that it's simple and relates something new (computer programming language expressions) to something very familiar -- the rules you were taught in school for doing arithmetic. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-01 09:18 -0800 |
| Message-ID | <aa0bc6b8-a7f3-4330-b36d-32e279ec03c1@googlegroups.com> |
| In reply to | #105120 |
On Tuesday, February 28, 2017 at 12:43:53 PM UTC-5, Jerry Stuckle wrote: > On 2/28/2017 5:46 AM, Ben Bacarisse wrote: ... > > You also missed the other point of my example. The table don't show > > that -- and ++ can also be postfix operators. If both sizeof and ++ > > have the same precedence and are both right associative how you possibly > > parse sizeof x++? What does it even mean to have a right associative > > postfix operator? > > > > ++ can be either prefix or postfix. They did not differentiate between > them because they have the same precedence and associativity. Note: in the following paragraphs I make frequent use of the terms "precedence" and "associativity", even though the relevant rules from the C standard don't make any use of those concepts. Your lies to the contrary notwithstanding, I've never denied that those concepts exist, and I have in fact explicitly stated that they can be used to describe features of the C grammar. This is an example of that. Each of the sections in under 6.5 describes one precedence level, with the higher precedence levels being discussed before the lower ones. In standard C, postfix ++ and postfix are described in section 6.5.2 "Postfix operators", giving them the second highest precedence level, which they share with array subscripting, function calls, the member selection operators, and compound literals. That corresponds to the first line of the operator precedence table in K&R1. Because the operand for an increment or decrement operator must be an lvalue, and the result is NOT an lvalue, so they can't be chained together with themselves or each other. However, they associate left-to-right with the other operators that have the same precedence level. (a+b)[c+d](e+f).g->h++ is parsed as (((((a+b)[c+d])(e+f)).g)->h)++. It really wouldn't be possible for them to associate right-to-left, because, by definition of "postfix", none of them have grammar rule that ends with an expression. Prefix ++ and -- are described in section 6.5.3 "Unary operators", giving them the third highest precedence level, which they share with !, ~, unary -, *, &, sizeof, and type casts. This corresponds to the second line in K&R1's precedence table. Just like the postfix version, they cannot be chained together with themselves or each other, but the prefix increment and decrement operators associate from right-to-left with the other operators at the same precedence level: ! ~ - sizeof ++ * (char*) & a is parsed as !(~(-(sizeof(++(*((char*)(&a))))))). Since none of them has a grammar rule that starts with an expression, it isn't really possible for them to associate left-to-right. A consequence of the different precedence levels is that ++a[b] must be parsed as ++(a[b]), while *a++ must be parsed as *(a++). > And you parse sizeof(x++) by parsing the increment operator first > because it is in parens, then taking the size of the resulting object. True - but how do you parse sizeof x++?, the case he actually asked you about, which has no parentheses? The C standard identifies x++ as a postfix-expression, which has a higher precedence than sizeof x, which is a unary-expression, mandating that sizeof x++ be parsed the same as sizeof(x++). Since you don't make that distinction, how do you justify that parse? ... > Both of the operators exist and MUST be evaluated. "If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated ..." (6.5.4p2). Are you claiming that x++ has a variable length array type? That's not actually possible, you know.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-26 19:47 -0500 |
| Message-ID | <o8vsq5$v6a$2@jstuckle.eternal-september.org> |
| In reply to | #104792 |
On 2/26/2017 4:54 PM, Richard Heathfield wrote: > On 26/02/17 20:57, Jerry Stuckle wrote: >> On 2/26/2017 12:00 PM, James R. Kuyper wrote: >>> Jerry - I'm posting this message as a reply to my own message, rather >>> than as a reply to your response, because I wanted to quote some text >>> from my message, which you chose to cut from your response. You didn't >>> say anything in your response worth quoting. >>> >> >> <snip more bullshit> >> >> I snipped it because it's pure BS. Nothing more, nothing less. >> >> For instance - in the case of >> >> (a=b) && a++ >> >> You have another operator in there - the logical AND operator. The >> rules also state than when logical operators are being processed, >> evaluation stops as soon as the result of the entire expression can be >> determined. > > That's right. In fact, it's a counter-example to your claim about > precedence and associativity determining order of evaluation. > > No wonder you call it "bullshit". > Hit send too quickly... And the rest of his "proof" is similar bullshit. But if you understood that, you wouldn't have posted this crap. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-26 19:24 -0800 |
| Message-ID | <11f8fc0a-80a0-4c1e-9ade-50f8af280be0@googlegroups.com> |
| In reply to | #104789 |
On Sunday, February 26, 2017 at 3:57:23 PM UTC-5, Jerry Stuckle wrote: ... > For instance - in the case of > > (a=b) && a++ > > You have another operator in there - the logical AND operator. The > rules also state than when logical operators are being processed, > evaluation stops as soon as the result of the entire expression can be > determined. > > In the case of the AND operator, the result is true only if both > operands are true. So the left operator is evaluated, and only if it > returns true is the right operand evaluated. Correct - that's basically what it says in 6.5.13p4. Which is why I chose that operator for my example. Which, in turn, is why I cited 6.5.13p4 as the rule that specifies that, in this case, a=b must be evaluated before a++, despite the fact that postfix increment has a much higher precedence than assignment. It seems to me that you're in agreement with me about that fact. True? False? I don't want to put words in your mouth - if neither "True" nor "False" fits, please feel free to provide your own words describing the relationship between what I believe is required for the order of evaluation, and what you believe is required for the order of evaluation. Just to be clear, let me reiterate that I believe that the 6.5.13p4 requires that a=b be evaluated first, and that if b has a non-zero value, then a++ gets evaluated second. Then 6.5p1 requires that (a=b) && a++ must be evaluated last. > And the rest of your examples are just as much bullshit as this one is. I don't care whether you consider them bullshit. I would like to know whether you agree with me that, in each of those cases, for the specified reason in each case, a=b must be evaluated prior to a++, despite the fact that a++ has a higher precedence than a=b. I can't imagine any reason why you'd disagree in any of those cases - you couldn't write working C code of any significant size without knowing most of those rules. But I can easily imagine that you'll avoid saying so just out of spite.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 11:08 -0500 |
| Message-ID | <o91ipm$qm5$1@jstuckle.eternal-september.org> |
| In reply to | #104817 |
On 2/26/2017 10:24 PM, jameskuyper@verizon.net wrote: > On Sunday, February 26, 2017 at 3:57:23 PM UTC-5, Jerry Stuckle wrote: > ... >> For instance - in the case of >> >> (a=b) && a++ >> >> You have another operator in there - the logical AND operator. The >> rules also state than when logical operators are being processed, >> evaluation stops as soon as the result of the entire expression can be >> determined. >> >> In the case of the AND operator, the result is true only if both >> operands are true. So the left operator is evaluated, and only if it >> returns true is the right operand evaluated. > > Correct - that's basically what it says in 6.5.13p4. Which is why I chose that operator for my example. Which, in turn, is why I cited 6.5.13p4 as the rule that specifies that, in this case, a=b must be evaluated before a++, despite the fact that postfix increment has a much higher precedence than assignment. It seems to me that you're in agreement with me about that fact. True? False? > And that is flow control, not precedence or associativity. Two entirely different things. > I don't want to put words in your mouth - if neither "True" nor "False" fits, please feel free to provide your own words describing the relationship between what I believe is required for the order of evaluation, and what you believe is required for the order of evaluation. > The logical AND operator determines WHETHER the subsequent operations are performed. IF they are performed, precedence and associativity rules apply. In this case the a++ expression would be evaluated before the AND. > Just to be clear, let me reiterate that I believe that the 6.5.13p4 requires that a=b be evaluated first, and that if b has a non-zero value, then a++ gets evaluated second. Then 6.5p1 requires that (a=b) && a++ must be evaluated last. > That is true because, as I said, flow control is involved here. That is not the same as precedence and associativity. >> And the rest of your examples are just as much bullshit as this one is. > > I don't care whether you consider them bullshit. I would like to know whether you agree with me that, in each of those cases, for the specified reason in each case, a=b must be evaluated prior to a++, despite the fact that a++ has a higher precedence than a=b. I can't imagine any reason why you'd disagree in any of those cases - you couldn't write working C code of any significant size without knowing most of those rules. But I can easily imagine that you'll avoid saying so just out of spite. > I agree that your posts are complete bullshit. Here are three independent references from respectable sources which agree with me: Purdue University: https://web.ics.purdue.edu/~cs240/misc/operators.html University of Hawaii: https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html Microsoft: https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx Please show three independent and respected resources which contradict these. And no, your incorrect interpretation of the standards does not count. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-27 10:15 -0800 |
| Message-ID | <7fc8c78c-96df-4de9-846f-4cbc4c7c789f@googlegroups.com> |
| In reply to | #104883 |
On Monday, February 27, 2017 at 11:08:17 AM UTC-5, Jerry Stuckle wrote: > On 2/26/2017 10:24 PM, jameskuyper@verizon.net wrote: > > On Sunday, February 26, 2017 at 3:57:23 PM UTC-5, Jerry Stuckle wrote: > > ... > >> For instance - in the case of > >> > >> (a=b) && a++ > >> > >> You have another operator in there - the logical AND operator. The > >> rules also state than when logical operators are being processed, > >> evaluation stops as soon as the result of the entire expression can be > >> determined. > >> > >> In the case of the AND operator, the result is true only if both > >> operands are true. So the left operator is evaluated, and only if it > >> returns true is the right operand evaluated. > > > > Correct - that's basically what it says in 6.5.13p4. Which is why I chose > > that operator for my example. Which, in turn, is why I cited 6.5.13p4 as > > the rule that specifies that, in this case, a=b must be evaluated before > > a++, despite the fact that postfix increment has a much higher precedence > > than assignment. ... > And that is flow control, not precedence or associativity. Two entirely > different things. I never said those rules involved precedence or associativity. I was asking you how the rule that you claim exists, but which I can't find anywhere in the standard, interacts with these other rules that I can find in the standard. You have never stated the rule as being anything other than absolute, which puts it in conflict with each of these examples. I never made the mistake of interpreting your description literally. Writing with clarity, precision, or the correct use of relevant jargon is clearly not your forte. If the rule you're talking about actually existed, a complete and precise statement of that rule would have to include wording that allowed for these exceptions (as your wording does not). It could, for example say "Within the sub-expressions of a full-expression, ...", which would cover most of the exceptions I listed. That wouldn't, however, cover the exceptions I labelled with 6.5.13p4 through 6.5.17p2 - each of those four cases is a single full-expression. Another option would be to say "Unless otherwise specified, ...". That would, by definition, cover all of the cases I listed. The standard makes only use the concept of "control flow" a couple of times, neither of them relevant to this context. It also makes only limited use of the terms "precedence" and "associativity". Therefore, it definitely fails to distinguish between precedence rules and control flow rules. However, I chose those particular rules precisely because every one of them involves a sequence point that controls the sequence with with expressions and their side-effects occur. If that's sufficient to justify you labeling each of the rules I cited as a "control flow rule", and if you're willing to modify your description of the operator precedence rule to allow it to be overriden by control flow rules, then that would answer my question, in precisely the way I had expected it to be answered. If you'd simply responded from the beginning that "Yes, control flow rules always override the rule that operator precedence determines the order of evaluation.", we both would have saved a lot of time and effort. This wouldn't have been an issue if you'd been willing the quote the exact wording of the relevant rule, either in K&R or in one or more versions of the standard. I would have been able to examine the exact words, and also their context, and that would allow me to determine precisely how that rule interacts with the other rules that I could find. You wouldn't even need to quote the words. A sufficiently precise citation would have been sufficient - but the only citation you've been able to give us is page 53 of K&R2, (corresponding, apparently, to page 49 in K&R1) - and the only statement made about the order of evaluation on that page is "C, like most languages, does not specify in what order the operands of an operator are evaluated." - which is certainly not the rule you're describing. ... > 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?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 15:08 -0500 |
| Message-ID | <o920r2$imm$1@jstuckle.eternal-september.org> |
| In reply to | #104907 |
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: >> On 2/26/2017 10:24 PM, jameskuyper@verizon.net wrote: >>> On Sunday, February 26, 2017 at 3:57:23 PM UTC-5, Jerry Stuckle wrote: >>> ... >>>> For instance - in the case of >>>> >>>> (a=b) && a++ >>>> >>>> You have another operator in there - the logical AND operator. The >>>> rules also state than when logical operators are being processed, >>>> evaluation stops as soon as the result of the entire expression can be >>>> determined. >>>> >>>> In the case of the AND operator, the result is true only if both >>>> operands are true. So the left operator is evaluated, and only if it >>>> returns true is the right operand evaluated. >>> >>> Correct - that's basically what it says in 6.5.13p4. Which is why I chose >>> that operator for my example. Which, in turn, is why I cited 6.5.13p4 as >>> the rule that specifies that, in this case, a=b must be evaluated before >>> a++, despite the fact that postfix increment has a much higher precedence >>> than assignment. > ... >> And that is flow control, not precedence or associativity. Two entirely >> different things. > > I never said those rules involved precedence or associativity. I was asking you > how the rule that you claim exists, but which I can't find anywhere in the > standard, interacts with these other rules that I can find in the standard. You > have never stated the rule as being anything other than absolute, which puts it > in conflict with each of these examples. I never made the mistake of > interpreting your description literally. Writing with clarity, precision, or > the correct use of relevant jargon is clearly not your forte. > > If the rule you're talking about actually existed, a complete and precise > statement of that rule would have to include wording that allowed for these > exceptions (as your wording does not). It could, for example say "Within the > sub-expressions of a full-expression, ...", which would cover most of the > exceptions I listed. That wouldn't, however, cover the exceptions I labelled > with 6.5.13p4 through 6.5.17p2 - each of those four cases is a single > full-expression. Another option would be to say "Unless otherwise specified, > ...". That would, by definition, cover all of the cases I listed. > > The standard makes only use the concept of "control flow" a couple of times, > neither of them relevant to this context. It also makes only limited use of the > terms "precedence" and "associativity". Therefore, it definitely fails to > distinguish between precedence rules and control flow rules. > > However, I chose those particular rules precisely because every one of them > involves a sequence point that controls the sequence with with expressions and > their side-effects occur. If that's sufficient to justify you labeling each of > the rules I cited as a "control flow rule", and if you're willing to modify > your description of the operator precedence rule to allow it to be overriden by > control flow rules, then that would answer my question, in precisely the way I > had expected it to be answered. If you'd simply responded from the beginning > that "Yes, control flow rules always override the rule that operator precedence > determines the order of evaluation.", we both would have saved a lot of time > and effort. > > This wouldn't have been an issue if you'd been willing the quote the exact > wording of the relevant rule, either in K&R or in one or more versions of the > standard. I would have been able to examine the exact words, and also their > context, and that would allow me to determine precisely how that rule interacts > with the other rules that I could find. You wouldn't even need to quote the > words. A sufficiently precise citation would have been sufficient - but the > only citation you've been able to give us is page 53 of K&R2, (corresponding, > apparently, to page 49 in K&R1) - and the only statement made about the order > of evaluation on that page is "C, like most languages, does not specify in what > order the operands of an operator are evaluated." - which is certainly not the > rule you're describing. > > ... >> 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. Can you show even ONE independent source which supports your interpretation? And while the standard is authoritative, your interpretation of it is not. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 25 of 27 — ← Prev page 1 … 23 24 [25] 26 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web