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 20 of 27 — ← Prev page 1 … 18 19 [20] 21 22 … 27 Next page →
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 13:40 -0800 |
| Message-ID | <ddbc9eab-2d61-479e-bfeb-dc3fe513838f@googlegroups.com> |
| In reply to | #104640 |
On Friday, February 24, 2017 at 3:42:19 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 2:43 PM, jameskuyper@verizon.net wrote: > > Not as far as I could see. Ike Knarr correctly pointed out that > > "sizeof x ? B : C" must be parsed as "(sizeof x) ? B : C", which was probably > > not what BartC had intended. He also gave precisely the correct reason why that's the correct parse for that expression: the fact that sizeof takes a unary-expression for it's only operand. "x" is a unary-expression, "x ? B : C" > > is not. > > > > You responded by saying that Ike was correct in his conclusions, but gave > > the wrong reason. You then presented "x ? B : C returns a single value" as > > if it were the correct reason. You then went on to a non-sequitur, pointing > > out that "sizeof(x ? B : C)" was valid. While correct, that fact is > > completely irrelevant to the correct parsing of "sizeof x ? B : C". > > > > I responded by expanding on the reason that Ike gave, showing that he was > > right. Therefore, what I said could not be equivalent to what you said, > > because you claimed his reason was wrong. > > > > That is correct. His answer is right - but for the wrong reason. ... > > Furthermore, "x ? B : C" does not appear as an expression anywhere in > > "sizeof x ? B : C". The only sub-expressions of that expression are > > "sizeof x", "B", and "C". Therefore, the fact that, if "x ? B : C" were an > > expression, it would result in only a single value, is completely > > irrelevant to the question at hand. > > > > No, x ? B : C is also an expression - see the trinary operator. And it "x ? B : C" can be an expression, but it is not a sub-expression that occurs anywhere in "sizeof x ? B : C". As a string of tokens, it is a substring of the other string of tokens, but is not a sub-expression of that expression. > does result in a single value - either B or C, depending on the value of x. As is true of all C expressions, and has nothing to do with how this expression should be parsed. > However, sizeof takes has higher precedence, so the sizeof x is > evaluated first. Your reason that sizeof has higher precedence is true only as an incomplete summary of the relevant grammar rules. Ike's reason directly referred to the relevant grammar rules, so in what sense are you claiming his reason is wrong? I'll give you some options to choose from, you can add your own: are you claiming 1. that sizeof doesn't require a unary expression as it's only operand. 2. that x isn't a unary-expression. 3. that x:B?C is a unary-expression. 4. some other statement inconsistent with Ike's stated reason for this parse?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 20:23 -0500 |
| Message-ID | <o8qm61$9om$3@jstuckle.eternal-september.org> |
| In reply to | #104648 |
On 2/24/2017 4:40 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 3:42:19 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 2:43 PM, jameskuyper@verizon.net wrote: > >>> Not as far as I could see. Ike Knarr correctly pointed out that >>> "sizeof x ? B : C" must be parsed as "(sizeof x) ? B : C", which was probably >>> not what BartC had intended. He also gave precisely the correct reason why that's the correct parse for that expression: the fact that sizeof takes a unary-expression for it's only operand. "x" is a unary-expression, "x ? B : C" >>> is not. >>> >>> You responded by saying that Ike was correct in his conclusions, but gave >>> the wrong reason. You then presented "x ? B : C returns a single value" as >>> if it were the correct reason. You then went on to a non-sequitur, pointing >>> out that "sizeof(x ? B : C)" was valid. While correct, that fact is >>> completely irrelevant to the correct parsing of "sizeof x ? B : C". >>> >>> I responded by expanding on the reason that Ike gave, showing that he was >>> right. Therefore, what I said could not be equivalent to what you said, >>> because you claimed his reason was wrong. >>> >> >> That is correct. His answer is right - but for the wrong reason. > ... >>> Furthermore, "x ? B : C" does not appear as an expression anywhere in >>> "sizeof x ? B : C". The only sub-expressions of that expression are >>> "sizeof x", "B", and "C". Therefore, the fact that, if "x ? B : C" were an >>> expression, it would result in only a single value, is completely >>> irrelevant to the question at hand. >>> >> >> No, x ? B : C is also an expression - see the trinary operator. And it > > "x ? B : C" can be an expression, but it is not a sub-expression that occurs anywhere in "sizeof x ? B : C". As a string of tokens, it is a substring of the other string of tokens, but is not a sub-expression of that expression. > >> does result in a single value - either B or C, depending on the value of x. > > As is true of all C expressions, and has nothing to do with how this expression should be parsed. > >> However, sizeof takes has higher precedence, so the sizeof x is >> evaluated first. > > Your reason that sizeof has higher precedence is true only as an incomplete > summary of the relevant grammar rules. Ike's reason directly referred to the > relevant grammar rules, so in what sense are you claiming his reason is wrong? > I'll give you some options to choose from, you can add your own: are you > claiming > > 1. that sizeof doesn't require a unary expression as it's only operand. > 2. that x isn't a unary-expression. > 3. that x:B?C is a unary-expression. > 4. some other statement inconsistent with Ike's stated reason for this parse? > I am claiming nothing of the kind. Do not put words into my mouth. I stand by my statements on precedence and associativity, as defined by K&R. And they use the terms "precedence" and "standard". So now you're telling me K&R is incorrect. Right. No wonder the really knowledgeable C programmers left here. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 18:54 -0800 |
| Message-ID | <cf6051c3-51cf-4fdc-9a8f-08eee65b98ab@googlegroups.com> |
| In reply to | #104674 |
On Friday, February 24, 2017 at 8:23:06 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 4:40 PM, jameskuyper@verizon.net wrote: ... > > Your reason that sizeof has higher precedence is true only as an incomplete > > summary of the relevant grammar rules. Ike's reason directly referred to the > > relevant grammar rules, so in what sense are you claiming his reason is wrong? > > I'll give you some options to choose from, you can add your own: are you > > claiming > > > > 1. that sizeof doesn't require a unary expression as it's only operand. > > 2. that x isn't a unary-expression. > > 3. that x:B?C is a unary-expression. > > 4. some other statement inconsistent with Ike's stated reason for this parse? > > > > I am claiming nothing of the kind. Do not put words into my mouth. I didn't insist on putting words in your mouth. I provided options 1-3 because those are the only things I could imagine justifying a claim that his reason was incorrect. However, I'm fully aware that things I never imagined can also be true, so I also provided option 4, which you could use to provide your own words explaining why Ike's stated reason is wrong. Which you have failed to do. ... > So now you're telling me K&R is incorrect. Yes. It described K&R C basically correctly, while leaving a lot of important details unspecified. The committee produce a standard which specified what is and is not allowed much more precisely than K&R did, and as a result ended using ways of the describing the language different than the ones used by K&R. In particular, it doesn't use precedence rules. K&R's description is a good approximation to standard C, though it becomes less accurate with each revision of the standard. However, K&R never said that precedence determines the order of evaluation. It did say that the order of evaluation of operands is unspecified. As an example of the kinds of problems the committee cleaned up, K&R fails to mention that there are exceptions to that rule. To address a semantic confusion you've frequently expressed today: in C, operators are not evaluated. Expressions, of which operators are a key component, are evaluated. Operands are expressions (modulo some minor issues with the standard's definition of an expression), but there are also expressions that are not operands of any other expression - those are called "full expressions". All expressions have their order of evaluation partially (but not completely) constrained by the rules of the C standard - none of which are operator precedence rules.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 23:17 -0500 |
| Message-ID | <o8r0dh$931$1@jstuckle.eternal-september.org> |
| In reply to | #104684 |
On 2/24/2017 9:54 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 8:23:06 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 4:40 PM, jameskuyper@verizon.net wrote: > ... >>> Your reason that sizeof has higher precedence is true only as an incomplete >>> summary of the relevant grammar rules. Ike's reason directly referred to the >>> relevant grammar rules, so in what sense are you claiming his reason is wrong? >>> I'll give you some options to choose from, you can add your own: are you >>> claiming >>> >>> 1. that sizeof doesn't require a unary expression as it's only operand. >>> 2. that x isn't a unary-expression. >>> 3. that x:B?C is a unary-expression. >>> 4. some other statement inconsistent with Ike's stated reason for this parse? >>> >> >> I am claiming nothing of the kind. Do not put words into my mouth. > > I didn't insist on putting words in your mouth. I provided options 1-3 because those are the only things I could imagine justifying a claim that his reason was incorrect. However, I'm fully aware that things I never imagined can also be true, so I also provided option 4, which you could use to provide your own words explaining why Ike's stated reason is wrong. Which you have failed to do. > > ... >> So now you're telling me K&R is incorrect. > > Yes. It described K&R C basically correctly, while leaving a lot of important details unspecified. The committee produce a standard which specified what is and is not allowed much more precisely than K&R did, and as a result ended using ways of the describing the language different than the ones used by K&R. In particular, it doesn't use precedence rules. K&R's description is a good approximation to standard C, though it becomes less accurate with each revision of the standard. However, K&R never said that precedence determines the order of evaluation. It did say that the order of evaluation of operands is unspecified. As an example of the kinds of problems the committee cleaned up, K&R fails to mention that there are exceptions to that rule. > I'm sure the Committee members are going to be surprised by that statement, especially since they were very careful to ensure C followed K&R in this area - all the way from the first standard. > To address a semantic confusion you've frequently expressed today: in C, operators are not evaluated. Expressions, of which operators are a key component, are evaluated. Operands are expressions (modulo some minor issues with the standard's definition of an expression), but there are also expressions that are not operands of any other expression - those are called "full expressions". All expressions have their order of evaluation partially (but not completely) constrained by the rules of the C standard - none of which are operator precedence rules. > Correct. Expressions are evaluated - according to the precedence and associativity of the operators. However, operands may be evaluated in any order. I really wish people here could UNDERSTAND the standard. All most of them can do is read and quote it. It's no wonder there is so much argument about what the standard says. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-25 19:15 -0800 |
| Message-ID | <ebbded1a-3f6c-4fea-a0f0-4e831cf6307b@googlegroups.com> |
| In reply to | #104688 |
On Friday, February 24, 2017 at 11:17:48 PM UTC-5, Jerry Stuckle wrote:
...
> ... Expressions are evaluated - according to the precedence and
> associativity of the operators. ...
...
> I really wish people here could UNDERSTAND the standard. All most of
> them can do is read and quote it.
I'm sorry - I've looked in K&R, and I've looked in the standard, and I can't find wording that imposes any such requirement on the order of evaluation. Whether it's due to the non-existence of any such requirement (as I claim) or it's due to me being incapable of understanding the standard (as you claim), one consequence is the same: I have no idea precisely how the relevant requirement is worded. This matters, because while I cannot find that requirement, I can find many other requirements on the order in which expressions must be evaluated. Without the precise wording of the rule you're referring to, I can't figure out how it is is supposed to interact with the rules that I can find.
First of all, let me confirm my understanding: to the extent that the grammar can be summarized using precedence rules, a++ is normally given a very high precedence, while a=b is normally given a very low precedence, so the rule you're referring to would require a++ to be evaluated before a=b. Is that consistent with your understanding?
In each of the following cases, one of the rules that I could find in the standard requires, as I understand it, that a=b be evaluated before a++. In each of those cases am I right, or am I misunderstanding the relevant rule, or does the operator precedence rule you're referring to override the rule I cite? I'm not trying to put words in your mouth - if none of those statements covers a given case, feel free to provide an explanation using your own wording about how the specified rule interacts with the operator precedence rule:
6.5.2.2p10:
int f(int a) {a++; return a;}
int main(void)
{
int a=1;
int b=2;
b = f(a=b);
}
6.5.13p4: (a=b) && a++
6.5.14p4: (a=b) || a++
6.5.15p4: (a=b) ? a++ : b++
6.5.17p2: a=b , a++
6.7.6p3: int c[a=b], d[a++];
6.7.9p19: int c[2] = {a=b, a++};
6.8p4: a=b; a++;
if(a=b) a++;
switch(a=b) { case 1: a++;}
while(a=b) a++;
do a=b; while(a++);
for(a=b; a++; );
for(; a=b; a++);
a=b; return a++;
Note: in each of the above cases where execution of a++ is conditional on the value of b, assume that b has a value that will ensure that a++ gets executed.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-25 23:10 -0500 |
| Message-ID | <o8tkc9$ua3$1@jstuckle.eternal-september.org> |
| In reply to | #104739 |
On 2/25/2017 10:15 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 11:17:48 PM UTC-5, Jerry Stuckle wrote: > ... >> ... Expressions are evaluated - according to the precedence and >> associativity of the operators. ... > ... >> I really wish people here could UNDERSTAND the standard. All most of >> them can do is read and quote it. > > I'm sorry - I've looked in K&R, and I've looked in the standard, and I can't find wording that imposes any such requirement on the order of evaluation. Whether it's due to the non-existence of any such requirement (as I claim) or it's due to me being incapable of understanding the standard (as you claim), one consequence is the same: I have no idea precisely how the relevant requirement is worded. This matters, because while I cannot find that requirement, I can find many other requirements on the order in which expressions must be evaluated. Without the precise wording of the rule you're referring to, I can't figure out how it is is supposed to interact with the rules that I can find. > You haven't read very well, then. For instance, in K&R is is on page 53 or page 49 depending on your version. And the standard, if you understood it, explains exactly what order expressions using multiple operators must be evaluated. I suspect you go back to second grade and learn to understand what is being written. The standard is very specific - but obviously written at a level too complicated for you to understand. > First of all, let me confirm my understanding: to the extent that the grammar can be summarized using precedence rules, a++ is normally given a very high precedence, while a=b is normally given a very low precedence, so the rule you're referring to would require a++ to be evaluated before a=b. Is that consistent with your understanding? > Quite frankly, I'm not about to try to teach the pig to sing. There are plenty of sites on the internet which make things clear enough that even you (and many of the others on this newsgroup) should be able to understand. I can see why most of the real C programmers left this group long ago. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-26 12:00 -0500 |
| Message-ID | <fa2e93ad-4504-0945-bc8a-ed15e6a491df@verizon.net> |
| In reply to | #104739 |
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.
I know that you won't bother addressing any issue discussed below,
you'll simply dismiss it as an example of me misunderstanding the
standard. Therefore, there's really no point in you bothering to even
read this message, much less bothering to reply to it. I'm posting it
only for the sake of other people, so they can understand why the rule
you think exists in the standard wouldn't even matter, even if it did exist.
On 02/25/2017 10:15 PM, jameskuyper@verizon.net wrote:
...
> 6.5.2.2p10:
> int f(int a) {a++; return a;}
> int main(void)
> {
> int a=1;
> int b=2;
> b = f(a=b);
> }
>
> 6.5.13p4: (a=b) && a++
> 6.5.14p4: (a=b) || a++
> 6.5.15p4: (a=b) ? a++ : b++
> 6.5.17p2: a=b , a++
> 6.7.6p3: int c[a=b], d[a++];
> 6.7.9p19: int c[2] = {a=b, a++};
> 6.8p4: a=b; a++;
> if(a=b) a++;
> switch(a=b) { case 1: a++;}
> while(a=b) a++;
> do a=b; while(a++);
> for(a=b; a++; );
> for(; a=b; a++);
> a=b; return a++;
>
> Note: in each of the above cases where execution of a++ is
> conditional on the value of b, assume that b has a value that will
> ensure that a++ gets executed.
I'd hoped it wouldn't be hard for you to acknowledge the simple fact
that, in every one of those cases, the specified clause requires that
a=b be evaluated before a++, even though postfix increment has a much
higher order of precedence than assignment. However, as usual, I
overestimated your capacity for rational discussion - you just decided
to go into singing pig mode.
The reason why I chose that particular list of cases, is that it
constitutes a complete list of every rule that allows you to force a
sequence point to separate the evaluation of two expressions with
different precedence levels. 7.21.6p1 describes sequence points that
affect the behavior of calls to the formatted I/O functions, but they do
not separate the evaluation of expressions inside user code. 7.22.5p5
describes sequence points before and after each call to the comparison
function, but those function calls necessarily have the same precedence.
Therefore, if the C standard did in fact have an rule requiring
evaluation of expressions to be done in order of operator precedence
(one that required that in the expression a==b | c*d, the sub-expression
c*d must be evaluated before a==b), then that rule would have to be
overridden by each of the rules cited above. That means the only cases
where such a rule would apply are cases when the two expressions are NOT
separated by a sequence point.
I'd like to thank you for focusing my attention, in a previous response,
on the observable behavior of the program. As a result I realized that
the absence of a sequence point between the expressions has an
interesting consequence: such a rule, if it existed, would never impose
any actual constraints on the observable behavior of the program. That
might be why the C standard doesn't bother imposing any such rule.
That is true because "observable behavior" (5.1.2.3p6) is all about
side-effects (5.1.2.3p2). The side-effects of an expression are only
loosely connected to evaluation of that expression - they can occur at
any time between the preceding and following sequences points. In older
versions of the standard this was stated directly, but in C2011 it's a
fact that can be derived from 5.1.2.3p3.
When neither expression is a sub-expression of the other, there are only
two ways that the order in which they are evaluated can affect the
observable behavior of a program: 1 - one expression has a side effect
on an object, and the other expression has a result that depends upon a
value computation using the value of the same object. 2 - both
expressions have side effects, and the order of evaluation can be
inferred from the order in which those side effects occur.
Way #1 doesn't work, because if there's no sequence point separating the
two expressions, the behavior is undefined by reason of 6.5p2: "If a
side effect on a scalar object is unsequenced relative to ... a value
computation using the value of the same scalar object, the behavior is
undefined.". Prior to C2011, the standard used a simpler, less precise,
and far more confusing way of saying the same thing - so confusing, in
fact, that it was not clear that it WAS saying the same thing - but that
was what it was intended to mean. Therefore, the standard imposes no
requirements of any kind on the behavior of a program containing such code.
Way #2 suffers from the fact that the side effects of the first
expression are only constrained to occur between the same pair of
bracketing sequence points as the side effects of the second one. The
side affects of the two expressions are therefore allowed to occur in
either order, regardless of the order in which the corresponding
expressions are evaluated.
Therefore, you're perfectly free to harbor the delusion that the
standard uses operator precedence for purposes other than determining
which expressions are sub-expressions of other expressions. You can
think that it also imposes requirements on the order of evaluation,
other than the ones associated with the expression/sub-expression
relationship, requirements that depend upon operator precedence.
Violation of such a rule when translating strictly conforming code would
be always produce observable behavior that was equally consistent with
obedience to that rule.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-26 15:57 -0500 |
| Message-ID | <o8vfbo$j14$1@jstuckle.eternal-september.org> |
| In reply to | #104768 |
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. 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. And the rest of your examples are just as much bullshit as this one is. -- ================== 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-26 21:54 +0000 |
| Message-ID | <o8vin4$up1$1@dont-email.me> |
| In reply to | #104789 |
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". -- 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-26 19:45 -0500 |
| Message-ID | <o8vsmf$v6a$1@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". > Not at all, Richard. He included a third operator - the logical AND operator. And that also affects the order of processing. Stoopid is as stoopid does. As you so often prove. -- ================== 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-27 01:29 +0000 |
| Message-ID | <87h93g8lpl.fsf@bsb.me.uk> |
| In reply to | #104801 |
Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > Not at all, Richard. He included a third operator - the logical AND > operator. And that also affects the order of processing. Yes it does, contrary to what you've said in this thread. You said: | Precedence determines which operator evaluations have | higher priority over other operations. Those with higher precedence | have higher priority and are evaluated first.[1] with no exceptions: | Precedence and associativity define the order in which EVERY operator is | evaluated.[2] but with a free choice for operand evaluation order: | Precedence and associativity apply only to the order | of evaluation of operators, and define in which order those operators | will be evaluated. Operands, however, can be evaluated in any | order.[3] The expression x && ++x is a counter example to both claims. [1] Message-ID: <o8qro7$td2$1@jstuckle.eternal-september.org> [2] Message-ID: <o8qlj4$8sr$1@jstuckle.eternal-september.org> [3] Message-ID: <o8qluc$9om$1@jstuckle.eternal-september.org> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 10:52 -0500 |
| Message-ID | <o91hsl$n51$1@jstuckle.eternal-september.org> |
| In reply to | #104809 |
On 2/26/2017 8:29 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> > >> Not at all, Richard. He included a third operator - the logical AND >> operator. And that also affects the order of processing. > > Yes it does, contrary to what you've said in this thread. You said: > Nope. The AND operator affects flow control, not order of processing. It determines IF subsequent expressions are evaluated. > | Precedence determines which operator evaluations have > | higher priority over other operations. Those with higher precedence > | have higher priority and are evaluated first.[1] > > with no exceptions: > That is correct. > | Precedence and associativity define the order in which EVERY operator is > | evaluated.[2] > > but with a free choice for operand evaluation order: > Your proof of that statement? And please don't try to quote your misunderstanding of the standard. > | Precedence and associativity apply only to the order > | of evaluation of operators, and define in which order those operators > | will be evaluated. Operands, however, can be evaluated in any > | order.[3] > > The expression > > x && ++x > > is a counter example to both claims. > Nope. There is no rule as to when operands are evaluated. Either operand may be evaluated first. All we know is that the prefix increment operator will be evaluated before the and operator. > [1] Message-ID: <o8qro7$td2$1@jstuckle.eternal-september.org> > [2] Message-ID: <o8qlj4$8sr$1@jstuckle.eternal-september.org> > [3] Message-ID: <o8qluc$9om$1@jstuckle.eternal-september.org> > Here are three independent, reputable organizations which support my statements: Purdue University: web.ics.purdue.edu/~cs240/misc/operators.html University of Hawaii: 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 Can you show three independent sites which support your claims? -- ================== 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 16:04 +0000 |
| Message-ID | <slrn3vfsob8jjg.aue.ike@iceland.freeshell.org> |
| In reply to | #104879 |
On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: > On 2/26/2017 8:29 PM, Ben Bacarisse wrote: >> The expression >> >> x && ++x >> >> is a counter example to both claims. > > Nope. There is no rule as to when operands are evaluated. Either > operand may be evaluated first. All we know is that the prefix > increment operator will be evaluated before the and operator. Part of the task of the && operator is to decide whether the righthand operand will be evaluated at all (depending on the truth value of the lefthand operand). That decision necessarily has to be made before the ++ expression is evaluated. ~
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 11:16 -0500 |
| Message-ID | <o91j94$sfq$1@jstuckle.eternal-september.org> |
| In reply to | #104882 |
On 2/27/2017 11:04 AM, Ike Naar wrote: > On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >> On 2/26/2017 8:29 PM, Ben Bacarisse wrote: >>> The expression >>> >>> x && ++x >>> >>> is a counter example to both claims. >> >> Nope. There is no rule as to when operands are evaluated. Either >> operand may be evaluated first. All we know is that the prefix >> increment operator will be evaluated before the and operator. > > Part of the task of the && operator is to decide whether the > righthand operand will be evaluated at all (depending on the truth > value of the lefthand operand). That decision necessarily has to > be made before the ++ expression is evaluated. > ~ > That is true. But that is one of the very few exceptions to the rule. Others include the comma and ternary operators. But those are rules specific to the operators themselves, 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. -- ================== 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-27 20:42 +0000 |
| Message-ID | <87lgsrs6vk.fsf@bsb.me.uk> |
| In reply to | #104886 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/27/2017 11:04 AM, Ike Naar wrote: >> On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>> On 2/26/2017 8:29 PM, Ben Bacarisse wrote: >>>> The expression >>>> >>>> x && ++x >>>> >>>> is a counter example to both claims. >>> >>> Nope. There is no rule as to when operands are evaluated. Either >>> operand may be evaluated first. All we know is that the prefix >>> increment operator will be evaluated before the and operator. >> >> Part of the task of the && operator is to decide whether the >> righthand operand will be evaluated at all (depending on the truth >> value of the lefthand operand). That decision necessarily has to >> be made before the ++ expression is evaluated. > > That is true. But that is one of the very few exceptions to the rule. Right. But you recently said: | Precedence determines which operator evaluations have | higher priority over other operations. Those with higher precedence | have higher priority and are evaluated first.[1] and | Precedence and associativity define the order in which EVERY operator is | evaluated.[2] > Others include the comma and ternary operators. ... and || and sizeof (in many cases). Any rule can be claimed to apply to EVERY operator except those that are exceptions. It's much better to use precedence and associativity only as a short-hand for the grammar and not to try to squeeze any semantics out them. > But those are rules specific to the operators themselves, Exactly. It's much better to use precedence and associativity only to explain how an expression is parsed and then to give a summary of the semantics of the operators. > 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. (For example, you often see something like i++, j-- in the third clause of a for statement. Here, the order of evaluation of the operands does not matter so there is no real need for the comma operator, but it's used for the sake of clarity. While i++ & j-- might do instead, it's not nearly as clear.) [1] Message-ID: <o8qro7$td2$1@jstuckle.eternal-september.org> [2] Message-ID: <o8qlj4$8sr$1@jstuckle.eternal-september.org> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 17:18 -0500 |
| Message-ID | <o928g3$glv$1@jstuckle.eternal-september.org> |
| In reply to | #104929 |
On 2/27/2017 3:42 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/27/2017 11:04 AM, Ike Naar wrote: >>> On 2017-02-27, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>> On 2/26/2017 8:29 PM, Ben Bacarisse wrote: >>>>> The expression >>>>> >>>>> x && ++x >>>>> >>>>> is a counter example to both claims. >>>> >>>> Nope. There is no rule as to when operands are evaluated. Either >>>> operand may be evaluated first. All we know is that the prefix >>>> increment operator will be evaluated before the and operator. >>> >>> Part of the task of the && operator is to decide whether the >>> righthand operand will be evaluated at all (depending on the truth >>> value of the lefthand operand). That decision necessarily has to >>> be made before the ++ expression is evaluated. >> >> That is true. But that is one of the very few exceptions to the rule. > > Right. But you recently said: > > | Precedence determines which operator evaluations have > | higher priority over other operations. Those with higher precedence > | have higher priority and are evaluated first.[1] > > and > > | Precedence and associativity define the order in which EVERY operator is > | evaluated.[2] > >> Others include the comma and ternary operators. > > ... and || and sizeof (in many cases). Any rule can be claimed to apply > to EVERY operator except those that are exceptions. It's much better to > use precedence and associativity only as a short-hand for the grammar > and not to try to squeeze any semantics out them. > Yes, and they do. But you have to look at some operators which affect the flow - just as conditional statements like if (...) do. In the case of ternary operators, for instance - the ternary operator has lower precedence than addition. That only means when the ternary operator is included with other expressions, the ternary operator is evaluated after than expressions involving most other operators. It does not apply to expressions within the ternary operator - which are part of the ternary operator, not external to it. >> But those are rules specific to the operators themselves, > > Exactly. It's much better to use precedence and associativity only to > explain how an expression is parsed and then to give a summary of the > semantics of the operators. > The rules determine in which order the expressions must be processed. >> 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. > (For example, you often see something like i++, j-- in the third clause > of a for statement. Here, the order of evaluation of the operands does > not matter so there is no real need for the comma operator, but it's > used for the sake of clarity. While i++ & j-- might do instead, it's > not nearly as clear.) > > [1] Message-ID: <o8qro7$td2$1@jstuckle.eternal-september.org> > [2] Message-ID: <o8qlj4$8sr$1@jstuckle.eternal-september.org> > I provided references to support my case from three independent, respected sources. I can easily supply several hundred more. Can you supply even ONE independent, respected resource, other than your (incorrect) interpretation of the standard? -- ================== 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 01:34 +0000 |
| Message-ID | <87mvd7qerl.fsf@bsb.me.uk> |
| In reply to | #104948 |
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> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-27 17:55 -0800 |
| Message-ID | <e972c145-bf24-40a1-949a-55e236310461@googlegroups.com> |
| In reply to | #104999 |
On Tuesday, February 28, 2017 at 1:35:01 AM UTC, Ben Bacarisse wrote:
>
> Can you give an example of where a comma operator "effectively allows
> multiple statements to be used where only a single expression is
> allowed"?
>
int j = 0;
for(i=0;i<N;i++)
if(keep(&array[i]))
array[j++] = array[i];
N = j;
for(i=0,j=0;i<N;i++)
if(keep(&array[i]))
array[j++] = array[i];
N = j;
It's arguable. Personally I prefer the former style.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-28 02:16 +0000 |
| Message-ID | <87d1e3qcuk.fsf@bsb.me.uk> |
| In reply to | #105005 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, February 28, 2017 at 1:35:01 AM UTC, Ben Bacarisse wrote: >> >> Can you give an example of where a comma operator "effectively allows >> multiple statements to be used where only a single expression is >> allowed"? >> > int j = 0; > for(i=0;i<N;i++) > if(keep(&array[i])) > array[j++] = array[i]; > N = j; > > for(i=0,j=0;i<N;i++) > if(keep(&array[i])) > array[j++] = array[i]; > N = j; > > It's arguable. Personally I prefer the former style. Are you claiming the Jerry means "expressions with a side-effects" by "statement"? Otherwise I've no idea why you think this might be an example of what was said. (By the way, that was my guess too, but I don't like to assume someone is using words so poorly, so i asked.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-28 10:09 +0000 |
| Message-ID | <877f4ar5i8.fsf@bsb.me.uk> |
| In reply to | #105007 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Are you claiming the Jerry means "expressions with a side-effects" by
>>"statement"? Otherwise I've no idea why you think this might be an
>>example of what was said. (By the way, that was my guess too, but I
>>don't like to assume someone is using words so poorly, so i asked.)
>
> One can discuss whether this is - syntactically - an instance
> of a statement contained in an expression:
>
> for(";",0;;);
>
> . I mean »";",0« is an expression. It contains a statement »;«.
No, it contains two expressions.
> Well, someone might say it's not statement /there/. But the
> grammar rule clearly is:
>
> expression-statement:
> expression_opt ;
>
> and it's /context free/! I.e., it does nowhere require that
> it appears at a specific position in the program.
That's not what context free means when talking about grammars.
> Of course,
> it's not where the implementation is expecting a statement,
> so it will never be executed, but a statement it is.
I suspect you're joking and I've taken it too seriously. Sorry if
that's the case.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 20 of 27 — ← Prev page 1 … 18 19 [20] 21 22 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web