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 19 of 27 — ← Prev page 1 … 17 18 [19] 20 21 … 27 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 15:39 -0500 |
| Message-ID | <o8q5i1$ksp$1@jstuckle.eternal-september.org> |
| In reply to | #104634 |
On 2/24/2017 3:22 PM, jameskuyper@verizon.net wrote: > On Sunday, February 19, 2017 at 11:42:36 AM UTC-5, Jerry Stuckle wrote: > ... >> Nope. Every operation is based on precedence and associativity. x?B:C >> is an expression which returns a unary result, which is why >> sizeof(x?B:C) works. >> >> However, in the absence of parens, there are two operators - the uniary >> sizeof and ternary ?:. Precedence rules require the unary operator be >> evaluated before the ternary operator. > > C is not defined in terms of precedence rules or associativity rules. It does > have a grammar, many parts of which lend themselves to being summarized by > precedence and associativity, but other parts do not. In particular, a > precedence table for C would necessarily place the comma operator as having the > lowest possible precedence. That explains perfectly well why a,b?c:d,e must be > parsed as a,(b?c:d),e, but it does not explain why a?b,c:d must be parsed as > a?(b,c):d, rather than (a?b),(c:d), which would be a syntax error. The grammar > rules, on the other hand, make it perfectly clear: the middle operand is > specified as being an "expression", referring to the grammar rule in (6.5.15p1). > So from what you're saying, the C compiler developers can evaluate multiple operators in any order. That's what you would have with no precedence or associativity rules. > The grammar has an effect on the order of evaluation, but only a limited one: > "The value computations of the operands of an operator are sequenced before the > value computation of the result of the operator." (6.5p1). This means that > evaluation of "x" would be sequenced before evaluation of "sizeof x" (a fact > that's meaningful only if x has a variable length array type - otherwise > evaluation of the operand of sizeof is suppressed (6.5.3.4p2)). It also means > that that evaluation of "sizeof x", and either "B" or "C" (depending upon the > value of "sizeof x") is sequenced before evaluation of the entire expression. > However, that's the full extent of the influence that the grammar has over the > order of evaluation. "The grouping of operators and operands is indicated by > the syntax. Except as specified later, side effects and value computations of > subexpressions are unsequenced." (6.5p3). > Which is precedence, is it not? > The semantics of conditional expressions does specify that "sizeof x" gets evaluated before "B" or "C", with a sequence point between them (6.5.15p4) - but the grammar has nothing to say about that issue. > > If the full expression had been "sizeof x + B + C", then evaluation of "sizeof x" and "B" would both be sequenced before evaluation of their sum, but the two expressions would be unsequenced relative to each other. The evaluation of C and the evaluation of the first sum, would both be sequenced before evaluation of the final sum. However, evaluation of "C" would be unsequenced relative to any of the other sub-expressions. > Not necessarily, according to your statement that C has no precedence or associativity rules. Learn to UNDERSTAND the standard - not just read it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 13:26 -0800 |
| Message-ID | <d58fde6d-b898-4ad8-944d-3840a10ac392@googlegroups.com> |
| In reply to | #104638 |
On Friday, February 24, 2017 at 3:39:23 PM UTC-5, Jerry Stuckle wrote:
> On 2/24/2017 3:22 PM, jameskuyper@verizon.net wrote:
...
> > C is not defined in terms of precedence rules or associativity rules. It does
> > have a grammar, many parts of which lend themselves to being summarized by
> > precedence and associativity, but other parts do not. In particular, a
> > precedence table for C would necessarily place the comma operator as having the
> > lowest possible precedence. That explains perfectly well why a,b?c:d,e must be
> > parsed as a,(b?c:d),e, but it does not explain why a?b,c:d must be parsed as
> > a?(b,c):d, rather than (a?b),(c:d), which would be a syntax error. The grammar
> > rules, on the other hand, make it perfectly clear: the middle operand is
> > specified as being an "expression", referring to the grammar rule in (6.5.15p1).
> >
>
> So from what you're saying, the C compiler developers can evaluate
> multiple operators in any order. That's what you would have with no
> precedence or associativity rules.
Without precedence or associativity rules, the C standard still has a grammar, and rules about the sequencing of the evaluation of expressions that are connected to that grammar. Those rules give some of the same results that you would get by mistakenly assuming that precedence determined the order of evaluation, but it also produces different results in some circumstances.
> > The grammar has an effect on the order of evaluation, but only a limited
> > one: "The value computations of the operands of an operator are sequenced
> > before the value computation of the result of the operator." (6.5p1). This
> > means that evaluation of "x" would be sequenced before evaluation of
> > "sizeof x" (a fact that's meaningful only if x has a variable length array
> > type - otherwise evaluation of the operand of sizeof is suppressed
> > (6.5.3.4p2)). It also means that that evaluation of "sizeof x", and either
> > "B" or "C" (depending upon the value of "sizeof x") is sequenced before
> > evaluation of the entire expression.
> > However, that's the full extent of the influence that the grammar has over
> > the order of evaluation. "The grouping of operators and operands is
> > indicated by the syntax. Except as specified later, side effects and value
> > computations of subexpressions are unsequenced." (6.5p3).
> >
>
> Which is precedence, is it not?
No - precedence is about "grouping of operators and operands", not about the sequencing of side effects and value computations. It's easiest to show the difference in terms of sub-expressions that have side effects, so let a(), b(), and c() be three different functions that are defined as returning 1 and having the side effect of printing "a", "b", and "c" respectively. The precedence rule that can be validly deduced from the C grammar for + and * says that printf("%d", a()+b()*c()) must be grouped as printf("%d", (a()+(b()*c()))), but says nothing about the order of evaluation. I'll use "E(f)<E(g)" to indicate that evaluation of f is sequenced before evaluation of g". 6.5p1 (and NOT the precedence rules implied by the grammar) says:
E(b()) < E(b()*c())
E(c()) < E(b()*c())
E(a()) < E(a()+b()*c())
E(b()*c()) < E(a()+b()*c())
E(a()+b()*c()) < E(printf("%d", a()+b()*c())
6.5p3 says that all of those expressions are otherwise unsequenced. Therefore, any other constraints that you might derive from assuming that precedence determines order of evaluation do not in fact apply to C expressions. All of following outputs are allowed by the C standard for this expression:
abc2
cab2
bca2
cba2
acb2
bac2
> > The semantics of conditional expressions does specify that "sizeof x" gets
> > evaluated before "B" or "C", with a sequence point between them (6.5.15p4)
> > - but the grammar has nothing to say about that issue.
> >
> > If the full expression had been "sizeof x + B + C", then evaluation of
> > "sizeof x" and "B" would both be sequenced before evaluation of their sum,
> > but the two expressions would be unsequenced relative to each other. The
> > evaluation of C and the evaluation of the first sum, would both be
> > sequenced before evaluation of the final sum. However, evaluation of "C"
> > would be unsequenced relative to any of the other sub-expressions.
> >
>
> Not necessarily, according to your statement that C has no precedence or
> associativity rules.
According to my statement that C has grammar rules, and sequencing requirements
that are tied to those rules, everything I've said about what's sequenced and
unsequenced is necessarily true - without the C standard containing a single
operator precedence rule, and despite the fact that the C standard's grammar
rules have features that cannot be completely described in terms of precedence
and associativity.
All you have to do to contradict our claim that C is not defined in terms of operator precedence rules is to cite the location of at least one such rule. Which you can't.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-24 18:53 -0500 |
| Message-ID | <5db7245a-b747-4b07-9891-aa8670a8fef0@verizon.net> |
| In reply to | #104646 |
On 02/24/2017 04:26 PM, jameskuyper@verizon.net wrote:
...
> No - precedence is about "grouping of operators and operands", not
> about the sequencing of side effects and value computations. It's
> easiest to show the difference in terms of sub-expressions that have
> side effects, so let a(), b(), and c() be three different functions that
> are defined as returning 1 and having the side effect of printing "a",
> "b", and "c" respectively. The precedence rule that can be validly
> deduced from the C grammar for + and * says that printf("%d",
> a()+b()*c()) must be grouped as printf("%d", (a()+(b()*c()))), but
> says nothing about the order of evaluation. I'll use "E(f)<E(g)" to
indicate
> that evaluation of f is sequenced before evaluation of g". 6.5p1 (and
> NOT the precedence rules implied by the grammar) says:
>
> E(b()) < E(b()*c())
> E(c()) < E(b()*c())
> E(a()) < E(a()+b()*c())
> E(b()*c()) < E(a()+b()*c())
> E(a()+b()*c()) < E(printf("%d", a()+b()*c())
>
> 6.5p3 says that all of those expressions are otherwise unsequenced. Therefore, any other constraints that you might derive from assuming that precedence determines order of evaluation do not in fact apply to C expressions. All of following outputs are allowed by the C standard for this expression:
>
> abc2
> cab2
> bca2
> cba2
> acb2
> bac2
I just realized that my example, while explaining precisely how the C
grammar imposes sequencing requirements on the evaluation of
expressions, fails to demonstrate a contradiction with the point of view
that precedence determines the order of evaluation. To demonstrate that,
I need a expression with two sub-expressions, each of which involves an
operator with a different precedence. Example:
a()*b() | c()==d()
Sections 6.5p1 of the C standard requires the following:
E( a() ) < E( a()*b() )
E( b() ) < E( a()*b() )
E( c() ) < E( c()==d() )
E( d() ) < E( c()==d() )
E( a()*b() ) < E( a()*b() | c()==d() )
E( c()==d() ) < E( a()*b() | c()==d() )
If you believe that operator precedence determines the order of
evaluation, then if follows that a()*b() must be evaluated before
c()==d(), because multiplication has a higher precedence than comparison
for equality. This corresponds to the constraint that:
E( a()*b() ) < E( c()==d() )
However, 6.5p3 says that there is no such constraint. The output
cdab
which is permitted by the 6.5p3, would be prohibited if the order of
evaluation was controlled by precedence rules.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 20:14 -0500 |
| Message-ID | <o8qlmk$8sr$2@jstuckle.eternal-september.org> |
| In reply to | #104661 |
On 2/24/2017 6:53 PM, James R. Kuyper wrote:
> On 02/24/2017 04:26 PM, jameskuyper@verizon.net wrote:
> ...
>> No - precedence is about "grouping of operators and operands", not
>> about the sequencing of side effects and value computations. It's
>> easiest to show the difference in terms of sub-expressions that have
>> side effects, so let a(), b(), and c() be three different functions that
>> are defined as returning 1 and having the side effect of printing "a",
>> "b", and "c" respectively. The precedence rule that can be validly
>> deduced from the C grammar for + and * says that printf("%d",
>> a()+b()*c()) must be grouped as printf("%d", (a()+(b()*c()))), but
>> says nothing about the order of evaluation. I'll use "E(f)<E(g)" to
> indicate
>> that evaluation of f is sequenced before evaluation of g". 6.5p1 (and
>> NOT the precedence rules implied by the grammar) says:
>>
>> E(b()) < E(b()*c())
>> E(c()) < E(b()*c())
>> E(a()) < E(a()+b()*c())
>> E(b()*c()) < E(a()+b()*c())
>> E(a()+b()*c()) < E(printf("%d", a()+b()*c())
>>
>> 6.5p3 says that all of those expressions are otherwise unsequenced.
>> Therefore, any other constraints that you might derive from assuming
>> that precedence determines order of evaluation do not in fact apply to
>> C expressions. All of following outputs are allowed by the C standard
>> for this expression:
>>
>> abc2
>> cab2
>> bca2
>> cba2
>> acb2
>> bac2
>
> I just realized that my example, while explaining precisely how the C
> grammar imposes sequencing requirements on the evaluation of
> expressions, fails to demonstrate a contradiction with the point of view
> that precedence determines the order of evaluation. To demonstrate that,
> I need a expression with two sub-expressions, each of which involves an
> operator with a different precedence. Example:
>
> a()*b() | c()==d()
>
> Sections 6.5p1 of the C standard requires the following:
>
> E( a() ) < E( a()*b() )
> E( b() ) < E( a()*b() )
> E( c() ) < E( c()==d() )
> E( d() ) < E( c()==d() )
> E( a()*b() ) < E( a()*b() | c()==d() )
> E( c()==d() ) < E( a()*b() | c()==d() )
>
> If you believe that operator precedence determines the order of
> evaluation, then if follows that a()*b() must be evaluated before
> c()==d(), because multiplication has a higher precedence than comparison
> for equality. This corresponds to the constraint that:
>
> E( a()*b() ) < E( c()==d() )
>
> However, 6.5p3 says that there is no such constraint. The output
>
> cdab
>
> which is permitted by the 6.5p3, would be prohibited if the order of
> evaluation was controlled by precedence rules.
Incorrect. Precedence and associativity define the order in which
OPERATORS are evaluated. a(), b(), c() and d() are OPERANDS and can be
evaluated in any order.
Operator is not the same as operand.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 20:13 -0500 |
| Message-ID | <o8qlj4$8sr$1@jstuckle.eternal-september.org> |
| In reply to | #104646 |
On 2/24/2017 4:26 PM, jameskuyper@verizon.net wrote:
> On Friday, February 24, 2017 at 3:39:23 PM UTC-5, Jerry Stuckle wrote:
>> On 2/24/2017 3:22 PM, jameskuyper@verizon.net wrote:
> ...
>>> C is not defined in terms of precedence rules or associativity rules. It does
>>> have a grammar, many parts of which lend themselves to being summarized by
>>> precedence and associativity, but other parts do not. In particular, a
>>> precedence table for C would necessarily place the comma operator as having the
>>> lowest possible precedence. That explains perfectly well why a,b?c:d,e must be
>>> parsed as a,(b?c:d),e, but it does not explain why a?b,c:d must be parsed as
>>> a?(b,c):d, rather than (a?b),(c:d), which would be a syntax error. The grammar
>>> rules, on the other hand, make it perfectly clear: the middle operand is
>>> specified as being an "expression", referring to the grammar rule in (6.5.15p1).
>>>
>>
>> So from what you're saying, the C compiler developers can evaluate
>> multiple operators in any order. That's what you would have with no
>> precedence or associativity rules.
>
> Without precedence or associativity rules, the C standard still has a grammar, and rules about the sequencing of the evaluation of expressions that are connected to that grammar. Those rules give some of the same results that you would get by mistakenly assuming that precedence determined the order of evaluation, but it also produces different results in some circumstances.
>
So from what you're saying, the C compiler developers can evaluate
multiple operators in any order. I understand.
>>> The grammar has an effect on the order of evaluation, but only a limited
>>> one: "The value computations of the operands of an operator are sequenced
>>> before the value computation of the result of the operator." (6.5p1). This
>>> means that evaluation of "x" would be sequenced before evaluation of
>>> "sizeof x" (a fact that's meaningful only if x has a variable length array
>>> type - otherwise evaluation of the operand of sizeof is suppressed
>>> (6.5.3.4p2)). It also means that that evaluation of "sizeof x", and either
>>> "B" or "C" (depending upon the value of "sizeof x") is sequenced before
>>> evaluation of the entire expression.
>>> However, that's the full extent of the influence that the grammar has over
>>> the order of evaluation. "The grouping of operators and operands is
>>> indicated by the syntax. Except as specified later, side effects and value
>>> computations of subexpressions are unsequenced." (6.5p3).
>>>
>>
>> Which is precedence, is it not?
>
> No - precedence is about "grouping of operators and operands", not about the sequencing of side effects and value computations. It's easiest to show the difference in terms of sub-expressions that have side effects, so let a(), b(), and c() be three different functions that are defined as returning 1 and having the side effect of printing "a", "b", and "c" respectively. The precedence rule that can be validly deduced from the C grammar for + and * says that printf("%d", a()+b()*c()) must be grouped as printf("%d", (a()+(b()*c()))), but says nothing about the order of evaluation. I'll use "E(f)<E(g)" to indicate that evaluation of f is sequenced before evaluation of g". 6.5p1 (and NOT the precedence rules implied by the grammar) says:
>
> E(b()) < E(b()*c())
> E(c()) < E(b()*c())
> E(a()) < E(a()+b()*c())
> E(b()*c()) < E(a()+b()*c())
> E(a()+b()*c()) < E(printf("%d", a()+b()*c())
>
> 6.5p3 says that all of those expressions are otherwise unsequenced. Therefore, any other constraints that you might derive from assuming that precedence determines order of evaluation do not in fact apply to C expressions. All of following outputs are allowed by the C standard for this expression:
>
> abc2
> cab2
> bca2
> cba2
> acb2
> bac2
>
You need to look up the definition of the term "precedence". It has
nothing to do with grouping. But I know you won't. You'll argue that
you're bullshit opinion is right until the day you die.
>>> The semantics of conditional expressions does specify that "sizeof x" gets
>>> evaluated before "B" or "C", with a sequence point between them (6.5.15p4)
>>> - but the grammar has nothing to say about that issue.
>>>
>>> If the full expression had been "sizeof x + B + C", then evaluation of
>>> "sizeof x" and "B" would both be sequenced before evaluation of their sum,
>>> but the two expressions would be unsequenced relative to each other. The
>>> evaluation of C and the evaluation of the first sum, would both be
>>> sequenced before evaluation of the final sum. However, evaluation of "C"
>>> would be unsequenced relative to any of the other sub-expressions.
>>>
>>
>> Not necessarily, according to your statement that C has no precedence or
>> associativity rules.
>
> According to my statement that C has grammar rules, and sequencing requirements
> that are tied to those rules, everything I've said about what's sequenced and
> unsequenced is necessarily true - without the C standard containing a single
> operator precedence rule, and despite the fact that the C standard's grammar
> rules have features that cannot be completely described in terms of precedence
> and associativity.
>
> All you have to do to contradict our claim that C is not defined in terms of operator precedence rules is to cite the location of at least one such rule. Which you can't.
>
Precedence and associativity define the order in which EVERY operator is
evaluated.
You want the rules? They are defined in the first version of K&R.
You can read the standard. But it is obvious you do not UNDERSTAND the
standard. No surprise there - you do that regularly.
--
==================
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:33 -0800 |
| Message-ID | <09abec7b-d4fd-447a-add1-fc4f9f713bdb@googlegroups.com> |
| In reply to | #104668 |
On Friday, February 24, 2017 at 8:13:01 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 4:26 PM, jameskuyper@verizon.net wrote: ... > > Without precedence or associativity rules, the C standard still has a > > grammar, and rules about the sequencing of the evaluation of expressions > > that are connected to that grammar. Those rules give some of the same > > results that you would get by mistakenly assuming that precedence > > determined the order of evaluation, but it also produces different results > > in some circumstances. > > > > So from what you're saying, the C compiler developers can evaluate > multiple operators in any order. I understand. Obviously you don't. What I said is that C compiler developers can evaluate expressions (not operators) in any order that conforms to the requirements of 6.5p1, and the additional requirements about sequencing expressed elsewhere in the standard. Those requirements are not precedence rules, nor are they defined in terms of operator precedence. But despite that fact, they do exist and do have to be obeyed by a conforming implementation of C. Claiming that I've denied the existence of those rules, after I explicitly referred to them, doesn't make me look dumb, it makes you look ridiculous. ... > You need to look up the definition of the term "precedence". The C standard itself has no definition of that term; however it very specifically says that "The grouping of operators and operands is indicated by the syntax. Except as specified later, side effects and value computations of subexpressions are unsequenced." (6.5p3). That specification overrides any definitions of the relevant terms that are inconsistent with that specification. If you think that operator precedence necessarily means that evaluation of expressions involving operators with higher precedence must be sequenced before evaluation of expressions involving operators with lower precedence, either C operators don't have precedence in the sense that you mean, or you're using a definition of precedence that's incompatible with 6.5p3. Wiktionary gives the definition "The state of preceding in importance or priority." It notably fails to specify "in order of evaluation". That fact that operators with higher precedence group expressions together with a higher priority than operators with lower precedence is sufficient to satisfy that definition. > It has > nothing to do with grouping. But I know you won't. You'll argue that > you're bullshit opinion is right until the day you die. No I won't. I'll get bored of contradicting your nonsense long before I die, unless it's your nonsense that triggers the heart attack that causes my death. ... > Precedence and associativity define the order in which EVERY operator is > evaluated. No, they only define the priority with which grouping occurs. > You want the rules? They are defined in the first version of K&R. K&R1 is only a historical reference nowadays, not a normative one. The standard doesn't use operator precedence rules to describe C, and never has. I'm only interested in discussing long obsolete versions of C for historical purposes, and as far as I'm concerned K&R C was obsolete by 1995 (I know that other people have different opinions on the matter). When I say "C is not defined by precedence rules", I'm referring to the current standard (though the statement is equally true of the earlier standards).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 21:58 -0500 |
| Message-ID | <o8qro7$td2$1@jstuckle.eternal-september.org> |
| In reply to | #104681 |
On 2/24/2017 9:33 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 8:13:01 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 4:26 PM, jameskuyper@verizon.net wrote: > ... >>> Without precedence or associativity rules, the C standard still has a >>> grammar, and rules about the sequencing of the evaluation of expressions >>> that are connected to that grammar. Those rules give some of the same >>> results that you would get by mistakenly assuming that precedence >>> determined the order of evaluation, but it also produces different results >>> in some circumstances. >>> >> >> So from what you're saying, the C compiler developers can evaluate >> multiple operators in any order. I understand. > > Obviously you don't. What I said is that C compiler developers can evaluate > expressions (not operators) in any order that conforms to the requirements of > 6.5p1, and the additional requirements about sequencing expressed elsewhere in > the standard. Those requirements are not precedence rules, nor are they defined > in terms of operator precedence. But despite that fact, they do exist and do > have to be obeyed by a conforming implementation of C. Claiming that I've > denied the existence of those rules, after I explicitly referred to them, > doesn't make me look dumb, it makes you look ridiculous. > I understand completely. You read the standard, but you do not understand it. Expressions containing operators are evaluated in a specific order. This order was first specified in K&R, according to the table of precedence and associativity. But you said C has no precedence rules. So you did deny the existence of those rules. > ... >> You need to look up the definition of the term "precedence". > > The C standard itself has no definition of that term; however it very > specifically says that "The grouping of operators and operands is indicated by > the syntax. Except as specified later, side effects and value computations of > subexpressions are unsequenced." (6.5p3). That specification overrides any > definitions of the relevant terms that are inconsistent with that > specification. If you think that operator precedence necessarily means that > evaluation of expressions involving operators with higher precedence must be > sequenced before evaluation of expressions involving operators with lower > precedence, either C operators don't have precedence in the sense that you mean, or you're using a definition of precedence that's incompatible with > 6.5p3. > > Wiktionary gives the definition "The state of preceding in importance or > priority." It notably fails to specify "in order of evaluation". That fact that > operators with higher precedence group expressions together with a higher > priority than operators with lower precedence is sufficient to satisfy that > definition. > That is true. Precedence determines which operator evaluations have higher priority over other operations. Those with higher precedence have higher priority and are evaluated first. >> It has >> nothing to do with grouping. But I know you won't. You'll argue that >> you're bullshit opinion is right until the day you die. > > No I won't. I'll get bored of contradicting your nonsense long before I die, > unless it's your nonsense that triggers the heart attack that causes my death. > That is exactly what you are doing. > ... >> Precedence and associativity define the order in which EVERY operator is >> evaluated. > > No, they only define the priority with which grouping occurs. > >> You want the rules? They are defined in the first version of K&R. > > K&R1 is only a historical reference nowadays, not a normative one. The > standard doesn't use operator precedence rules to describe C, and never has. > I'm only interested in discussing long obsolete versions of C for historical > purposes, and as far as I'm concerned K&R C was obsolete by 1995 (I know that > other people have different opinions on the matter). When I say "C is not > defined by precedence rules", I'm referring to the current standard (though the > statement is equally true of the earlier standards). > So you're saying that the K&R has nothing to do with C nowadays? That is even stoopider than most of the things I've read in this newsgroup. I'm sure committee members would get a huge laugh out of it. It's no wonder the real C experts abandoned this newsgroup years ago. No one on our private server would ever make such an inane comment. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 19:38 -0800 |
| Message-ID | <3774b6a7-8f02-4e2a-a7fc-8728876423da@googlegroups.com> |
| In reply to | #104685 |
On Friday, February 24, 2017 at 9:58:09 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 9:33 PM, jameskuyper@verizon.net wrote: > > On Friday, February 24, 2017 at 8:13:01 PM UTC-5, Jerry Stuckle wrote: ... > >> nothing to do with grouping. But I know you won't. You'll argue that > >> you're bullshit opinion is right until the day you die. > > > > No I won't. I'll get bored of contradicting your nonsense long before I die, > > unless it's your nonsense that triggers the heart attack that causes my death. > > > > That is exactly what you are doing. No, it isn't. I've reached my boredom threshold, and will leave all of your current and subsequence nonsense on this topic unaddressed. The fact that it has taken this long for me to reach that point is a tribute to how much I don't want to do the things I should have been doing with this time. Let's put it this way - one of the least pleasant tasks I have to deal with regularly nowadays is changing the diaper of a toddler who is violently opposed to having his diaper changed. The tasks I'm putting off by arguing with your are much less pleasant than that one.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 23:21 -0500 |
| Message-ID | <o8r0k0$931$3@jstuckle.eternal-september.org> |
| In reply to | #104687 |
On 2/24/2017 10:38 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 9:58:09 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 9:33 PM, jameskuyper@verizon.net wrote: >>> On Friday, February 24, 2017 at 8:13:01 PM UTC-5, Jerry Stuckle wrote: > ... >>>> nothing to do with grouping. But I know you won't. You'll argue that >>>> you're bullshit opinion is right until the day you die. >>> >>> No I won't. I'll get bored of contradicting your nonsense long before I die, >>> unless it's your nonsense that triggers the heart attack that causes my death. >>> >> >> That is exactly what you are doing. > > No, it isn't. I've reached my boredom threshold, and will leave all of your > current and subsequence nonsense on this topic unaddressed. The fact that it > has taken this long for me to reach that point is a tribute to how much I don't > want to do the things I should have been doing with this time. > Let's put it this way - one of the least pleasant tasks I have to deal with > regularly nowadays is changing the diaper of a toddler who is violently opposed > to having his diaper changed. The tasks I'm putting off by arguing with your > are much less pleasant than that one. > It's too bad you read the standard but don't understand it. I'm glad you aren't working on any compilers. And that goes for several other people in this newsgroup. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-25 06:57 -0800 |
| Message-ID | <a8d55d3e-eed6-45d7-aa94-39984da18fc5@googlegroups.com> |
| In reply to | #104690 |
On Friday, February 24, 2017 at 11:21:17 PM UTC-5, Jerry Stuckle wrote:
...
> It's too bad you read the standard but don't understand it. I'm glad
> you aren't working on any compilers.
You're right that I don't work on compilers, but apparently some people who do agree with me. The following program:
#include <stdio.h>
static unsigned a(void) { putchar('a'); return 1;}
static unsigned b(void) { putchar('b'); return 2;}
static unsigned c(void) { putchar('c'); return 3;}
static unsigned d(void) { putchar('d'); return 4;}
int main(void)
{
printf("%u\n", a()==b() | c()*d());
return 0;
}
when compiled using
gcc -std=c99 -pedantic -Wall -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wmissing-prototypes
Produces a program that executes to produce the following output:
abcd12
even though * has a higher precedence than ==. How odd! Examination of the generated assembly code confirms that it doesn't just call a(), b(), c() and d(), saving their results in registers, and then evaluate the *, == and | expressions in order of precedence:
.file "precedence.c"
.text
.type a, @function
a:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $97, %edi
call putchar
movl $1, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size a, .-a
.type b, @function
b:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $98, %edi
call putchar
movl $2, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size b, .-b
.type c, @function
c:
.LFB2:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $99, %edi
call putchar
movl $3, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2:
.size c, .-c
.type d, @function
d:
.LFB3:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $100, %edi
call putchar
movl $4, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE3:
.size d, .-d
.section .rodata
.LC0:
.string "%u\n"
.text
.globl main
.type main, @function
main:
.LFB4:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
pushq %r12
pushq %rbx
.cfi_offset 3, -32
.cfi_offset 12, -24
call a
movl %eax, %ebx
call b
cmpl %eax, %ebx
sete %al
movzbl %al, %r12d
call c
movl %eax, %ebx
call d
imull %ebx, %eax
movl %r12d, %edx
orl %eax, %edx
movl $.LC0, %eax
movl %edx, %esi
movq %rax, %rdi
movl $0, %eax
call printf
movl $0, %eax
popq %rbx
popq %r12
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE4:
.size main, .-main
.ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-17)"
.section .note.GNU-stack,"",@progbits
Note that the imull instruction is executed after the cmpl instruction. Apparently the people who design gcc had just as much difficulty as I did locating the clause in the standard that mandates that expressions be evaluated in order of operator precedence. Perhaps civilization is doomed.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-25 16:08 -0500 |
| Message-ID | <o8srkv$ubj$1@jstuckle.eternal-september.org> |
| In reply to | #104699 |
On 2/25/2017 9:57 AM, jameskuyper@verizon.net wrote:
> On Friday, February 24, 2017 at 11:21:17 PM UTC-5, Jerry Stuckle wrote:
> ...
>> It's too bad you read the standard but don't understand it. I'm glad
>> you aren't working on any compilers.
>
> You're right that I don't work on compilers, but apparently some people who do agree with me. The following program:
>
> #include <stdio.h>
>
> static unsigned a(void) { putchar('a'); return 1;}
> static unsigned b(void) { putchar('b'); return 2;}
> static unsigned c(void) { putchar('c'); return 3;}
> static unsigned d(void) { putchar('d'); return 4;}
>
> int main(void)
> {
> printf("%u\n", a()==b() | c()*d());
> return 0;
> }
>
> when compiled using
>
> gcc -std=c99 -pedantic -Wall -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wmissing-prototypes
>
> Produces a program that executes to produce the following output:
> abcd12
>
> even though * has a higher precedence than ==. How odd! Examination of the generated assembly code confirms that it doesn't just call a(), b(), c() and d(), saving their results in registers, and then evaluate the *, == and | expressions in order of precedence:
>
> .file "precedence.c"
> .text
> .type a, @function
> a:
> .LFB0:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> movl $97, %edi
> call putchar
> movl $1, %eax
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE0:
> .size a, .-a
> .type b, @function
> b:
> .LFB1:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> movl $98, %edi
> call putchar
> movl $2, %eax
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE1:
> .size b, .-b
> .type c, @function
> c:
> .LFB2:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> movl $99, %edi
> call putchar
> movl $3, %eax
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE2:
> .size c, .-c
> .type d, @function
> d:
> .LFB3:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> movl $100, %edi
> call putchar
> movl $4, %eax
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE3:
> .size d, .-d
> .section .rodata
> .LC0:
> .string "%u\n"
> .text
> .globl main
> .type main, @function
> main:
> .LFB4:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> pushq %r12
> pushq %rbx
> .cfi_offset 3, -32
> .cfi_offset 12, -24
> call a
> movl %eax, %ebx
> call b
> cmpl %eax, %ebx
> sete %al
> movzbl %al, %r12d
> call c
> movl %eax, %ebx
> call d
> imull %ebx, %eax
> movl %r12d, %edx
> orl %eax, %edx
> movl $.LC0, %eax
> movl %edx, %esi
> movq %rax, %rdi
> movl $0, %eax
> call printf
> movl $0, %eax
> popq %rbx
> popq %r12
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE4:
> .size main, .-main
> .ident "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-17)"
> .section .note.GNU-stack,"",@progbits
>
> Note that the imull instruction is executed after the cmpl instruction. Apparently the people who design gcc had just as much difficulty as I did locating the clause in the standard that mandates that expressions be evaluated in order of operator precedence. Perhaps civilization is doomed.
>
You cannot go by the assembler output. The compiler IS allowed to
change the order of any sequence of expressions - *IFF (if and only if)
THE REORDERING DOES NOT CHANGE THE RESULT*.
It could even so something like:
a = 3;
b = 4;
c = 3;
And change that to
a = c = 3;
b = 4;
But that does not change the precedence or associativity rules.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2017-02-24 15:03 -0800 |
| Message-ID | <o8qe1e$kma$1@dont-email.me> |
| In reply to | #104638 |
On 2/24/2017 12:39 PM, Jerry Stuckle wrote: >> >> C is not defined in terms of precedence rules or associativity rules. It does >> have a grammar, many parts of which lend themselves to being summarized by >> precedence and associativity, but other parts do not. In particular, a >> precedence table for C would necessarily place the comma operator as having the >> lowest possible precedence. That explains perfectly well why a,b?c:d,e must be >> parsed as a,(b?c:d),e, but it does not explain why a?b,c:d must be parsed as >> a?(b,c):d, rather than (a?b),(c:d), which would be a syntax error. The grammar >> rules, on the other hand, make it perfectly clear: the middle operand is >> specified as being an "expression", referring to the grammar rule in (6.5.15p1). >> > > So from what you're saying, the C compiler developers can evaluate > multiple operators in any order. That's what you would have with no > precedence or associativity rules. False. Firstly, even if we assume that "precedence or associativity rules" exist in C, it still would not help with order of evaluation. Precedence or associativity rules have nothing to do with order of evaluation. Secondly, C has no "precedence or associativity rules" per se. The grammar includes a number of cyclical (i.e. non-transitive) substructures, which makes it impossible to linearize it into "precedence or associativity rules". Instead C has sequencing rules that impose some partial temporal relationships between subexpressions, i.e. some partial order of evaluation. >> order of evaluation. "The grouping of operators and operands is indicated by >> the syntax. Except as specified later, side effects and value computations of >> subexpressions are unsequenced." (6.5p3). > > Which is precedence, is it not? Yes, it is precedence. Note that it describes the _grouping_ between operators and their operands. It does not even attempt to touch the subject of the "order of evaluation", which is what is explicitly stated in the above quote from the standard. >> The semantics of conditional expressions does specify that "sizeof x" gets evaluated before "B" or "C", with a sequence point between them (6.5.15p4) - but the grammar has nothing to say about that issue. >> >> If the full expression had been "sizeof x + B + C", then evaluation of "sizeof x" and "B" would both be sequenced before evaluation of their sum, but the two expressions would be unsequenced relative to each other. The evaluation of C and the evaluation of the first sum, would both be sequenced before evaluation of the final sum. However, evaluation of "C" would be unsequenced relative to any of the other sub-expressions. > > Not necessarily, according to your statement that C has no precedence or > associativity rules. Huh? Apparently this is hopeless... > Learn to UNDERSTAND the standard - not just read it. Troll alert? -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-25 12:12 +1300 |
| Message-ID | <ehbsunF5ugU7@mid.individual.net> |
| In reply to | #104657 |
On 02/25/17 12:03 PM, Andrey Tarasevich wrote: > On 2/24/2017 12:39 PM, Jerry Stuckle wrote: > > Huh? Apparently this is hopeless... > >> Learn to UNDERSTAND the standard - not just read it. > > Troll alert? Belated... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 20:20 -0500 |
| Message-ID | <o8qm1f$9om$2@jstuckle.eternal-september.org> |
| In reply to | #104659 |
On 2/24/2017 6:12 PM, Ian Collins wrote: > On 02/25/17 12:03 PM, Andrey Tarasevich wrote: >> On 2/24/2017 12:39 PM, Jerry Stuckle wrote: >> >> Huh? Apparently this is hopeless... >> >>> Learn to UNDERSTAND the standard - not just read it. >> >> Troll alert? > > Belated... > Yes, there are several trolls here who don't understand the standard. No wonder the really knowledgeable C programmers formed their own group. No arguments there as to what the standard says - because they understand the standard. They don't just read it. Too many times I've seen arguments in this newsgroup about the standard. It is obvious most people here have no real understanding - they just read it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 20:19 -0500 |
| Message-ID | <o8qluc$9om$1@jstuckle.eternal-september.org> |
| In reply to | #104657 |
On 2/24/2017 6:03 PM, Andrey Tarasevich wrote: > On 2/24/2017 12:39 PM, Jerry Stuckle wrote: >>> >>> C is not defined in terms of precedence rules or associativity rules. >>> It does >>> have a grammar, many parts of which lend themselves to being >>> summarized by >>> precedence and associativity, but other parts do not. In particular, a >>> precedence table for C would necessarily place the comma operator as >>> having the >>> lowest possible precedence. That explains perfectly well why >>> a,b?c:d,e must be >>> parsed as a,(b?c:d),e, but it does not explain why a?b,c:d must be >>> parsed as >>> a?(b,c):d, rather than (a?b),(c:d), which would be a syntax error. >>> The grammar >>> rules, on the other hand, make it perfectly clear: the middle operand is >>> specified as being an "expression", referring to the grammar rule in >>> (6.5.15p1). >>> >> >> So from what you're saying, the C compiler developers can evaluate >> multiple operators in any order. That's what you would have with no >> precedence or associativity rules. > > False. > > Firstly, even if we assume that "precedence or associativity rules" > exist in C, it still would not help with order of evaluation. Precedence > or associativity rules have nothing to do with order of evaluation. > They have EVERYTHING to do with the evaluation order of operators. > Secondly, C has no "precedence or associativity rules" per se. The > grammar includes a number of cyclical (i.e. non-transitive) > substructures, which makes it impossible to linearize it into > "precedence or associativity rules". Instead C has sequencing rules that > impose some partial temporal relationships between subexpressions, i.e. > some partial order of evaluation. > Incorrect. They were first laid out in K&R. >>> order of evaluation. "The grouping of operators and operands is >>> indicated by >>> the syntax. Except as specified later, side effects and value >>> computations of >>> subexpressions are unsequenced." (6.5p3). >> >> Which is precedence, is it not? > > Yes, it is precedence. Note that it describes the _grouping_ between > operators and their operands. It does not even attempt to touch the > subject of the "order of evaluation", which is what is explicitly stated > in the above quote from the standard. > Again, incorrect. 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. Start with K&R - the rules are clearly defined there. >>> The semantics of conditional expressions does specify that "sizeof x" >>> gets evaluated before "B" or "C", with a sequence point between them >>> (6.5.15p4) - but the grammar has nothing to say about that issue. >>> >>> If the full expression had been "sizeof x + B + C", then evaluation >>> of "sizeof x" and "B" would both be sequenced before evaluation of >>> their sum, but the two expressions would be unsequenced relative to >>> each other. The evaluation of C and the evaluation of the first sum, >>> would both be sequenced before evaluation of the final sum. However, >>> evaluation of "C" would be unsequenced relative to any of the other >>> sub-expressions. >> >> Not necessarily, according to your statement that C has no precedence or >> associativity rules. > > Huh? Apparently this is hopeless... > That's what you stated earlier. >> Learn to UNDERSTAND the standard - not just read it. > > Troll alert? > So now you're saying you're a troll? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-19 08:42 -0800 |
| Message-ID | <a55fd6d1-dd50-4989-bb3f-e1e4136a309d@googlegroups.com> |
| In reply to | #104190 |
On Sunday, February 19, 2017 at 9:06:26 AM UTC-5, Jerry Stuckle wrote:
> On 2/19/2017 4:06 AM, Ike Naar wrote:
> > On 2017-02-18, BartC <bc@freeuk.com> wrote:
> >> sizeof x?B:C B,C both converted to pointers
> >
> > The sizeof operator takes a unary-expression as its operand, so
> > the expression above is interpreted as:
> >
> > (sizeof x) ? B : C
> >
> > Is that what you intended, or did you mean
> >
> > sizeof (x ? B : C)
> >
> > ?
> >
>
> You are correct, but not for the reason you stated. x ? B : C returns a
> single value, ...
Returning a single value isn't the relevant criterion - that would correspond
roughly to what the standard refers to as a value of scalar type. The standard
defines a unary-expression as follows: Without the parenthesis, the largest
portion of x ? B : C that can be parsed as a unary expression is "x", so I was
correct when he claimed that
unary-expression:
postfix-expression
++ unary-expression
-- unary-expression
unary-operator cast-expression
sizeof unary-expression
sizeof ( type-name )
_Alignof ( type-name )
unary-operator: one of
& * + - ~ !
The expression x?B:C cannot be parsed as a unary-expression. The longest
portion of that expression which can be so parsed is "x", which qualifies as a
primary-expression, and therefore as a postfix-expression and a unary
expression. Therefore, sizeof x?B:C is, as Ike said, parsed as (sizeof x)?B:C.
> ... so sizeof (x ? B : C) is valid.
That's true - because the parentheses convert the entire enclosed expression
into a primary-expression, and therefore a postfix-expression and a unary
expression. Which is why Ike Naar suggested adding them.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-19 08:58 -0800 |
| Message-ID | <1446ce43-d7d1-44b2-9429-62c77acc6526@googlegroups.com> |
| In reply to | #104205 |
On Sunday, February 19, 2017 at 11:42:19 AM UTC-5, james...@verizon.net wrote: ... > Returning a single value isn't the relevant criterion - that would correspond > roughly to what the standard refers to as a value of scalar type. The standard > defines a unary-expression as follows: Without the parenthesis, the largest > portion of x ? B : C that can be parsed as a unary expression is "x", so I was > correct when he claimed that My apologies: everything in that paragraph after the first semicolon was a typo - it should not have been in that location, and I'm not sure how it got there.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-23 16:45 -0500 |
| Message-ID | <o8nl1d$v9$3@jstuckle.eternal-september.org> |
| In reply to | #104205 |
On 2/19/2017 11:42 AM, jameskuyper@verizon.net wrote: > On Sunday, February 19, 2017 at 9:06:26 AM UTC-5, Jerry Stuckle wrote: >> On 2/19/2017 4:06 AM, Ike Naar wrote: >>> On 2017-02-18, BartC <bc@freeuk.com> wrote: >>>> sizeof x?B:C B,C both converted to pointers >>> >>> The sizeof operator takes a unary-expression as its operand, so >>> the expression above is interpreted as: >>> >>> (sizeof x) ? B : C >>> >>> Is that what you intended, or did you mean >>> >>> sizeof (x ? B : C) >>> >>> ? >>> >> >> You are correct, but not for the reason you stated. x ? B : C returns a >> single value, ... > > Returning a single value isn't the relevant criterion - that would correspond > roughly to what the standard refers to as a value of scalar type. The standard > defines a unary-expression as follows: Without the parenthesis, the largest > portion of x ? B : C that can be parsed as a unary expression is "x", so I was > correct when he claimed that > > > unary-expression: > postfix-expression > ++ unary-expression > -- unary-expression > unary-operator cast-expression > sizeof unary-expression > sizeof ( type-name ) > _Alignof ( type-name ) > > unary-operator: one of > & * + - ~ ! > > The expression x?B:C cannot be parsed as a unary-expression. The longest > portion of that expression which can be so parsed is "x", which qualifies as a > primary-expression, and therefore as a postfix-expression and a unary > expression. Therefore, sizeof x?B:C is, as Ike said, parsed as (sizeof x)?B:C. > >> ... so sizeof (x ? B : C) is valid. > > That's true - because the parentheses convert the entire enclosed expression > into a primary-expression, and therefore a postfix-expression and a unary > expression. Which is why Ike Naar suggested adding them. > Isn't that what I said - only in something more easily understood? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 11:43 -0800 |
| Message-ID | <6321a007-667e-4cff-8f76-1e8f05bafaf5@googlegroups.com> |
| In reply to | #104539 |
On Thursday, February 23, 2017 at 4:45:10 PM UTC-5, Jerry Stuckle wrote: > On 2/19/2017 11:42 AM, jameskuyper@verizon.net wrote: > > On Sunday, February 19, 2017 at 9:06:26 AM UTC-5, Jerry Stuckle wrote: > >> On 2/19/2017 4:06 AM, Ike Naar wrote: > >>> On 2017-02-18, BartC <bc@freeuk.com> wrote: > >>>> sizeof x?B:C B,C both converted to pointers > >>> > >>> The sizeof operator takes a unary-expression as its operand, so > >>> the expression above is interpreted as: > >>> > >>> (sizeof x) ? B : C > >>> > >>> Is that what you intended, or did you mean > >>> > >>> sizeof (x ? B : C) > >>> > >>> ? > >>> > >> > >> You are correct, but not for the reason you stated. x ? B : C returns a > >> single value, ... > > > > Returning a single value isn't the relevant criterion - that would correspond > > roughly to what the standard refers to as a value of scalar type. The standard > > defines a unary-expression as follows: Without the parenthesis, the largest > > portion of x ? B : C that can be parsed as a unary expression is "x", so I was > > correct when he claimed that > > > > > > unary-expression: > > postfix-expression > > ++ unary-expression > > -- unary-expression > > unary-operator cast-expression > > sizeof unary-expression > > sizeof ( type-name ) > > _Alignof ( type-name ) > > > > unary-operator: one of > > & * + - ~ ! > > > > The expression x?B:C cannot be parsed as a unary-expression. The longest > > portion of that expression which can be so parsed is "x", which qualifies as a > > primary-expression, and therefore as a postfix-expression and a unary > > expression. Therefore, sizeof x?B:C is, as Ike said, parsed as (sizeof x)?B:C. > > > >> ... so sizeof (x ? B : C) is valid. > > > > That's true - because the parentheses convert the entire enclosed expression > > into a primary-expression, and therefore a postfix-expression and a unary > > expression. Which is why Ike Naar suggested adding them. > > > > Isn't that what I said - only in something more easily understood? 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. The result of a C expression is always a single value. That value could be a struct value, which could have two or more members with their own individual values. It could also be a complex value, which has both real and imaginary components. Those are the only two types of things that a C expression could return that I could imagine anyone thinking are not "single values", even though they actually are. However, that distinction has nothing to do with this issue. sizeof x ? B : C parses the same way even if x has a complex type. It also parses the same way even if B and C both have struct types, or if B and C both have arithmetic type, and at least one of them is complex. 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.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 15:42 -0500 |
| Message-ID | <o8q5na$ksp$2@jstuckle.eternal-september.org> |
| In reply to | #104626 |
On 2/24/2017 2:43 PM, jameskuyper@verizon.net wrote: > On Thursday, February 23, 2017 at 4:45:10 PM UTC-5, Jerry Stuckle wrote: >> On 2/19/2017 11:42 AM, jameskuyper@verizon.net wrote: >>> On Sunday, February 19, 2017 at 9:06:26 AM UTC-5, Jerry Stuckle wrote: >>>> On 2/19/2017 4:06 AM, Ike Naar wrote: >>>>> On 2017-02-18, BartC <bc@freeuk.com> wrote: >>>>>> sizeof x?B:C B,C both converted to pointers >>>>> >>>>> The sizeof operator takes a unary-expression as its operand, so >>>>> the expression above is interpreted as: >>>>> >>>>> (sizeof x) ? B : C >>>>> >>>>> Is that what you intended, or did you mean >>>>> >>>>> sizeof (x ? B : C) >>>>> >>>>> ? >>>>> >>>> >>>> You are correct, but not for the reason you stated. x ? B : C returns a >>>> single value, ... >>> >>> Returning a single value isn't the relevant criterion - that would correspond >>> roughly to what the standard refers to as a value of scalar type. The standard >>> defines a unary-expression as follows: Without the parenthesis, the largest >>> portion of x ? B : C that can be parsed as a unary expression is "x", so I was >>> correct when he claimed that >>> >>> >>> unary-expression: >>> postfix-expression >>> ++ unary-expression >>> -- unary-expression >>> unary-operator cast-expression >>> sizeof unary-expression >>> sizeof ( type-name ) >>> _Alignof ( type-name ) >>> >>> unary-operator: one of >>> & * + - ~ ! >>> >>> The expression x?B:C cannot be parsed as a unary-expression. The longest >>> portion of that expression which can be so parsed is "x", which qualifies as a >>> primary-expression, and therefore as a postfix-expression and a unary >>> expression. Therefore, sizeof x?B:C is, as Ike said, parsed as (sizeof x)?B:C. >>> >>>> ... so sizeof (x ? B : C) is valid. >>> >>> That's true - because the parentheses convert the entire enclosed expression >>> into a primary-expression, and therefore a postfix-expression and a unary >>> expression. Which is why Ike Naar suggested adding them. >>> >> >> Isn't that what I said - only in something more easily understood? > > 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. > The result of a C expression is always a single value. That value could be a > struct value, which could have two or more members with their own individual > values. It could also be a complex value, which has both real and imaginary > components. Those are the only two types of things that a C expression could > return that I could imagine anyone thinking are not "single values", even > though they actually are. However, that distinction has nothing to do with this > issue. sizeof x ? B : C parses the same way even if x has a complex type. It > also parses the same way even if B and C both have struct types, or if B and C > both have arithmetic type, and at least one of them is complex. > > 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 does result in a single value - either B or C, depending on the value of x. However, sizeof takes has higher precedence, so the sizeof x is evaluated first. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 19 of 27 — ← Prev page 1 … 17 18 [19] 20 21 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web