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 21 of 27 — ← Prev page 1 … 19 20 [21] 22 23 … 27 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 23:28 -0500 |
| Message-ID | <o92u4l$7a0$2@jstuckle.eternal-september.org> |
| In reply to | #104999 |
On 2/27/2017 8:34 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/27/2017 3:42 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >>>> because other >>>> than the comma operator, the others affect flow control. The comma >>>> operator effectively allows multiple statements to be used where only a >>>> single expression is allowed. >>> >>> No, you can't have statements as operands to the comma operator -- only >>> expressions -- and you rarely need the comma operator just to allow >>> multiple expressions where one is allowed. The distinguishing property >>> of the comma operator is that it allows expression evaluation to be >>> explicitly sequenced, though it is often used when the order does not, >>> in fact matter. >> >> Once again you don't understand what I said. Read it again and >> understand. > > Can you give an example of where a comma operator "effectively allows > multiple statements to be used where only a single expression is > allowed"? > > <snip> > for (i-0, j=10; i < j; i++, j--) ... as a start. -- ================== 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:16 +0000 |
| Message-ID | <871suir56m.fsf@bsb.me.uk> |
| In reply to | #105018 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/27/2017 8:34 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> >>>>> because other >>>>> than the comma operator, the others affect flow control. The comma >>>>> operator effectively allows multiple statements to be used where only a >>>>> single expression is allowed. <snip> >> Can you give an example of where a comma operator "effectively allows >> multiple statements to be used where only a single expression is >> allowed"? >> >> <snip> > > for (i-0, j=10; i < j; i++, j--) ... > > as a start. No. All of i-0 (you probably meant i=0 but it makes no difference), j=10, i++ and j-- are expressions. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 12:31 -0500 |
| Message-ID | <o94c29$qhb$2@jstuckle.eternal-september.org> |
| In reply to | #105071 |
On 2/28/2017 5:16 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/27/2017 8:34 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >>>>>> because other >>>>>> than the comma operator, the others affect flow control. The comma >>>>>> operator effectively allows multiple statements to be used where only a >>>>>> single expression is allowed. > <snip> >>> Can you give an example of where a comma operator "effectively allows >>> multiple statements to be used where only a single expression is >>> allowed"? >>> >>> <snip> >> >> for (i-0, j=10; i < j; i++, j--) ... >> >> as a start. > > No. All of i-0 (you probably meant i=0 but it makes no difference), > j=10, i++ and j-- are expressions. > And then there is if (i == 0) j=3,k=5; Two expressions, one statement. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-28 20:17 +0100 |
| Message-ID | <o94i8e$i1g$1@dont-email.me> |
| In reply to | #105118 |
On 28/02/17 18:31, Jerry Stuckle wrote: > On 2/28/2017 5:16 AM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 2/27/2017 8:34 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >> <snip> >>>>>>> because other >>>>>>> than the comma operator, the others affect flow control. The comma >>>>>>> operator effectively allows multiple statements to be used where only a >>>>>>> single expression is allowed. >> <snip> >>>> Can you give an example of where a comma operator "effectively allows >>>> multiple statements to be used where only a single expression is >>>> allowed"? >>>> >>>> <snip> >>> >>> for (i-0, j=10; i < j; i++, j--) ... >>> >>> as a start. >> >> No. All of i-0 (you probably meant i=0 but it makes no difference), >> j=10, i++ and j-- are expressions. >> > > And then there is > > if (i == 0) > j=3,k=5; > > Two expressions, one statement. > Read your words here - "two expressions, /one/ statement". Read your words above - "the comma operator effectively allows multiple statements to be used where only a single expression is allowed". So you have given a fine example of using the comma operator with /one/ statement (and the statement could not be used where only a single expression is allowed). You have been challenged to show how to use the comma operator to squeeze at least two statements into a space where only a single expression is allowed.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-28 19:26 +0000 |
| Message-ID | <o94iq8$k3n$1@dont-email.me> |
| In reply to | #105145 |
On 28/02/17 19:17, David Brown wrote: > You have been challenged to show how to use the > comma operator to squeeze at least two statements into a space where > only a single expression is allowed. That's easy. f(); -- 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:42 -0500 |
| Message-ID | <o94n6v$4g2$3@jstuckle.eternal-september.org> |
| In reply to | #105145 |
On 2/28/2017 2:17 PM, David Brown wrote: > On 28/02/17 18:31, Jerry Stuckle wrote: >> On 2/28/2017 5:16 AM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 2/27/2017 8:34 PM, Ben Bacarisse wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> <snip> >>>>>>>> because other >>>>>>>> than the comma operator, the others affect flow control. The comma >>>>>>>> operator effectively allows multiple statements to be used where only a >>>>>>>> single expression is allowed. >>> <snip> >>>>> Can you give an example of where a comma operator "effectively allows >>>>> multiple statements to be used where only a single expression is >>>>> allowed"? >>>>> >>>>> <snip> >>>> >>>> for (i-0, j=10; i < j; i++, j--) ... >>>> >>>> as a start. >>> >>> No. All of i-0 (you probably meant i=0 but it makes no difference), >>> j=10, i++ and j-- are expressions. >>> >> >> And then there is >> >> if (i == 0) >> j=3,k=5; >> >> Two expressions, one statement. >> > > Read your words here - "two expressions, /one/ statement". Read your > words above - "the comma operator effectively allows multiple statements > to be used where only a single expression is allowed". > > So you have given a fine example of using the comma operator with /one/ > statement (and the statement could not be used where only a single > expression is allowed). You have been challenged to show how to use the > comma operator to squeeze at least two statements into a space where > only a single expression is allowed. > > > That is the equivalent of two statements: j = 3; k = 5; But only one statement is allowed in the then clause of an if statement. The comma operator allows two statements to be used. I could have been expanded into any number of expressions for that one statement. And a statement is just an expression followed by a semicolon. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-28 23:30 +0100 |
| Message-ID | <o94tj5$sg2$1@dont-email.me> |
| In reply to | #105161 |
On 28/02/17 21:42, Jerry Stuckle wrote: > On 2/28/2017 2:17 PM, David Brown wrote: >> On 28/02/17 18:31, Jerry Stuckle wrote: >>> On 2/28/2017 5:16 AM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 2/27/2017 8:34 PM, Ben Bacarisse wrote: >>>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> <snip> >>>>>>>>> because other >>>>>>>>> than the comma operator, the others affect flow control. The comma >>>>>>>>> operator effectively allows multiple statements to be used where only a >>>>>>>>> single expression is allowed. >>>> <snip> >>>>>> Can you give an example of where a comma operator "effectively allows >>>>>> multiple statements to be used where only a single expression is >>>>>> allowed"? >>>>>> >>>>>> <snip> >>>>> >>>>> for (i-0, j=10; i < j; i++, j--) ... >>>>> >>>>> as a start. >>>> >>>> No. All of i-0 (you probably meant i=0 but it makes no difference), >>>> j=10, i++ and j-- are expressions. >>>> >>> >>> And then there is >>> >>> if (i == 0) >>> j=3,k=5; >>> >>> Two expressions, one statement. >>> >> >> Read your words here - "two expressions, /one/ statement". Read your >> words above - "the comma operator effectively allows multiple statements >> to be used where only a single expression is allowed". >> >> So you have given a fine example of using the comma operator with /one/ >> statement (and the statement could not be used where only a single >> expression is allowed). You have been challenged to show how to use the >> comma operator to squeeze at least two statements into a space where >> only a single expression is allowed. >> >> >> > > That is the equivalent of two statements: > > j = 3; > k = 5; > > But only one statement is allowed in the then clause of an if statement. > The comma operator allows two statements to be used. I could have been > expanded into any number of expressions for that one statement. > > And a statement is just an expression followed by a semicolon. > No, an expression followed by a semicolon is a kind of statement (an expression statement, to be exact). There are many other kinds of statements in C. Clearly a comma can be used to combine two expressions, and the expressions can have side effects, and they can be the kind of expression that is more commonly written as expression statements (like your example). But that is very far from saying you can use a comma operator to combine statements into one expression. Of course, if you had read the standards - and /understood/ the standards - you would know that.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-01 08:37 -0500 |
| Message-ID | <o96im7$k2h$3@jstuckle.eternal-september.org> |
| In reply to | #105180 |
On 2/28/2017 5:30 PM, David Brown wrote: > On 28/02/17 21:42, Jerry Stuckle wrote: >> On 2/28/2017 2:17 PM, David Brown wrote: >>> On 28/02/17 18:31, Jerry Stuckle wrote: >>>> On 2/28/2017 5:16 AM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 2/27/2017 8:34 PM, Ben Bacarisse wrote: >>>>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> <snip> >>>>>>>>>> because other >>>>>>>>>> than the comma operator, the others affect flow control. The >>>>>>>>>> comma >>>>>>>>>> operator effectively allows multiple statements to be used >>>>>>>>>> where only a >>>>>>>>>> single expression is allowed. >>>>> <snip> >>>>>>> Can you give an example of where a comma operator "effectively >>>>>>> allows >>>>>>> multiple statements to be used where only a single expression is >>>>>>> allowed"? >>>>>>> >>>>>>> <snip> >>>>>> >>>>>> for (i-0, j=10; i < j; i++, j--) ... >>>>>> >>>>>> as a start. >>>>> >>>>> No. All of i-0 (you probably meant i=0 but it makes no difference), >>>>> j=10, i++ and j-- are expressions. >>>>> >>>> >>>> And then there is >>>> >>>> if (i == 0) >>>> j=3,k=5; >>>> >>>> Two expressions, one statement. >>>> >>> >>> Read your words here - "two expressions, /one/ statement". Read your >>> words above - "the comma operator effectively allows multiple statements >>> to be used where only a single expression is allowed". >>> >>> So you have given a fine example of using the comma operator with /one/ >>> statement (and the statement could not be used where only a single >>> expression is allowed). You have been challenged to show how to use the >>> comma operator to squeeze at least two statements into a space where >>> only a single expression is allowed. >>> >>> >>> >> >> That is the equivalent of two statements: >> >> j = 3; >> k = 5; >> >> But only one statement is allowed in the then clause of an if statement. >> The comma operator allows two statements to be used. I could have been >> expanded into any number of expressions for that one statement. >> >> And a statement is just an expression followed by a semicolon. >> > > No, an expression followed by a semicolon is a kind of statement (an > expression statement, to be exact). There are many other kinds of > statements in C. > > Clearly a comma can be used to combine two expressions, and the > expressions can have side effects, and they can be the kind of > expression that is more commonly written as expression statements (like > your example). > > But that is very far from saying you can use a comma operator to combine > statements into one expression. > That is not what I said. You can't even quote correctly. > Of course, if you had read the standards - and /understood/ the > standards - you would know that. > You guys are hopeless. I'm tired of trying to teach the pigs to sing. I've quoted multiple independent, respected sources and you've argued with every one of them. The only independent source you have quoted to support your position is a single site run by a single person, with unsubstantiated claims as to how much his site is "peer reviewed". If your position is so correct, you should be able to find thousands of sites to support your position. I can do it for mine. 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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-27 09:19 +0000 |
| Message-ID | <o90qqo$3bk$1@dont-email.me> |
| In reply to | #104801 |
On 27/02/17 00:45, Jerry Stuckle wrote: > 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". >> > > Not at all, Richard. He included a third operator - the logical AND > operator. Precisely. But if there were only two operators in any expression, we would hardly need precedence rules, would we? We could just say "right to left" and be done with it: it would make sense to do that, since if we were only allowed two operators, most expressions would have = as their first operator. But no, C allows more than two operators in an expression, and so either we allow C compilers the freedom to make up their own rules as to the order in which they calculate the results of sub-expressions or we impose a strict rule. Your claim is that precedence (with associativity for tie-breaks) is that rule. And yet that rule does not cover a simple expression such as a=b && a++ - so it's not much of a rule, is it? In a=b && a++ the order of precedence is: ++ (highest) && (middle) = (lowest) It is, however, clear that the = operation must be evaluated first, the && second, and the ++ last (if at all). So much for precedence. > And that also affects the order of processing. Yes, except for the "also". In fact, it turns out that precedence and associativity do not determine the order of evaluation after all. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-27 09:14 -0500 |
| Message-ID | <o91c3u$rv$1@dont-email.me> |
| In reply to | #104828 |
On 02/27/2017 04:19 AM, Richard Heathfield wrote: ... > for tie-breaks) is that rule. And yet that rule does not cover a simple > expression such as a=b && a++ - so it's not much of a rule, is it? Just a hint. In my example, there were parentheses around a=b. There was a reason for that.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 11:00 -0500 |
| Message-ID | <o91ibg$odk$2@jstuckle.eternal-september.org> |
| In reply to | #104856 |
On 2/27/2017 9:14 AM, James Kuyper wrote:
> On 02/27/2017 04:19 AM, Richard Heathfield wrote:
> ...
>> for tie-breaks) is that rule. And yet that rule does not cover a simple
>> expression such as a=b && a++ - so it's not much of a rule, is it?
>
> Just a hint. In my example, there were parentheses around a=b. There was
> a reason for that.
>
Good point - I missed that one. From this expression the result is an
assignment to a. So the equivalent would be:
if (b)
if (a++)
a = 1;
else
a = 0;
else
a = 0;
--
==================
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-27 16:24 +0000 |
| Message-ID | <o91jo8$tsk$1@dont-email.me> |
| In reply to | #104856 |
On 27/02/17 14:14, James Kuyper wrote: > On 02/27/2017 04:19 AM, Richard Heathfield wrote: > ... >> for tie-breaks) is that rule. And yet that rule does not cover a simple >> expression such as a=b && a++ - so it's not much of a rule, is it? > > Just a hint. In my example, there were parentheses around a=b. There was > a reason for that. Carelessness on my part. Sorry. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 10:58 -0500 |
| Message-ID | <o91i83$odk$1@jstuckle.eternal-september.org> |
| In reply to | #104828 |
On 2/27/2017 4:19 AM, Richard Heathfield wrote:
> On 27/02/17 00:45, Jerry Stuckle wrote:
>> 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".
>>>
>>
>> Not at all, Richard. He included a third operator - the logical AND
>> operator.
>
> Precisely. But if there were only two operators in any expression, we
> would hardly need precedence rules, would we? We could just say "right
> to left" and be done with it: it would make sense to do that, since if
> we were only allowed two operators, most expressions would have = as
> their first operator.
>
Yes, we would. You still need to determine which order the two
operators are processed.
> But no, C allows more than two operators in an expression, and so either
> we allow C compilers the freedom to make up their own rules as to the
> order in which they calculate the results of sub-expressions or we
> impose a strict rule. Your claim is that precedence (with associativity
> for tie-breaks) is that rule. And yet that rule does not cover a simple
> expression such as a=b && a++ - so it's not much of a rule, is it?
>
Yes, it does.
> In a=b && a++ the order of precedence is:
>
> ++ (highest)
> && (middle)
> = (lowest)
>
> It is, however, clear that the = operation must be evaluated first, the
> && second, and the ++ last (if at all). So much for precedence.
>
>> And that also affects the order of processing.
>
> Yes, except for the "also". In fact, it turns out that precedence and
> associativity do not determine the order of evaluation after all.
>
That is correct. But you have to look at the operators involved, also.
The logical AND operator affects flow control. Unlike most languages,
the second expression may or may not be evaluated based on the results
of the first expression. This is not precedence or associativity - it
is flow control.
An equivalent expression without the flow control would be:
if (a=b)
if (a++)
true;
else
false;
else
false;
Don't mix flow control with precedence and associativity.
--
==================
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-27 16:39 +0000 |
| Message-ID | <o91kkv$24t$1@dont-email.me> |
| In reply to | #104880 |
On 27/02/17 15:58, Jerry Stuckle wrote: > On 2/27/2017 4:19 AM, Richard Heathfield wrote: >> On 27/02/17 00:45, Jerry Stuckle wrote: >>> 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". >>>> >>> >>> Not at all, Richard. He included a third operator - the logical AND >>> operator. >> >> Precisely. But if there were only two operators in any expression, we >> would hardly need precedence rules, would we? We could just say "right >> to left" and be done with it: it would make sense to do that, since if >> we were only allowed two operators, most expressions would have = as >> their first operator. >> > > Yes, we would. You still need to determine which order the two > operators are processed. Like I said, we would hardly need precedence rules - the simple rule "right to left" would cover it. Learn to read. > >> But no, C allows more than two operators in an expression, and so either >> we allow C compilers the freedom to make up their own rules as to the >> order in which they calculate the results of sub-expressions or we >> impose a strict rule. Your claim is that precedence (with associativity >> for tie-breaks) is that rule. And yet that rule does not cover a simple >> expression such as a=b && a++ - so it's not much of a rule, is it? >> > > Yes, it does. > >> In a=b && a++ the order of precedence is: >> >> ++ (highest) >> && (middle) >> = (lowest) >> >> It is, however, clear that the = operation must be evaluated first, the >> && second, and the ++ last (if at all). So much for precedence. >> >>> And that also affects the order of processing. >> >> Yes, except for the "also". In fact, it turns out that precedence and >> associativity do not determine the order of evaluation after all. >> > > That is correct. But you have to look at the operators involved, also. > The logical AND operator affects flow control. Unlike most languages, > the second expression may or may not be evaluated based on the results > of the first expression. This is not precedence or associativity - it > is flow control. So precedence and associativity do not govern the order in which operations are carried out. There is more to it than that. That's what people have been saying, and you've been telling us we're talking bullshit even while you're agreeing with us. > Don't mix flow control with precedence and associativity. In other words, you're right except when you're wrong. Well, quite so. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 15:19 -0500 |
| Message-ID | <o921h5$m5o$1@jstuckle.eternal-september.org> |
| In reply to | #104889 |
On 2/27/2017 11:39 AM, Richard Heathfield wrote: > On 27/02/17 15:58, Jerry Stuckle wrote: >> On 2/27/2017 4:19 AM, Richard Heathfield wrote: >>> On 27/02/17 00:45, Jerry Stuckle wrote: >>>> 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". >>>>> >>>> >>>> Not at all, Richard. He included a third operator - the logical AND >>>> operator. >>> >>> Precisely. But if there were only two operators in any expression, we >>> would hardly need precedence rules, would we? We could just say "right >>> to left" and be done with it: it would make sense to do that, since if >>> we were only allowed two operators, most expressions would have = as >>> their first operator. >>> >> >> Yes, we would. You still need to determine which order the two >> operators are processed. > > Like I said, we would hardly need precedence rules - the simple rule > "right to left" would cover it. Learn to read. > Nope. a*b+c would not be processed "right to left". If it were, f(a*b+c) would give an incorrect result. >> >>> But no, C allows more than two operators in an expression, and so either >>> we allow C compilers the freedom to make up their own rules as to the >>> order in which they calculate the results of sub-expressions or we >>> impose a strict rule. Your claim is that precedence (with associativity >>> for tie-breaks) is that rule. And yet that rule does not cover a simple >>> expression such as a=b && a++ - so it's not much of a rule, is it? >>> >> >> Yes, it does. >> >>> In a=b && a++ the order of precedence is: >>> >>> ++ (highest) >>> && (middle) >>> = (lowest) >>> >>> It is, however, clear that the = operation must be evaluated first, the >>> && second, and the ++ last (if at all). So much for precedence. >>> >>>> And that also affects the order of processing. >>> >>> Yes, except for the "also". In fact, it turns out that precedence and >>> associativity do not determine the order of evaluation after all. >>> >> >> That is correct. But you have to look at the operators involved, also. >> The logical AND operator affects flow control. Unlike most languages, >> the second expression may or may not be evaluated based on the results >> of the first expression. This is not precedence or associativity - it >> is flow control. > > So precedence and associativity do not govern the order in which > operations are carried out. There is more to it than that. That's what > people have been saying, and you've been telling us we're talking > bullshit even while you're agreeing with us. > Nope. I am not agreeing with you. But you have to look at the operators and how they affect flow control. >> Don't mix flow control with precedence and associativity. > > In other words, you're right except when you're wrong. Well, quite so. > Here are three reputable organizations who 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 I can easily find a few hundred more which say the same thing. Can you find three reputable sites who say these are wrong? No, your interpretation of the standard does not count. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-02-27 20:57 +0000 |
| Message-ID | <slrn3vfsob94on.62t.ike@iceland.freeshell.org> |
| In reply to | #104927 |
On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: > Here are three reputable organizations who 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 The Microsoft page mentions: "The precedence of an operator is established by the definition of its associated grammar production."
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-27 21:52 +0000 |
| Message-ID | <8737ezs3m8.fsf@bsb.me.uk> |
| In reply to | #104932 |
Ike Naar <ike@iceland.freeshell.org> writes: > On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >> Here are three reputable organizations who 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 > > The Microsoft page mentions: > "The precedence of an operator is established by the definition of > its associated grammar production." And it's not about C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 17:21 -0500 |
| Message-ID | <o928m0$glv$3@jstuckle.eternal-september.org> |
| In reply to | #104942 |
On 2/27/2017 4:52 PM, Ben Bacarisse wrote: > Ike Naar <ike@iceland.freeshell.org> writes: > >> On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>> Here are three reputable organizations who 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 >> >> The Microsoft page mentions: >> "The precedence of an operator is established by the definition of >> its associated grammar production." > > And it's not about C. > Sorry - wrong link. The correct one is https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx -- ================== 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-27 23:33 +0000 |
| Message-ID | <o92csr$2m8$1@dont-email.me> |
| In reply to | #104950 |
On 27/02/17 22:21, Jerry Stuckle wrote: > On 2/27/2017 4:52 PM, Ben Bacarisse wrote: >> Ike Naar <ike@iceland.freeshell.org> writes: >> >>> On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>> Here are three reputable organizations who 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 >>> >>> The Microsoft page mentions: >>> "The precedence of an operator is established by the definition of >>> its associated grammar production." >> >> And it's not about C. >> > > Sorry - wrong link. Fair enough. > The correct one is > > https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx Okay, let's look at it. Firstly, we have to make the assumption that this is about C, rather than about Visual Studio 2015's implementation of C. That is by no means an easy assumption to make --- the page is part of MSDN's C reference, but on the other hand it is labelled "Visual Studio 2015". Claim 1: "The precedence and associativity of C operators affect the grouping and evaluation of operands in expressions." True and undisputed. The Standard doesn't define what is meant by precedence, but we all know that it's a way to rank operators (although not uniquely, hence associativity). Claim 2: "An operator's precedence is meaningful only if other operators with higher or lower precedence are present." True and undisputed. Claim 3: "Expressions with higher-precedence operators are evaluated first." That may be true in Visual Studio 2015 but it's unlikely because, if it is, then Visual Studio is non-conforming in cases such as the short-cut evaluation example we've seen. (Note that there is no get-out-of-jail-free mention of flow control.) Claim 4: "Precedence can also be described by the word "binding." Operators with a higher precedence are said to have tighter binding. True and undisputed. Claim 5: "The following table summarizes the precedence and associativity (the order in which the operands are evaluated) of C operators, listing them in order of precedence from highest to lowest. Where several operators appear together, they have equal precedence and are evaluated according to their associativity." If this is true for Visual Studio 2015, it renders the implementation non-conforming in several important respects (for the same reason as before). Of course, it isn't actually true --- the compiler writers are more careful than the documentation writers. And finally, the only other relevant claim I can find on that page: "Only the sequential-evaluation (,), logical-AND (&&), logical-OR (||), conditional-expression (? :), and function-call operators constitute sequence points and therefore guarantee a particular order of evaluation for their operands." True and undisputed. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 18:49 -0500 |
| Message-ID | <o92dr1$5rr$1@jstuckle.eternal-september.org> |
| In reply to | #104962 |
On 2/27/2017 6:33 PM, Richard Heathfield wrote: > On 27/02/17 22:21, Jerry Stuckle wrote: >> On 2/27/2017 4:52 PM, Ben Bacarisse wrote: >>> Ike Naar <ike@iceland.freeshell.org> writes: >>> >>>> On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>>> Here are three reputable organizations who 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 >>>> >>>> The Microsoft page mentions: >>>> "The precedence of an operator is established by the definition of >>>> its associated grammar production." >>> >>> And it's not about C. >>> >> >> Sorry - wrong link. > > Fair enough. > >> The correct one is >> >> https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx > > Okay, let's look at it. Firstly, we have to make the assumption that > this is about C, rather than about Visual Studio 2015's implementation > of C. That is by no means an easy assumption to make --- the page is > part of MSDN's C reference, but on the other hand it is labelled "Visual > Studio 2015". > It is is C - not just "Visual Studio 2015's implementation of C". They need to follow the standards, also. > Claim 1: "The precedence and associativity of C operators affect the > grouping and evaluation of operands in expressions." > That is correct. > True and undisputed. The Standard doesn't define what is meant by > precedence, but we all know that it's a way to rank operators (although > not uniquely, hence associativity). > > Claim 2: "An operator's precedence is meaningful only if other operators > with higher or lower precedence are present." > > True and undisputed. > Oh, but you just claimed the Standard doesn't define what is meant by precedence. So which is it? > Claim 3: "Expressions with higher-precedence operators are evaluated > first." > > That may be true in Visual Studio 2015 but it's unlikely because, if it > is, then Visual Studio is non-conforming in cases such as the short-cut > evaluation example we've seen. (Note that there is no > get-out-of-jail-free mention of flow control.) > And your proof that it is non-conforming? Is gcc also non-conforming? clang? Other C compilers? > Claim 4: "Precedence can also be described by the word "binding." > Operators with a higher precedence are said to have tighter binding. > > True and undisputed. > But once again you claimed the standard doesn't define precedence. So obviously that can't be true. > Claim 5: "The following table summarizes the precedence and > associativity (the order in which the operands are evaluated) of C > operators, listing them in order of precedence from highest to lowest. > Where several operators appear together, they have equal precedence and > are evaluated according to their associativity." > > If this is true for Visual Studio 2015, it renders the implementation > non-conforming in several important respects (for the same reason as > before). Of course, it isn't actually true --- the compiler writers are > more careful than the documentation writers. > And your independent references to support your claims? How many more respected sites do I need to reference? What about the Purdue University and University of Hawaii sites which say the same thing? They aren't talking about Visual Studio 2015. > And finally, the only other relevant claim I can find on that page: > "Only the sequential-evaluation (,), logical-AND (&&), logical-OR (||), > conditional-expression (? :), and function-call operators constitute > sequence points and therefore guarantee a particular order of evaluation > for their operands." > > True and undisputed. > You just won't give up, despite being presented with evidence from multiple independent and respected resources. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 21 of 27 — ← Prev page 1 … 19 20 [21] 22 23 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web