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 16 of 27 — ← Prev page 1 … 14 15 [16] 17 18 … 27 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-02 15:54 -0500 |
| Message-ID | <o9a0nd$snc$1@dont-email.me> |
| In reply to | #105123 |
Jerry's uncharacteristic silence has given me some time to think about
this issue more carefully. The idea that operator precedence and
associativity always determine the order of evaluation of C expressions,
with expressions with a high precedence always being
evaluated first, and associativity being used to break ties between
expressions with the same precedence is very popular, and has been
around for a very long time. Jerry didn't invent it, not by a long
shot, but I need a simple name for this rule, so I'll call it the
"Stuckle rule" in honor of Jerry Stuckle.
In reality, there is no such rule in the C standard. The only thing
directly determined by precedence and associativity is the question of
which expressions are sub-expressions of which other expressions, and
the standard doesn't use those terms to specify the grammar which could
be (for the most part) accurately described by them. So why is belief
in the Stuckle rule so common?
6.5p1 requires that "The value computations of the operands of an
operator are sequenced before the value computation of the result of
the operator.". Most of the time, the operands will have an operator
with a precedence level greater than or equal to the precedence of the
operator itself, and when the precedence is equal, the
expression/sub-expression relationship can usually be determined by
applying associativity. For instance, the correct way to parse the
following expression
a * b / c && (int)d & e == f != g | h < i > j || k + l - m
can be determined entirely by thinking in terms of operator precedence
and associativity as follows:
((((a * b) / c) && (int)d) & ((e == f) != g)) | (((h < i) > j) ||
((k + l) - m))
The constraints imposed by 6.5p1 are therefore:
1. a and b must both be evaluated before the multiplication.
2. The multiplication and c must both be evaluated before the division.
3. The division must be evaluated before the logical-AND expression, and
if the cast expression is evaluated, it must be done before the
logical-AND expression.
4. The equality comparison must be evaluated before the inequality
comparison.
5. The logical-AND and inequality comparison must be completed before
the bit-wise &.
6. h and i must be evaluated before the less-than comparison.
7. The less-than comparison and j must both be evaluated before the
greater-than comparison.
k and l must be evaluated before the addition.
8. The addition and m must be evaluated before the subtraction.
9. The greater-than comparison must be evaluated before the logical-OR
expression, and if the subtraction is evaluated, it must also be done
before the logical-OR expression.
10. The bitwise-AND and the logical-OR expressions must both be
evaluated before the bitwise-OR expression.
Every single one of those restrictions can also be derived from the
Stuckle rule, which probably helps explain why belief in the Stuckle
rule is so common.
So does that mean that 6.5p1 IS in fact the Stuckle rule? It isn't
written using the concepts of operator precedence and associativity, but
then, neither are the grammar rules.
Not quite - the Stuckle rule, as described by Jerry, would seem to
require that the cast be evaluated before the logical-AND expression,
and that the subtraction be performed before the bitwise-AND expression,
but 6.5p1 imposes no such requirements. However, Jerry has acknowledged
that the order of evaluation of the operands of an operator is not
determined by the Stuckle rule. He's also acknowledged that sequence
relationships imposed by sequence points (which he calls "control flow")
override the Stuckle rule. He has, of course, never presented a version
of the Stuckle rule written in such a way as to allow for such exceptions.
Still, could the Stuckle rule be described as a rule derived from 6.5p1
in combination with the grammar rules?
No - because it depends subtly upon how the grammar rules are written,
and there's six different cases where the C grammar defines an
expression as containing a sub-expression that could have a lower
precedence. In all six cases, this works because the expression syntax
surrounds the relevant sub-expression. Here's an example including all
six cases. I use integer constants for expressions that are not
evaluated, or which must have a specific value in order for other
expressions to be evaluated:
(_Generic( 1: int: a && (func_type*){func1=func2}[2?b,c:0](d||e) ))
6.5p1 imposes the following requirements:
1. The generic expression* must be evaluated before the parenthesized
expression can be.
2. The logical-AND expression* must be evaluated before the generic
expression.
3. The function call and a must be evaluated before the logical-AND
expression.
4. The subscript expression and logical-OR expression* must be evaluated
before the function call.
5. The compound literal and the conditional expression* must be
evaluated before the subscript expression.
6. The assignment expression* must be evaluated before the compound
literal can be.
7. func1 and func2 must be evaluated before the assignment expression
can be.
8. 2 and the comma expression* must be evaluated before conditional
expression.
9. b and c must be evaluated before the comma expression
10. d and e must be evaluated before the logical-OR expression.
Note the * that I've placed after each sub-expression which has a lower
precedence than the expression containing it. The same rule which, in
the previous case, imposed requirements consistent with the Stuckle rule
imposes requirements in these six cases that contradict that rule.
Therefore, 6.5p1 is NOT the Stuckle rule.
Now, two of those constructs didn't even exist in C90, which seems to be
Jerry's primary focus. The other four can each be dismissed as an
exception, and I'm sure he would do so. He's made it clear that he
doesn't believe in the existence of the function-call operator, even
though the standard itself uses the term. He'd described the
parenthesized expression as a device that raises the precedence of an
expression, rather than as a type of expression in it's own right, which
is the way the standard describes it. It's not at all clear how he would
dismiss the subscript and conditional expression cases, but I have faith
in his ability to come up with some excuse for doing so.
Let's assume that he does. We can then describe the combination of most
of C's grammar for expressions as combining with 6.5p1 to impose the
Stuckle rule, as long as we allow for exceptions for those six cases,
and say that sequence requirements imposed by sequence points override
the rule, and that the rule doesn't apply to determining the order
between the sub-expressions of another expression.
That's a very complicated rule with lots of exception that can be
derived from the more fundamental rules, but is not itself a fundamental
rule. The very next version of the standard could add yet another new
type of expression whose grammar requires it to be yet one more
exception to the rule.
To the extent that the Stuckle rule imposes the same requirements as the
C standard, it can be derived from two rules which can be expressed much
more simply: use the C grammar to determine which expressions are
sub-expressions of which other expressions, and always evaluate
sub-expressions before the expression they are part of. Why not remember
those simple rules rather than the complicated exception-ridden Stuckle
rule? You need to understand the grammar anyway, otherwise you won't be
able to avoid/detect syntax errors, regardless of what the sequence
rules say. And 6.5p1 is so obviously true that C2011 is the first
version of the standard to state it explicitly. It was simply assumed to
be true in all previous versions, as well as in K&R1.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-03 11:26 +0100 |
| Message-ID | <o9bg9h$rga$1@dont-email.me> |
| In reply to | #105333 |
On 02/03/17 21:54, James Kuyper wrote: > Jerry's uncharacteristic silence has given me some time to think about > this issue more carefully. The idea that operator precedence and > associativity always determine the order of evaluation of C expressions, > with expressions with a high precedence always being > evaluated first, and associativity being used to break ties between > expressions with the same precedence is very popular, and has been > around for a very long time. Jerry didn't invent it, not by a long > shot, but I need a simple name for this rule, so I'll call it the > "Stuckle rule" in honor of Jerry Stuckle. > (I snipped the rest of your detailed and informative post, simply to save space.) Would it be fair to say that if you have an expression where no sub-expression has any side effects (no volatile accesses, ++ operators, assignment operators, etc., and only "pure" function calls) then the Stuckle rule will apply? If you have "x && y" and "y" has no side effects, then it makes no difference to the outcome of the program whether y (or its sub-expressions) is evaluated, even if x evaluates to 0. I think it is reasonable to suggest that most real-life expressions in well-written code are going to fall into this category. Side-effect causing parts of expressions are mostly the outermost operator - the assignment operator, function call, etc. (There are a few exceptions, such as the idiomatic "*p++ = *q++"). Most of the examples in this thread for expressions that don't follow the Stuckle rule are rather contrived, and would be unlikely to occur in real code. So if we follow Heathfield's rule of writing readable code and restrict our sub-expressions to Malcolm-functions, then Stuckle's rule applies :-)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-03 10:33 +0000 |
| Message-ID | <o9bgn0$suv$1@dont-email.me> |
| In reply to | #105343 |
On 03/03/17 10:26, David Brown wrote: > On 02/03/17 21:54, James Kuyper wrote: >> Jerry's uncharacteristic silence has given me some time to think about >> this issue more carefully. The idea that operator precedence and >> associativity always determine the order of evaluation of C expressions, >> with expressions with a high precedence always being >> evaluated first, and associativity being used to break ties between >> expressions with the same precedence is very popular, and has been >> around for a very long time. Jerry didn't invent it, not by a long >> shot, but I need a simple name for this rule, so I'll call it the >> "Stuckle rule" in honor of Jerry Stuckle. >> > > (I snipped the rest of your detailed and informative post, simply to > save space.) > > Would it be fair to say that if you have an expression where no > sub-expression has any side effects (no volatile accesses, ++ operators, > assignment operators, etc., and only "pure" function calls) then the > Stuckle rule will apply? If the Stuckle "rule" did not work *most of the time*, it would never have survived as a meme. In that respect, it is no different to void main, casting malloc, and not casting a pointer for %p. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-03 12:30 +0100 |
| Message-ID | <o9bk0l$8at$1@dont-email.me> |
| In reply to | #105344 |
On 03/03/17 11:33, Richard Heathfield wrote: > On 03/03/17 10:26, David Brown wrote: >> On 02/03/17 21:54, James Kuyper wrote: >>> Jerry's uncharacteristic silence has given me some time to think about >>> this issue more carefully. The idea that operator precedence and >>> associativity always determine the order of evaluation of C expressions, >>> with expressions with a high precedence always being >>> evaluated first, and associativity being used to break ties between >>> expressions with the same precedence is very popular, and has been >>> around for a very long time. Jerry didn't invent it, not by a long >>> shot, but I need a simple name for this rule, so I'll call it the >>> "Stuckle rule" in honor of Jerry Stuckle. >>> >> >> (I snipped the rest of your detailed and informative post, simply to >> save space.) >> >> Would it be fair to say that if you have an expression where no >> sub-expression has any side effects (no volatile accesses, ++ operators, >> assignment operators, etc., and only "pure" function calls) then the >> Stuckle rule will apply? > > If the Stuckle "rule" did not work *most of the time*, it would never > have survived as a meme. Yes - it is a very useful "rule of thumb", as long as we remember not to apply it if evaluation order actually matters. > In that respect, it is no different to void > main, casting malloc, and not casting a pointer for %p. > It is quite different from these. An implementation is free to allow "void main". Casting the result of malloc is a matter of style preference - it is perfectly well defined and some people (perhaps especially C++ fans) consider it /good/ style. Using %p without casting /may/ be an error, but it will work as expected on the majority of implementations. But if you have an expression for which the Stuckle rule does not apply, then the C grammar rules involved cannot be overridden by the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-03 11:32 +0000 |
| Message-ID | <o9bk4n$8gc$1@dont-email.me> |
| In reply to | #105345 |
On 03/03/17 11:30, David Brown wrote: > On 03/03/17 11:33, Richard Heathfield wrote: >> On 03/03/17 10:26, David Brown wrote: >>> On 02/03/17 21:54, James Kuyper wrote: >>>> Jerry's uncharacteristic silence has given me some time to think about >>>> this issue more carefully. The idea that operator precedence and >>>> associativity always determine the order of evaluation of C expressions, >>>> with expressions with a high precedence always being >>>> evaluated first, and associativity being used to break ties between >>>> expressions with the same precedence is very popular, and has been >>>> around for a very long time. Jerry didn't invent it, not by a long >>>> shot, but I need a simple name for this rule, so I'll call it the >>>> "Stuckle rule" in honor of Jerry Stuckle. >>>> >>> >>> (I snipped the rest of your detailed and informative post, simply to >>> save space.) >>> >>> Would it be fair to say that if you have an expression where no >>> sub-expression has any side effects (no volatile accesses, ++ operators, >>> assignment operators, etc., and only "pure" function calls) then the >>> Stuckle rule will apply? >> >> If the Stuckle "rule" did not work *most of the time*, it would never >> have survived as a meme. > > Yes - it is a very useful "rule of thumb", as long as we remember not to > apply it if evaluation order actually matters. > >> In that respect, it is no different to void >> main, casting malloc, and not casting a pointer for %p. >> > > It is quite different from these. I draw your attention to the words "in that respect". -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-03 13:48 +0100 |
| Message-ID | <o9bojq$o14$1@dont-email.me> |
| In reply to | #105346 |
On 03/03/17 12:32, Richard Heathfield wrote: > On 03/03/17 11:30, David Brown wrote: >> On 03/03/17 11:33, Richard Heathfield wrote: >>> On 03/03/17 10:26, David Brown wrote: >>>> On 02/03/17 21:54, James Kuyper wrote: >>>>> Jerry's uncharacteristic silence has given me some time to think about >>>>> this issue more carefully. The idea that operator precedence and >>>>> associativity always determine the order of evaluation of C >>>>> expressions, >>>>> with expressions with a high precedence always being >>>>> evaluated first, and associativity being used to break ties between >>>>> expressions with the same precedence is very popular, and has been >>>>> around for a very long time. Jerry didn't invent it, not by a long >>>>> shot, but I need a simple name for this rule, so I'll call it the >>>>> "Stuckle rule" in honor of Jerry Stuckle. >>>>> >>>> >>>> (I snipped the rest of your detailed and informative post, simply to >>>> save space.) >>>> >>>> Would it be fair to say that if you have an expression where no >>>> sub-expression has any side effects (no volatile accesses, ++ >>>> operators, >>>> assignment operators, etc., and only "pure" function calls) then the >>>> Stuckle rule will apply? >>> >>> If the Stuckle "rule" did not work *most of the time*, it would never >>> have survived as a meme. >> >> Yes - it is a very useful "rule of thumb", as long as we remember not to >> apply it if evaluation order actually matters. >> >>> In that respect, it is no different to void >>> main, casting malloc, and not casting a pointer for %p. >>> >> >> It is quite different from these. > > I draw your attention to the words "in that respect". > Ah yes, that makes a difference!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-03 12:41 +0000 |
| Message-ID | <87lgsmleh9.fsf@bsb.me.uk> |
| In reply to | #105343 |
David Brown <david.brown@hesbynett.no> writes: > On 02/03/17 21:54, James Kuyper wrote: >> Jerry's uncharacteristic silence has given me some time to think about >> this issue more carefully. The idea that operator precedence and >> associativity always determine the order of evaluation of C expressions, >> with expressions with a high precedence always being >> evaluated first, and associativity being used to break ties between >> expressions with the same precedence is very popular, and has been >> around for a very long time. Jerry didn't invent it, not by a long >> shot, but I need a simple name for this rule, so I'll call it the >> "Stuckle rule" in honor of Jerry Stuckle. >> > > (I snipped the rest of your detailed and informative post, simply to > save space.) > > Would it be fair to say that if you have an expression where no > sub-expression has any side effects (no volatile accesses, ++ operators, > assignment operators, etc., and only "pure" function calls) then the > Stuckle rule will apply? If you have "x && y" and "y" has no side > effects, then it makes no difference to the outcome of the program > whether y (or its sub-expressions) is evaluated, even if x evaluates > to 0. It depends on what you mean by saying that the rule will apply. The compiler can't assume the rule applies because after seeing x && 1/x such a compiler could act as if x != 0 from here on. In other words it's not a rule about the language, but only (once hedged with "as if" and corrected by removing all the exceptions) a rule to help explain the value of expressions to beginners. But in my experience, the worst thing about it (especially as described in the cited Microsoft page) is that it often misleads beginners into think it applies to the operands. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-03 12:47 +0000 |
| Message-ID | <o9bohv$nrn$1@dont-email.me> |
| In reply to | #105347 |
On 03/03/17 12:41, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 02/03/17 21:54, James Kuyper wrote: >>> Jerry's uncharacteristic silence has given me some time to think about >>> this issue more carefully. The idea that operator precedence and >>> associativity always determine the order of evaluation of C expressions, >>> with expressions with a high precedence always being >>> evaluated first, and associativity being used to break ties between >>> expressions with the same precedence is very popular, and has been >>> around for a very long time. Jerry didn't invent it, not by a long >>> shot, but I need a simple name for this rule, so I'll call it the >>> "Stuckle rule" in honor of Jerry Stuckle. >>> >> >> (I snipped the rest of your detailed and informative post, simply to >> save space.) >> >> Would it be fair to say that if you have an expression where no >> sub-expression has any side effects (no volatile accesses, ++ operators, >> assignment operators, etc., and only "pure" function calls) then the >> Stuckle rule will apply? If you have "x && y" and "y" has no side >> effects, then it makes no difference to the outcome of the program >> whether y (or its sub-expressions) is evaluated, even if x evaluates >> to 0. > > It depends on what you mean by saying that the rule will apply. Well, it never *actually* applies. But there are circumstances in which the implementation may behave "as if" it applies. > The compiler can't assume the rule applies Right. :-) -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-03 12:57 +0000 |
| Message-ID | <87fuiuldql.fsf@bsb.me.uk> |
| In reply to | #105348 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 03/03/17 12:41, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 02/03/17 21:54, James Kuyper wrote: >>>> Jerry's uncharacteristic silence has given me some time to think about >>>> this issue more carefully. The idea that operator precedence and >>>> associativity always determine the order of evaluation of C expressions, >>>> with expressions with a high precedence always being >>>> evaluated first, and associativity being used to break ties between >>>> expressions with the same precedence is very popular, and has been >>>> around for a very long time. Jerry didn't invent it, not by a long >>>> shot, but I need a simple name for this rule, so I'll call it the >>>> "Stuckle rule" in honor of Jerry Stuckle. >>>> >>> >>> (I snipped the rest of your detailed and informative post, simply to >>> save space.) >>> >>> Would it be fair to say that if you have an expression where no >>> sub-expression has any side effects (no volatile accesses, ++ operators, >>> assignment operators, etc., and only "pure" function calls) then the >>> Stuckle rule will apply? If you have "x && y" and "y" has no side >>> effects, then it makes no difference to the outcome of the program >>> whether y (or its sub-expressions) is evaluated, even if x evaluates >>> to 0. >> >> It depends on what you mean by saying that the rule will apply. > > Well, it never *actually* applies. But there are circumstances in > which the implementation may behave "as if" it applies. And, curiously, you cut the very next sentence where I said exactly that. :-( <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-03 13:12 +0000 |
| Message-ID | <o9bq0f$spd$1@dont-email.me> |
| In reply to | #105350 |
On 03/03/17 12:57, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 03/03/17 12:41, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 02/03/17 21:54, James Kuyper wrote: >>>>> Jerry's uncharacteristic silence has given me some time to think about >>>>> this issue more carefully. The idea that operator precedence and >>>>> associativity always determine the order of evaluation of C expressions, >>>>> with expressions with a high precedence always being >>>>> evaluated first, and associativity being used to break ties between >>>>> expressions with the same precedence is very popular, and has been >>>>> around for a very long time. Jerry didn't invent it, not by a long >>>>> shot, but I need a simple name for this rule, so I'll call it the >>>>> "Stuckle rule" in honor of Jerry Stuckle. >>>>> >>>> >>>> (I snipped the rest of your detailed and informative post, simply to >>>> save space.) >>>> >>>> Would it be fair to say that if you have an expression where no >>>> sub-expression has any side effects (no volatile accesses, ++ operators, >>>> assignment operators, etc., and only "pure" function calls) then the >>>> Stuckle rule will apply? If you have "x && y" and "y" has no side >>>> effects, then it makes no difference to the outcome of the program >>>> whether y (or its sub-expressions) is evaluated, even if x evaluates >>>> to 0. >>> >>> It depends on what you mean by saying that the rule will apply. >> >> Well, it never *actually* applies. But there are circumstances in >> which the implementation may behave "as if" it applies. > > And, curiously, you cut the very next sentence where I said exactly > that. :-( Oops. Quite right. Sorry, Ben. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-03 13:57 +0100 |
| Message-ID | <o9bp4a$q5j$1@dont-email.me> |
| In reply to | #105347 |
On 03/03/17 13:41, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 02/03/17 21:54, James Kuyper wrote: >>> Jerry's uncharacteristic silence has given me some time to think about >>> this issue more carefully. The idea that operator precedence and >>> associativity always determine the order of evaluation of C expressions, >>> with expressions with a high precedence always being >>> evaluated first, and associativity being used to break ties between >>> expressions with the same precedence is very popular, and has been >>> around for a very long time. Jerry didn't invent it, not by a long >>> shot, but I need a simple name for this rule, so I'll call it the >>> "Stuckle rule" in honor of Jerry Stuckle. >>> >> >> (I snipped the rest of your detailed and informative post, simply to >> save space.) >> >> Would it be fair to say that if you have an expression where no >> sub-expression has any side effects (no volatile accesses, ++ operators, >> assignment operators, etc., and only "pure" function calls) then the >> Stuckle rule will apply? If you have "x && y" and "y" has no side >> effects, then it makes no difference to the outcome of the program >> whether y (or its sub-expressions) is evaluated, even if x evaluates >> to 0. > > It depends on what you mean by saying that the rule will apply. The > compiler can't assume the rule applies because after seeing > > x && 1/x > > such a compiler could act as if x != 0 from here on. In other words > it's not a rule about the language, but only (once hedged with "as if" > and corrected by removing all the exceptions) a rule to help explain the > value of expressions to beginners. > > But in my experience, the worst thing about it (especially as described > in the cited Microsoft page) is that it often misleads beginners into > think it applies to the operands. > Yes, pages that don't explain the details, or even worse state explicitly that precedence/association defines evaluation order, are a bad thing. Accurate pages are more useful: <http://en.cppreference.com/w/c/language/operator_precedence> (This page also mentions a difference between C and C++ that I was not aware of.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-03 05:23 -0800 |
| Message-ID | <0f665c0f-2dae-41cd-8a09-3f13052290ef@googlegroups.com> |
| In reply to | #105347 |
On Friday, March 3, 2017 at 6:41:30 AM UTC-6, Ben Bacarisse wrote: > David Brown writes: > > Would it be fair to say that if you have an expression where no > > sub-expression has any side effects (no volatile accesses, ++ operators, > > assignment operators, etc., and only "pure" function calls) then the > > Stuckle rule will apply? If you have "x && y" and "y" has no side > > effects, then it makes no difference to the outcome of the program > > whether y (or its sub-expressions) is evaluated, even if x evaluates > > to 0. > > It depends on what you mean by saying that the rule will apply. The > compiler can't assume the rule applies because after seeing > > x && 1/x > > such a compiler could act as if x != 0 from here on. In other words > it's not a rule about the language, but only (once hedged with "as if" > and corrected by removing all the exceptions) a rule to help explain the > value of expressions to beginners. If an implementation guaranteed that 1/x would never have any side-effects then the rule would be applicable to such an expression. Of course, if an implementation offered such a guarantee, that would imply that the behavior of executing 1/x would be defined for all possible x, and could not use that expression to make any inferences about what values x might hold.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-03 15:58 +0100 |
| Message-ID | <o9c06b$j2j$1@dont-email.me> |
| In reply to | #105354 |
On 03/03/17 14:23, supercat@casperkitty.com wrote:
> On Friday, March 3, 2017 at 6:41:30 AM UTC-6, Ben Bacarisse wrote:
>> David Brown writes:
>>> Would it be fair to say that if you have an expression where no
>>> sub-expression has any side effects (no volatile accesses, ++ operators,
>>> assignment operators, etc., and only "pure" function calls) then the
>>> Stuckle rule will apply? If you have "x && y" and "y" has no side
>>> effects, then it makes no difference to the outcome of the program
>>> whether y (or its sub-expressions) is evaluated, even if x evaluates
>>> to 0.
>>
>> It depends on what you mean by saying that the rule will apply. The
>> compiler can't assume the rule applies because after seeing
>>
>> x && 1/x
>>
>> such a compiler could act as if x != 0 from here on. In other words
>> it's not a rule about the language, but only (once hedged with "as if"
>> and corrected by removing all the exceptions) a rule to help explain the
>> value of expressions to beginners.
>
> If an implementation guaranteed that 1/x would never have any side-effects
> then the rule would be applicable to such an expression.
I suppose optimising due to undefined behaviour of 1/0, in the way Ben
suggests, would count as a side effect.
> Of course, if an
> implementation offered such a guarantee, that would imply that the behavior
> of executing 1/x would be defined for all possible x, and could not use that
> expression to make any inferences about what values x might hold.
>
No, that is not quite correct. An implementation can say that 1/0
returns an unspecified value - that would not be fully defined, but it
would not be fully defined either. It could implement reciprocal as
effectively:
int recip(int x) {
if (x == 0) return;
return recip_nonzero(x);
}
That is not legal C code for a user, but an implementation could do this
sort of thing.
Alternatively, the compiler the compiler could pick a value that made
other code optimisations more efficient. And it could pick different
values for depending on where the 1/x occurred in the source code, or
even different values on different runs. That would still not be a side
effect, but it would not be a fully defined behaviour either.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-03 07:13 -0800 |
| Message-ID | <99d7019d-d070-4e71-848c-74d15daca153@googlegroups.com> |
| In reply to | #105356 |
On Friday, March 3, 2017 at 8:58:27 AM UTC-6, David Brown wrote:
> On 03/03/17 14:23, supercat wrote:
> > If an implementation guaranteed that 1/x would never have any side-effects
> > then the rule would be applicable to such an expression.
>
> I suppose optimising due to undefined behaviour of 1/0, in the way Ben
> suggests, would count as a side effect.
Yes, that would definitely count as a rather severe side-effect.
> > Of course, if an
> > implementation offered such a guarantee, that would imply that the behavior
> > of executing 1/x would be defined for all possible x, and could not use that
> > expression to make any inferences about what values x might hold.
>
> No, that is not quite correct. An implementation can say that 1/0
> returns an unspecified value - that would not be fully defined, but it
> would not be fully defined either. It could implement reciprocal as
> effectively:
>
> int recip(int x) {
> if (x == 0) return;
> return recip_nonzero(x);
> }
>
> That is not legal C code for a user, but an implementation could do this
> sort of thing.
I should perhaps have said "yield some kind of value with no side-effect",
but hadn't considered the possibility that an expression of type "int" might
complete without side-effect without yielding a value. Though it should
be noted that an implementation that made the latter substitution might
specify something about the behavior of using the return value of a function
that returned without specifying one [e.g. it might guarantee that the return
will behave as an integer number which may or may not be within the range of
"int", and that if such a value is stored in a variable of type "int" it may
read back as the value stored or as any number whose lower part matches that
of the stored value.]. Such a guarantee would allow a lot of optimizations
but still allow code to pass values around "safely" if it could tolerate such
behavior.
> Alternatively, the compiler the compiler could pick a value that made
> other code optimisations more efficient. And it could pick different
> values for depending on where the 1/x occurred in the source code, or
> even different values on different runs. That would still not be a side
> effect, but it would not be a fully defined behaviour either.
By definition, if an action invokes Undefined Behavior, there are no
limits as to what consequences may result. If an implementation offers
any guarantees about the consequences of some action, it does not invoke
Undefined Behavior.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-03 12:53 -0500 |
| Message-ID | <o9caes$p6d$1@dont-email.me> |
| In reply to | #105343 |
On 03/03/2017 05:26 AM, David Brown wrote: ... > Would it be fair to say that if you have an expression where no > sub-expression has any side effects (no volatile accesses, ++ operators, > assignment operators, etc., and only "pure" function calls) then the > Stuckle rule will apply? If you have "x && y" and "y" has no side > effects, then it makes no difference to the outcome of the program > whether y (or its sub-expressions) is evaluated, even if x evaluates to 0. > > I think it is reasonable to suggest that most real-life expressions in > well-written code are going to fall into this category. Side-effect > causing parts of expressions are mostly the outermost operator - the > assignment operator, function call, etc. (There are a few exceptions, > such as the idiomatic "*p++ = *q++"). Most of the examples in this > thread for expressions that don't follow the Stuckle rule are rather > contrived, and would be unlikely to occur in real code. As I pointed out, parenthesized expressions, subscripts, _Generic, function calls, the conditional operator, and compound literals all allow an expression with a low precedence can be a sub-expressions of an expression with higher precedence. The same rule that, in most cases, required high-precedence expressions to be evaluated before low precedence one, makes exactly the opposite requirement in those cases. _Generic and compound literals are fairly new, the conditional operator is rarely used, but parentheses, subscripts, and function calls are very common in real-life well-written code. You don't need to look at side-effects to recognize which expressions in each of those cases must be evaluated first - if the sub-expression weren't evaluated first, you couldn't evaluate the expression as a whole. I suspect that is what makes them invisible to believers in the Stuckle rule - I suspect they only use it to disambiguate cases where the grammar could have been written to enforce a different order of precedence or associativity. Since the order with which the Stuckle rule would require them to be evaluated in is clearly infeasible, they don't even notice that it does actually require that order.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-03-03 19:33 +0000 |
| Message-ID | <8737eukvet.fsf@bsb.me.uk> |
| In reply to | #105359 |
James Kuyper <jameskuyper@verizon.net> writes: > On 03/03/2017 05:26 AM, David Brown wrote: > ... >> Would it be fair to say that if you have an expression where no >> sub-expression has any side effects (no volatile accesses, ++ operators, >> assignment operators, etc., and only "pure" function calls) then the >> Stuckle rule will apply? If you have "x && y" and "y" has no side >> effects, then it makes no difference to the outcome of the program >> whether y (or its sub-expressions) is evaluated, even if x evaluates to 0. >> >> I think it is reasonable to suggest that most real-life expressions in >> well-written code are going to fall into this category. Side-effect >> causing parts of expressions are mostly the outermost operator - the >> assignment operator, function call, etc. (There are a few exceptions, >> such as the idiomatic "*p++ = *q++"). Most of the examples in this >> thread for expressions that don't follow the Stuckle rule are rather >> contrived, and would be unlikely to occur in real code. > > As I pointed out, parenthesized expressions, subscripts, _Generic, > function calls, the conditional operator, and compound literals all > allow an expression with a low precedence can be a sub-expressions of an > expression with higher precedence. The same rule that, in most cases, > required high-precedence expressions to be evaluated before low > precedence one, makes exactly the opposite requirement in those cases. But none of these are governed by precedence -- or at least it's much better not to try to talk about them that way. Everyone learns in school that (a+b)*c is a way to make the multiplication act on the sum, and things like [exp] and a ? exp : b are just funny looking parentheses. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-03-03 21:18 -0500 |
| Message-ID | <o9d82o$s9t$1@dont-email.me> |
| In reply to | #105360 |
On 03/03/2017 02:33 PM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: ... >> On 03/03/2017 05:26 AM, David Brown wrote: >> As I pointed out, parenthesized expressions, subscripts, _Generic, >> function calls, the conditional operator, and compound literals all >> allow an expression with a low precedence can be a sub-expressions of an >> expression with higher precedence. The same rule that, in most cases, >> required high-precedence expressions to be evaluated before low >> precedence one, makes exactly the opposite requirement in those cases. > > But none of these are governed by precedence -- or at least it's much True - but according to the Stuckle rule, all expressions are evaluated in an order determined by precedence and associativity. That is why it must, at a minimum, be modified to acknowledge those cases as exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-03 21:23 -0500 |
| Message-ID | <o9d8b4$s95$1@jstuckle.eternal-september.org> |
| In reply to | #105333 |
On 3/2/2017 3:54 PM, James Kuyper wrote: > Jerry's uncharacteristic silence has given me some time to think about > this issue more carefully. The idea that operator precedence and > associativity always determine the order of evaluation of C expressions, > with expressions with a high precedence always being > evaluated first, and associativity being used to break ties between > expressions with the same precedence is very popular, and has been > around for a very long time. Jerry didn't invent it, not by a long > shot, but I need a simple name for this rule, so I'll call it the > "Stuckle rule" in honor of Jerry Stuckle. > I appreciate it, but the correct name would be the "K&R Rule" - since it first appeared in K&R, published several years before I started programming in C. And I'm quite because I'm tired of trying to teach pigs to sing. These idiots keep claiming they are right, but have no independent, respected source to back them up. That's because they can't find any. While I've listed several resources, starting with K&R. -- ================== 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 19:58 +0100 |
| Message-ID | <o94h4b$dku$1@dont-email.me> |
| In reply to | #105116 |
On 28/02/17 18:27, Jerry Stuckle wrote: > > I've pointed to three independent and respected organizations, all which > say the same thing. And even your blessed GNU C compiler documentation > says the same thing: > > https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Operator-Precedence > 1. This is not documentation for the GNU C compiler. It is a "C Reference Manual" written by GNU, for C "as implemented by the GNU C Compiler". That's a different thing - it is an independent document and not part of the gcc documentation. Plus it's a bit out of date. 2. It describes the operator precedence, but makes absolutely /no/ claims precedence relates to the order of evaluation. Order of evaluation is covered in the next section. That runs counter to your claims that precedence determines the order of evaluation.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 15:21 -0500 |
| Message-ID | <o94lvh$dl$1@jstuckle.eternal-september.org> |
| In reply to | #105141 |
On 2/28/2017 1:58 PM, David Brown wrote:
> On 28/02/17 18:27, Jerry Stuckle wrote:
>
>>
>> I've pointed to three independent and respected organizations, all which
>> say the same thing. And even your blessed GNU C compiler documentation
>> says the same thing:
>>
>> https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Operator-Precedence
>>
>
> 1. This is not documentation for the GNU C compiler. It is a "C
> Reference Manual" written by GNU, for C "as implemented by the GNU C
> Compiler". That's a different thing - it is an independent document and
> not part of the gcc documentation. Plus it's a bit out of date.
>
> 2. It describes the operator precedence, but makes absolutely /no/
> claims precedence relates to the order of evaluation. Order of
> evaluation is covered in the next section.
>
> That runs counter to your claims that precedence determines the order of
> evaluation.
>
>
You don't read very well, do you? But that's not surprising. To quote:
"When an expression contains multiple operators, such as a + b * f(),
the operators are grouped based on rules of precedence. For instance,
the meaning of that expression is to call the function f with no
arguments, multiply the result by b, then add that result to a. That’s
what the C rules of operator precedence determine for this expression.
The following is a list of types of expressions, presented in order of
highest precedence first. Sometimes two or more operators have equal
precedence; all those operators are applied from left to right unless
stated otherwise. "
3.20 deals with the evaluation of operands, and by when the evaluation
must be completed. But you still don't understand the difference
between an operator and an operand. They use as an example:
static int a = 1;
static int f (void)
{
a = 100;
return 3;
}
int foo (void)
{
return ++a * f();
}
Where the resultant value is indeterminate because there is no way to
guarantee which of two independent operands (++x and f()) are evaluated
first. All that is guaranteed is that both will be evaluated before the
multiplication.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
Page 16 of 27 — ← Prev page 1 … 14 15 [16] 17 18 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web