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 13 of 27 — ← Prev page 1 … 11 12 [13] 14 15 … 27 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-23 16:41 -0500 |
| Message-ID | <o8nkr5$v9$1@jstuckle.eternal-september.org> |
| In reply to | #104212 |
On 2/19/2017 12:45 PM, Richard Heathfield wrote:
> On 19/02/17 16:42, Jerry Stuckle wrote:
>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> 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, so sizeof (x ? B : C) is valid.
>>>>
>>>> However, unary operators such as sizeof have a higher precedence
>>>> than the ternary operator, so sizeof is evaluated before ?:.
>>>
>>> Ike Naar is correct (the hyphen is a clue). C's expressions are
>>> defined in terms of a grammar and, as stated,
>>>
>>> unary-expression: postfix-expression ++ unary-expression --
>>> unary-expression unary-operator cast-expression sizeof
>>> unary-expression sizeof ( type-name ) _Alignof ( type-name )
>>>
>>> You can, of course, re-phrase the grammar in terms of precedence
>>> and associative, but that does not mean that the original
>>> explanation was wrong.
>>>
>>> (There's a small error in your explanation in that you conflate
>>> higher precedence with evaluation order.)
>>>
>>
>> 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.
>
> You are making the same mistake again. Precedence determines which
> operators operate on which operands. Evaluation order in C is, for the
> most part, unspecified. The only guarantee you get about evaluation
> order is that all evaluations after a given sequence point will be
> complete (or, at least, as complete as necessary) by the next sequence
> point.
>
I am talking about operations - not operands.
> Take, for example, the following code:
>
> #include <stdio.h>
>
> int calc_A(void)
> {
> printf("A\n");
> return 1;
> }
>
> int calc_B(void)
> {
> printf("B\n");
> return 2;
> }
>
> int calc_C(void)
> {
> printf("C\n");
> return 3;
> }
>
> int main(void)
> {
> int x = calc_A() + calc_B() * calc_C();
> printf("%d\n", x);
> return 0;
> }
>
> Now, *precedence* requires that the result of calc_B() be multiplied by
> the result of calc_C(), and the product should then be added to the
> result of calc_A() --- thus 2 * 3 = 6, + 1 = 7. So main() *must* print 7
> --- there is no choice about that.
>
Once again you are confusing operator evaluation with operand evaluation.
> But, if you were correct to associate precedence with evaluation order,
> we would expect to see one of the following outputs:
>
> B
> C
> A
> 7
>
> or possibly
>
> C
> B
> A
> 7
>
> And yet, when I run this on my own system, I get:
>
> A
> B
> C
> 7
>
> This shows that calc_A() is being evaluated *first*.
>
Which is very possible. C does not require operands be evaluated in any
specific order.
> I deduce that one of two conclusions pertains:
>
> a) gcc is non-conforming in this regard (and gcc is such a widely-used
> compiler that it would mean it would not be safe in practice to rely on
> this 'rule' of C that precedence determines evaluation order; OR
>
> b) there is no such rule.
>
> The Standard's description of evaluation order has been massively
> complicated by the inclusion of threads. It used to say that "the order
> of evaluation of subexpressions and the order in which side effects take
> place are both unspecified", which is certainly enough to prove my point
> for C90. But even in C11 we find in 5.1.2.3:
>
Nope. Evaluation order of operators has not changed.
> /Sequenced before/ is an asymmetric, transitive, pair-wise relation
> between evaluations executed by a single thread, which induces a partial
> order among those evaluations. Given any two evaluations A and B, if A
> is sequenced before B, then the execution of A shall precede the
> execution of B. (Conversely, if A is sequenced before B, then B is
> /sequenced after/ A.) If A is not sequenced before or after B, then A
> and B are /unsequenced/. Evaluations A and B are /indeterminately
> sequenced/ when A is sequenced either before or after B, but it is
> unspecified which. 13) The presence of a /sequence point/ between the
> evaluation of expressions A and B implies that every value computation
> and side effect associated with A is sequenced before every value
> computation and side effect associated with B.
>
> (I have added /italics/ to correspond with the italics in the Standard,
> which indicate that a term is being defined.)
>
And evaluation order of operands is still undefined.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-24 10:04 +0000 |
| Message-ID | <o8p0c1$e7m$1@dont-email.me> |
| In reply to | #104537 |
On 23/02/17 21:41, Jerry Stuckle wrote: > On 2/19/2017 12:45 PM, Richard Heathfield wrote: >> On 19/02/17 16:42, Jerry Stuckle wrote: >>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote: <snip> >>>> (There's a small error in your explanation in that you conflate >>>> higher precedence with evaluation order.) >>>> >>> >>> 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. >> >> You are making the same mistake again. Precedence determines which >> operators operate on which operands. Evaluation order in C is, for the >> most part, unspecified. The only guarantee you get about evaluation >> order is that all evaluations after a given sequence point will be >> complete (or, at least, as complete as necessary) by the next sequence >> point. >> > > I am talking about operations - not operands. Precedence and associativity define which operations must be performed, but neither precedence nor associativity dictates evaluation order either of operands nor of operations. For example, a compiler might decide that it's cheaper/faster to do (a+b)*c as a*c + b*c (if it can be sure that the result would be the same), in which case the (a+b) itself is never actually evaluated at all. The compiler is allowed to do this even if the operands are functions (because evaluation order is unspecified). <snip> > And evaluation order of operands is still undefined. I think you mean "unspecified". -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 08:43 -0500 |
| Message-ID | <o8pd6m$opc$1@jstuckle.eternal-september.org> |
| In reply to | #104573 |
On 2/24/2017 5:04 AM, Richard Heathfield wrote: > On 23/02/17 21:41, Jerry Stuckle wrote: >> On 2/19/2017 12:45 PM, Richard Heathfield wrote: >>> On 19/02/17 16:42, Jerry Stuckle wrote: >>>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote: > > <snip> > >>>>> (There's a small error in your explanation in that you conflate >>>>> higher precedence with evaluation order.) >>>>> >>>> >>>> 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. >>> >>> You are making the same mistake again. Precedence determines which >>> operators operate on which operands. Evaluation order in C is, for the >>> most part, unspecified. The only guarantee you get about evaluation >>> order is that all evaluations after a given sequence point will be >>> complete (or, at least, as complete as necessary) by the next sequence >>> point. >>> >> >> I am talking about operations - not operands. > > Precedence and associativity define which operations must be performed, > but neither precedence nor associativity dictates evaluation order > either of operands nor of operations. > That's exactly what I said. > For example, a compiler might decide that it's cheaper/faster to do > (a+b)*c as a*c + b*c (if it can be sure that the result would be the > same), in which case the (a+b) itself is never actually evaluated at > all. The compiler is allowed to do this even if the operands are > functions (because evaluation order is unspecified). > IFF the result is the same. > <snip> > >> And evaluation order of operands is still undefined. > > I think you mean "unspecified". > No, I mean undefined. But the discussion was about sizeof x?B:C; My statement stands. Precedence rules here. The sizeof has higher priority than ?:. So sizeof will be evaluated before ?:. And whether the size of x is non-zero or zero will determine whether B or C is returned from the expression. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-24 14:53 +0000 |
| Message-ID | <o8phaa$8f1$1@dont-email.me> |
| In reply to | #104577 |
On 24/02/17 13:43, Jerry Stuckle wrote:
> On 2/24/2017 5:04 AM, Richard Heathfield wrote:
>> On 23/02/17 21:41, Jerry Stuckle wrote:
>>> On 2/19/2017 12:45 PM, Richard Heathfield wrote:
>>>> On 19/02/17 16:42, Jerry Stuckle wrote:
>>>>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote:
>>
>> <snip>
>>
>>>>>> (There's a small error in your explanation in that you conflate
>>>>>> higher precedence with evaluation order.)
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> You are making the same mistake again. Precedence determines which
>>>> operators operate on which operands. Evaluation order in C is, for the
>>>> most part, unspecified. The only guarantee you get about evaluation
>>>> order is that all evaluations after a given sequence point will be
>>>> complete (or, at least, as complete as necessary) by the next sequence
>>>> point.
>>>>
>>>
>>> I am talking about operations - not operands.
>>
>> Precedence and associativity define which operations must be performed,
>> but neither precedence nor associativity dictates evaluation order
>> either of operands nor of operations.
>>
>
> That's exactly what I said.
No. It may or may not have been what you /meant/, but what you /said/
was: "unary operators such as sizeof have a higher precedence than
the ternary operator, so sizeof is evaluated before ?:" and "Precedence
rules require the unary operator be evaluated before the ternary operator."
They don't. Precedence doesn't actually exist as a concept within the C
definition, but it is nevertheless a handy and, as far as I'm aware,
wholly accurate rule of thumb that we can follow when writing code. But
we confuse precedence and evaluation order at our peril.
In the current case, sizeof x ? B : C; the operand of sizeof is not
evaluated at all (if x had had the syntax of a function call, for
example, that function wouldn't have been called).
The grammar for which precedence is a handy shortcut binds x to sizeof.
So it is /as if/ (sizeof x) ? B : C had been written.
The result of the sizeof is of course required before the conditional
operator can know which of B and C to evaluate (if they were functions
with side effects, which function to call). In fact, the ? can be
thought of as representing a sequence point, because ?: can't decide
between whether to evaluate B or C (for it must evaluate one and only
one of them) until it knows what (sizeof x) is.
But this is nothing to do with precedence. Precedence dictates only
which operands bind to which operators. Thus, precedence tells us that
the syntax tree is constructed as follows:
+--------?:---------+
| | |
sizeof B C
|
x
In this particular case, of course, sizeof doesn't evaluate its operand
and so this construct has /nothing to say/ on whether precedence governs
evaluation order. Indeed, I have already presented code which shows that
it does not.
>> For example, a compiler might decide that it's cheaper/faster to do
>> (a+b)*c as a*c + b*c (if it can be sure that the result would be the
>> same), in which case the (a+b) itself is never actually evaluated at
>> all. The compiler is allowed to do this even if the operands are
>> functions (because evaluation order is unspecified).
>
> IFF the result is the same.
Indeed.
>> <snip>
>>
>>> And evaluation order of operands is still undefined.
>>
>> I think you mean "unspecified".
>>
>
> No, I mean undefined.
Then you are mistaken again.
> But the discussion was about
>
> sizeof x?B:C;
>
> My statement stands. Precedence rules here. The sizeof has higher
> priority than ?:. So sizeof will be evaluated before ?:.
No, the grammar rules here. Precedence tells us that it is x, not x?B:C,
that is an operand of sizeof. And that's /all/ it tells us. Yes, sizeof
x has to be evaluated before ?: can be evaluated, but *all* operators
need to evaluate all their operands (except, perhaps ironically, in the
cases of sizeof and ?:) before they can yield a result. Precedence does
not determine the order in which this is done. It only determines which
results of evaluation belong to which operators.
> And whether
> the size of x is non-zero or zero will determine whether B or C is
> returned from the expression.
yielded, not returned.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 12:57 -0500 |
| Message-ID | <o8ps2n$iau$1@jstuckle.eternal-september.org> |
| In reply to | #104582 |
On 2/24/2017 9:53 AM, Richard Heathfield wrote: > On 24/02/17 13:43, Jerry Stuckle wrote: >> On 2/24/2017 5:04 AM, Richard Heathfield wrote: >>> On 23/02/17 21:41, Jerry Stuckle wrote: >>>> On 2/19/2017 12:45 PM, Richard Heathfield wrote: >>>>> On 19/02/17 16:42, Jerry Stuckle wrote: >>>>>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote: >>> >>> <snip> >>> >>>>>>> (There's a small error in your explanation in that you conflate >>>>>>> higher precedence with evaluation order.) >>>>>>> >>>>>> >>>>>> 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. >>>>> >>>>> You are making the same mistake again. Precedence determines which >>>>> operators operate on which operands. Evaluation order in C is, for the >>>>> most part, unspecified. The only guarantee you get about evaluation >>>>> order is that all evaluations after a given sequence point will be >>>>> complete (or, at least, as complete as necessary) by the next sequence >>>>> point. >>>>> >>>> >>>> I am talking about operations - not operands. >>> >>> Precedence and associativity define which operations must be performed, >>> but neither precedence nor associativity dictates evaluation order >>> either of operands nor of operations. >>> >> >> That's exactly what I said. > > No. It may or may not have been what you /meant/, but what you /said/ > was: "unary operators such as sizeof have a higher precedence than > the ternary operator, so sizeof is evaluated before ?:" and "Precedence > rules require the unary operator be evaluated before the ternary operator." > > They don't. Precedence doesn't actually exist as a concept within the C > definition, but it is nevertheless a handy and, as far as I'm aware, > wholly accurate rule of thumb that we can follow when writing code. But > we confuse precedence and evaluation order at our peril. > Wrong again. Precedence is highly structured within C. > In the current case, sizeof x ? B : C; the operand of sizeof is not > evaluated at all (if x had had the syntax of a function call, for > example, that function wouldn't have been called). > I didn't say ANYTHING about the operand. That is YOUR STATEMENT. > The grammar for which precedence is a handy shortcut binds x to sizeof. > So it is /as if/ (sizeof x) ? B : C had been written. > Which is exactly what I am saying. > The result of the sizeof is of course required before the conditional > operator can know which of B and C to evaluate (if they were functions > with side effects, which function to call). In fact, the ? can be > thought of as representing a sequence point, because ?: can't decide > between whether to evaluate B or C (for it must evaluate one and only > one of them) until it knows what (sizeof x) is. > <snip rest of bullshit> Your statement that C does not have precedence rules shows you're not worth even talking to any further. Go away and come back when you learn basic programming. You're not worth my wasting any more of my time. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-24 20:04 +0000 |
| Message-ID | <o8q3he$dll$1@dont-email.me> |
| In reply to | #104611 |
On 24/02/17 17:57, Jerry Stuckle wrote: > On 2/24/2017 9:53 AM, Richard Heathfield wrote: >> On 24/02/17 13:43, Jerry Stuckle wrote: >>> On 2/24/2017 5:04 AM, Richard Heathfield wrote: >>>> On 23/02/17 21:41, Jerry Stuckle wrote: >>>>> On 2/19/2017 12:45 PM, Richard Heathfield wrote: >>>>>> On 19/02/17 16:42, Jerry Stuckle wrote: >>>>>>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote: >>>> >>>> <snip> >>>> >>>>>>>> (There's a small error in your explanation in that you conflate >>>>>>>> higher precedence with evaluation order.) >>>>>>>> >>>>>>> >>>>>>> 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. >>>>>> >>>>>> You are making the same mistake again. Precedence determines which >>>>>> operators operate on which operands. Evaluation order in C is, for the >>>>>> most part, unspecified. The only guarantee you get about evaluation >>>>>> order is that all evaluations after a given sequence point will be >>>>>> complete (or, at least, as complete as necessary) by the next sequence >>>>>> point. >>>>>> >>>>> >>>>> I am talking about operations - not operands. >>>> >>>> Precedence and associativity define which operations must be performed, >>>> but neither precedence nor associativity dictates evaluation order >>>> either of operands nor of operations. >>>> >>> >>> That's exactly what I said. >> >> No. It may or may not have been what you /meant/, but what you /said/ >> was: "unary operators such as sizeof have a higher precedence than >> the ternary operator, so sizeof is evaluated before ?:" and "Precedence >> rules require the unary operator be evaluated before the ternary operator." >> >> They don't. Precedence doesn't actually exist as a concept within the C >> definition, but it is nevertheless a handy and, as far as I'm aware, >> wholly accurate rule of thumb that we can follow when writing code. But >> we confuse precedence and evaluation order at our peril. >> > > Wrong again. Precedence is highly structured within C. Read the Standard. In normative text, the word "precedence" occurs in *only* these places: 5.1.1.2 Translation phases 1 The precedence among the syntax rules of translation is specified by the following phases. And here, it's talking about the order of translation phases - not what we're after. 6.5.9(3) Equality operators The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence. This /is/ normative and /is/ about operators, but it is the *only* relevant use of the word "precedence" in normative text, and its meaning is not defined anywhere within the Standard itself. In practice, precedence is a handy way to think about operators, which is why it's so pervasive, but the Standard all but ignores it in favour of other ways of expressing the same basic idea. >> In the current case, sizeof x ? B : C; the operand of sizeof is not >> evaluated at all (if x had had the syntax of a function call, for >> example, that function wouldn't have been called). >> > > I didn't say ANYTHING about the operand. That is YOUR STATEMENT. That's right. If precedence has any meaning at all in C (and I'm not saying that it doesn't), it is to do with how operands bind to operators. It does not define an order of evaluation either of operands or indeed operators. > >> The grammar for which precedence is a handy shortcut binds x to sizeof. >> So it is /as if/ (sizeof x) ? B : C had been written. >> > > Which is exactly what I am saying. I'm not disagreeing with your conclusion. I'm disagreeing with how you got there. In fact, as you yourself said to Ike Naar, "You are correct, but not for the reason you stated." >> The result of the sizeof is of course required before the conditional >> operator can know which of B and C to evaluate (if they were functions >> with side effects, which function to call). In fact, the ? can be >> thought of as representing a sequence point, because ?: can't decide >> between whether to evaluate B or C (for it must evaluate one and only >> one of them) until it knows what (sizeof x) is. >> > > <snip rest of bullshit> > > Your statement that C does not have precedence rules shows you're not > worth even talking to any further. Go away and come back when you learn > basic programming. You're not worth my wasting any more of my time. Whatever. You have offered no actual evidence in support of your claim, and I can find *no text whatsoever* to support your view that precedence determines the order in which operations are carried out. Feel free to say again that I'm wrong if you like. I've given you the chance to be educated, but I can't force you to learn. Unless you have a concrete argument to present that doesn't consist of mere empty insults, I'm out of this discussion. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 15:35 -0500 |
| Message-ID | <o8q5ae$jil$1@jstuckle.eternal-september.org> |
| In reply to | #104630 |
On 2/24/2017 3:04 PM, Richard Heathfield wrote: > On 24/02/17 17:57, Jerry Stuckle wrote: >> On 2/24/2017 9:53 AM, Richard Heathfield wrote: >>> On 24/02/17 13:43, Jerry Stuckle wrote: >>>> On 2/24/2017 5:04 AM, Richard Heathfield wrote: >>>>> On 23/02/17 21:41, Jerry Stuckle wrote: >>>>>> On 2/19/2017 12:45 PM, Richard Heathfield wrote: >>>>>>> On 19/02/17 16:42, Jerry Stuckle wrote: >>>>>>>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote: >>>>> >>>>> <snip> >>>>> >>>>>>>>> (There's a small error in your explanation in that you conflate >>>>>>>>> higher precedence with evaluation order.) >>>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> You are making the same mistake again. Precedence determines which >>>>>>> operators operate on which operands. Evaluation order in C is, >>>>>>> for the >>>>>>> most part, unspecified. The only guarantee you get about evaluation >>>>>>> order is that all evaluations after a given sequence point will be >>>>>>> complete (or, at least, as complete as necessary) by the next >>>>>>> sequence >>>>>>> point. >>>>>>> >>>>>> >>>>>> I am talking about operations - not operands. >>>>> >>>>> Precedence and associativity define which operations must be >>>>> performed, >>>>> but neither precedence nor associativity dictates evaluation order >>>>> either of operands nor of operations. >>>>> >>>> >>>> That's exactly what I said. >>> >>> No. It may or may not have been what you /meant/, but what you /said/ >>> was: "unary operators such as sizeof have a higher precedence than >>> the ternary operator, so sizeof is evaluated before ?:" and "Precedence >>> rules require the unary operator be evaluated before the ternary >>> operator." >>> >>> They don't. Precedence doesn't actually exist as a concept within the C >>> definition, but it is nevertheless a handy and, as far as I'm aware, >>> wholly accurate rule of thumb that we can follow when writing code. But >>> we confuse precedence and evaluation order at our peril. >>> >> >> Wrong again. Precedence is highly structured within C. > > Read the Standard. In normative text, the word "precedence" occurs in > *only* these places: > > 5.1.1.2 Translation phases > 1 > The precedence among the syntax rules of translation is specified by the > following phases. > > And here, it's talking about the order of translation phases - not what > we're after. > > 6.5.9(3) Equality operators > > The == (equal to) and != (not equal to) operators are analogous to the > relational operators except for their lower precedence. > > This /is/ normative and /is/ about operators, but it is the *only* > relevant use of the word "precedence" in normative text, and its meaning > is not defined anywhere within the Standard itself. > > In practice, precedence is a handy way to think about operators, which > is why it's so pervasive, but the Standard all but ignores it in favour > of other ways of expressing the same basic idea. > >>> In the current case, sizeof x ? B : C; the operand of sizeof is not >>> evaluated at all (if x had had the syntax of a function call, for >>> example, that function wouldn't have been called). >>> >> >> I didn't say ANYTHING about the operand. That is YOUR STATEMENT. > > That's right. If precedence has any meaning at all in C (and I'm not > saying that it doesn't), it is to do with how operands bind to > operators. It does not define an order of evaluation either of operands > or indeed operators. > >> >>> The grammar for which precedence is a handy shortcut binds x to sizeof. >>> So it is /as if/ (sizeof x) ? B : C had been written. >>> >> >> Which is exactly what I am saying. > > I'm not disagreeing with your conclusion. I'm disagreeing with how you > got there. In fact, as you yourself said to Ike Naar, "You are correct, > but not for the reason you stated." > >>> The result of the sizeof is of course required before the conditional >>> operator can know which of B and C to evaluate (if they were functions >>> with side effects, which function to call). In fact, the ? can be >>> thought of as representing a sequence point, because ?: can't decide >>> between whether to evaluate B or C (for it must evaluate one and only >>> one of them) until it knows what (sizeof x) is. >>> >> >> <snip rest of bullshit> >> >> Your statement that C does not have precedence rules shows you're not >> worth even talking to any further. Go away and come back when you learn >> basic programming. You're not worth my wasting any more of my time. > > Whatever. You have offered no actual evidence in support of your claim, > and I can find *no text whatsoever* to support your view that precedence > determines the order in which operations are carried out. > > Feel free to say again that I'm wrong if you like. I've given you the > chance to be educated, but I can't force you to learn. Unless you have a > concrete argument to present that doesn't consist of mere empty insults, > I'm out of this discussion. > That's the difference. You read the standard. Most people UNDERSTAND the standard. A huge difference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 12:37 -0800 |
| Message-ID | <d7d05d59-f1d0-4d55-993b-8f0552f29e0a@googlegroups.com> |
| In reply to | #104611 |
On Friday, February 24, 2017 at 12:57:36 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 9:53 AM, Richard Heathfield wrote: ... > > No. It may or may not have been what you /meant/, but what you /said/ > > was: "unary operators such as sizeof have a higher precedence than > > the ternary operator, so sizeof is evaluated before ?:" and "Precedence > > rules require the unary operator be evaluated before the ternary operator." > > > > They don't. Precedence doesn't actually exist as a concept within the C > > definition, but it is nevertheless a handy and, as far as I'm aware, > > wholly accurate rule of thumb that we can follow when writing code. But > > we confuse precedence and evaluation order at our peril. ... > Your statement that C does not have precedence rules shows you're not > worth even talking to any further. I realize that my belief that the C standard does not contain any precedence rules for operators means that you also do not consider me worth talking to. However, I reached that conclusion by reading the entire text of the C standard and not finding any operator precedence rules. It has grammar rules that can be (mostly, but not completely) summarized by using operator precedence rules - but it has no operator precedence rules as such. If I'm mistaken about that, you should be able to show me where the operator precedence rules are that I missed. I won't ask you to provide a complete list of the locations of those rules - the location of even a single operator precedence rule would be sufficient to make your point. Of course, you won't be able to give me such a location, because there isn't one - but I'm sure that if you even bother to respond, you'll find some other justification for refusing to answer what should be a trivial request, if you were right.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 16:18 -0500 |
| Message-ID | <o8q7s3$ru2$1@jstuckle.eternal-september.org> |
| In reply to | #104636 |
On 2/24/2017 3:37 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 12:57:36 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 9:53 AM, Richard Heathfield wrote: > ... >>> No. It may or may not have been what you /meant/, but what you /said/ >>> was: "unary operators such as sizeof have a higher precedence than >>> the ternary operator, so sizeof is evaluated before ?:" and "Precedence >>> rules require the unary operator be evaluated before the ternary operator." >>> >>> They don't. Precedence doesn't actually exist as a concept within the C >>> definition, but it is nevertheless a handy and, as far as I'm aware, >>> wholly accurate rule of thumb that we can follow when writing code. But >>> we confuse precedence and evaluation order at our peril. > ... >> Your statement that C does not have precedence rules shows you're not >> worth even talking to any further. > > I realize that my belief that the C standard does not contain any precedence rules for operators means that you also do not consider me worth talking to. However, I reached that conclusion by reading the entire text of the C standard and not finding any operator precedence rules. It has grammar rules that can be (mostly, but not completely) summarized by using operator precedence rules - but it has no operator precedence rules as such. If I'm mistaken about that, you should be able to show me where the operator precedence rules are that I missed. I won't ask you to provide a complete list of the locations of those rules - the location of even a single operator precedence rule would be sufficient to make your point. > > Of course, you won't be able to give me such a location, because there isn't one - but I'm sure that if you even bother to respond, you'll find some other justification for refusing to answer what should be a trivial request, if you were right. > You read - but you don't UNDERSTAND. The original rules were laid out over 40 years ago in K&R, Page 53. This is exactly why the real C experts left this newsgroup. People argue about the most inane things because they don't try to understand the standard. That and why C is such a bad language. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 15:21 -0800 |
| Message-ID | <ac112ab3-5501-4f1a-bc2b-bbe7c55a1da9@googlegroups.com> |
| In reply to | #104645 |
On Friday, February 24, 2017 at 4:18:53 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 3:37 PM, jameskuyper@verizon.net wrote: ... > > I realize that my belief that the C standard does not contain any > > precedence rules for operators means that you also do not consider me worth > > talking to. However, I reached that conclusion by reading the entire text > > of the C standard and not finding any operator precedence rules. It has > > grammar rules that can be (mostly, but not completely) summarized by using > > operator precedence rules - but it has no operator precedence rules as > > such. If I'm mistaken about that, you should be able to show me where the > > operator precedence rules are that I missed. I won't ask you to provide a > > complete list of the locations of those rules - the location of even a > > single operator precedence rule would be sufficient to make your point. > > > > Of course, you won't be able to give me such a location, because there > > isn't one - but I'm sure that if you even bother to respond, you'll find > > some other justification for refusing to answer what should be a trivial > > request, if you were right. > > You read - but you don't UNDERSTAND. The original rules were laid out > over 40 years ago in K&R, Page 53. K&R 1 was published in 1978, which (barely) fails to qualify as "over 40 years ago". In my copy of that book, page 53 contains section 3.3, describing control flow. The precedence table is on page 49. Are you sure you're not referring to K&R 2, which was published in 1998, less than 20 years ago? I don't have a copy of that edition. I read and understood the precedence table over 40 years ago, in 1979. I'm sure that at that time I did not realize the subtle way in which it failed to correctly summarize the grammar rules in that same book - I didn't find out about that until I started following comp.std.c, about 15 years later. That precedence table has NOT been incorporated into the C standard. K&R 1 contains many uses of variations on the term "precedence" while describing C operators - but none of those uses have ever been incorporated in the C standard, either. The grammar was incorporated into the C standard, with only minor changes in the C90. Precedence rules do summarize some aspects of that grammar. They provide a useful shorthand for understanding the C syntax, so long as their limitations are understood. You don't understand those limitations, I do. They aren't major limitations, but the actual grammar overrules any contrary conclusion you might reach using only precedence and associativity rules. In turn, the actual words of the standard overrule the grammar, in a few special cases where the rules are much easier to describe by means other than grammar. Note, in particular, that even though the title of section 2.12 in K&R 1 is "Precedence and Order of Evaluation", it does not actually say that precedence determines the order of evaluation. Instead it says "C, like most languages, does not specify in what order the operands of an operator are evaluated.", which corresponds pretty closely to what the current standard says in more precise terminology in section 6.5p3.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-24 16:09 -0800 |
| Message-ID | <21253d47-39c1-4d0f-8ce2-b48666293107@googlegroups.com> |
| In reply to | #104660 |
On Friday, February 24, 2017 at 5:21:58 PM UTC-6, james...@verizon.net wrote:
> I read and understood the precedence table over 40 years ago, in 1979. I'm sure
> that at that time I did not realize the subtle way in which it failed to
> correctly summarize the grammar rules in that same book - I didn't find out
> about that until I started following comp.std.c, about 15 years later. That
> precedence table has NOT been incorporated into the C standard. K&R 1 contains
> many uses of variations on the term "precedence" while describing C operators -
> but none of those uses have ever been incorporated in the C standard, either.
> The grammar was incorporated into the C standard, with only minor changes in
> the C90. Precedence rules do summarize some aspects of that grammar. They
> provide a useful shorthand for understanding the C syntax, so long as their
> limitations are understood. You don't understand those limitations, I do. They
> aren't major limitations, but the actual grammar overrules any contrary
> conclusion you might reach using only precedence and associativity rules. In
> turn, the actual words of the standard overrule the grammar, in a few special
> cases where the rules are much easier to describe by means other than grammar.
Do you have any sense as to whether K&R intended the grammar was intended
to serve as a definition for the language in cases like 0x1e+3, or whether
it was intended to serve as a starting point for implementers, recognizing
that some tweaks might be needed to make things work the way they really
should?
I'd be curious whether anyone has ever asked K&R which of two compilers they
would regard as being of higher quality if they were identical in every way
except that, e.g.:
1. The first compiler would silently treat a construct like 0x1e+3 as
a hex number, a plus token, and an integer literal, and had no
option to do otherwise.
2. The second compilers would refuse to compile any code which contained
such a construct, and had no option to do otherwise.
I can imagine them thinking that compilers should be *allowed* to reject such
code; I'd be curious if they would regard a compiler which did reject such
code as being of higher quality than one that accepted it, or if they would
have regarded such a compiler as being of lower, but still acceptable, quality.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 17:45 -0800 |
| Message-ID | <11f6bf13-0d92-4466-8707-92e9a417ad61@googlegroups.com> |
| In reply to | #104662 |
On Friday, February 24, 2017 at 7:09:32 PM UTC-5, supe...@casperkitty.com wrote: > On Friday, February 24, 2017 at 5:21:58 PM UTC-6, james...@verizon.net wrote: ... > > aren't major limitations, but the actual grammar overrules any contrary > > conclusion you might reach using only precedence and associativity rules. In > > turn, the actual words of the standard overrule the grammar, in a few > > special cases where the rules are much easier to describe by means other > > than grammar. > > Do you have any sense as to whether K&R intended the grammar was intended > to serve as a definition for the language in cases like 0x1e+3, or whether > it was intended to serve as a starting point for implementers, recognizing > that some tweaks might be needed to make things work the way they really > should? Section 18 of K&R1: "This summary of C syntax is intended more for aiding comprehension than as an exact statement of the language." The C committee had a mandate to more precisely specify what is and isn't allowed than was the case for K&R1. That's what standardization is all about. > I'd be curious whether anyone has ever asked K&R which of two compilers they > would regard as being of higher quality if they were identical in every way > except that, e.g.: > > 1. The first compiler would silently treat a construct like 0x1e+3 as > a hex number, a plus token, and an integer literal, and had no > option to do otherwise.pp-number A fully conforming implementation of C could almost behave the way you specify. You would have to remove the word "silently", and instead specify that it generates the required diagnostic. It need only generated a single diagnostic, rather than a separate one for each constraint violation. > 2. The second compilers would refuse to compile any code which contained > such a construct, and had no option to do otherwise. Section 18.5 of K&R1 contains only a very simple grammar for preprocessing, and is not described in terms of translation phases. The standard has two separate grammars. One is described in A.3 "Preprocessing directives", and applies during translation phase 4. The other is the A.2 "Phrase structure grammar", which applies during translation phase 8. Both grammars refer to additional grammar rules shared between them, described in A.1. The standard very precisely specifies the translation phases and the connection between the two grammars. By doing so they explained much more precisely many things that were fuzzy in K&R C. The C rationale explains the particular issue you've raised: "The notion of preprocessing numbers was introduced to simplify the description of preprocessing. It provides a means of talking about the tokenization of strings that look like numbers, or initial substrings of numbers, prior to their semantic interpretation. In the interests of keeping the description simple, occasional spurious forms are scanned as preprocessing numbers. For example, 0x123E+1 is a single token under the rules. The C89 Committee felt that it was better to tolerate such anomalies than burden the preprocessor with a more exact, and exacting, lexical specification. It felt that this anomaly was no worse than the principle under which the characters a+++++b are tokenized as a ++ ++ + b (an invalid expression), even though the tokenization a ++ + ++ b would yield a syntactically correct expression. In both cases, exercise of reasonable precaution in coding style avoids surprises." Since K&R never attempted to describe the language as precisely as the C standard does, it's not clear that they even considered the issue of whether such a concept would "simplify the description of preprocessing". > I can imagine them thinking that compilers should be *allowed* to reject such > code; I'd be curious if they would regard a compiler which did reject such > code as being of higher quality than one that accepted it, or if they would > have regarded such a compiler as being of lower, but still acceptable, > quality. You'll have to ask Kernighan (Ritchie is unavailable). I can't answer that question for them. I personally would prefer the second one that only accepts portable constructs, even if the first one was corrected in the manner I indicated, to be fully conforming.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-25 14:44 -0800 |
| Message-ID | <c281e1fb-c6ea-4210-9c1d-21f853cac55b@googlegroups.com> |
| In reply to | #104678 |
On Friday, February 24, 2017 at 7:45:17 PM UTC-6, james...@verizon.net wrote: > The C committee had a mandate to more precisely specify what is and isn't > allowed than was the case for K&R1. That's what standardization is all about. A good standard, especially one developed after the things it's supposed to describe, should in many cases not try to define everything as being either conforming or non-conforming, and expect that every object can be definitively accepted or rejected. It is often much more useful for a standard to assign separate "go" and "no-go" criteria, such that every object meeting the "go" criteria must be accepted, every object meeting the "no-go" criteria must be rejected, and objects meeting neither set of criteria may be arbitrarily accepted or rejected. As a simple real-world example, if one is given the task of sorting metal rods into two piles--one containing rods more than 10.0000cm in length and one containing rods that are not more than 10.0000cm in length, rods that are 10.0001cm or 9.9999cm in length may be impossible to sort without expensive equipment. If the requirement had instead specified that rods less than 9cm must go in one pile, those greater than 11cm must go in the other pile, and rods between those lengths may go in either pile, then the cost of sorting could be greatly reduced. There are many C programs which must be accepted by some implementations and rejected by others on the basis of Implementation-Defined features. I would suggest, therefore, that there is limited value in trying to formulate a set of rules that would unambiguously specify for any program that a particular implementation must accept it or must reject it. Accepting the existence of programs which implementations could accept or not at their leisure would make it possible for implementations to use rules that fit better with their needs and those of their customers.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 20:08 -0500 |
| Message-ID | <o8qla6$7r8$1@jstuckle.eternal-september.org> |
| In reply to | #104660 |
On 2/24/2017 6:21 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 4:18:53 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 3:37 PM, jameskuyper@verizon.net wrote: > ... >>> I realize that my belief that the C standard does not contain any >>> precedence rules for operators means that you also do not consider me worth >>> talking to. However, I reached that conclusion by reading the entire text >>> of the C standard and not finding any operator precedence rules. It has >>> grammar rules that can be (mostly, but not completely) summarized by using >>> operator precedence rules - but it has no operator precedence rules as >>> such. If I'm mistaken about that, you should be able to show me where the >>> operator precedence rules are that I missed. I won't ask you to provide a >>> complete list of the locations of those rules - the location of even a >>> single operator precedence rule would be sufficient to make your point. >>> >>> Of course, you won't be able to give me such a location, because there >>> isn't one - but I'm sure that if you even bother to respond, you'll find >>> some other justification for refusing to answer what should be a trivial >>> request, if you were right. >> >> You read - but you don't UNDERSTAND. The original rules were laid out >> over 40 years ago in K&R, Page 53. > > K&R 1 was published in 1978, which (barely) fails to qualify as "over 40 years > ago". In my copy of that book, page 53 contains section 3.3, describing control > flow. The precedence table is on page 49. Are you sure you're not referring to > K&R 2, which was published in 1998, less than 20 years ago? I don't have a > copy of that edition. > > I read and understood the precedence table over 40 years ago, in 1979. I'm sure > that at that time I did not realize the subtle way in which it failed to > correctly summarize the grammar rules in that same book - I didn't find out > about that until I started following comp.std.c, about 15 years later. That > precedence table has NOT been incorporated into the C standard. K&R 1 contains > many uses of variations on the term "precedence" while describing C operators - > but none of those uses have ever been incorporated in the C standard, either. > The grammar was incorporated into the C standard, with only minor changes in > the C90. Precedence rules do summarize some aspects of that grammar. They > provide a useful shorthand for understanding the C syntax, so long as their > limitations are understood. You don't understand those limitations, I do. They > aren't major limitations, but the actual grammar overrules any contrary > conclusion you might reach using only precedence and associativity rules. In > turn, the actual words of the standard overrule the grammar, in a few special > cases where the rules are much easier to describe by means other than grammar. > > Note, in particular, that even though the title of section 2.12 in K&R 1 is > "Precedence and Order of Evaluation", it does not actually say that precedence > determines the order of evaluation. Instead it says "C, like most languages, > does not specify in what order the operands of an operator are evaluated.", > which corresponds pretty closely to what the current standard says in more > precise terminology in section 6.5p3. > Ok, so I was off a couple of pages. But it did set the order of precedence and associativity. But according to you, order of evaluation of operators is undefined, so compiler manufacturers can use any order they wish. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-25 14:15 +1300 |
| Message-ID | <ehc45hF3cogU1@mid.individual.net> |
| In reply to | #104667 |
On 02/25/17 02:08 PM, Jerry Stuckle wrote: > On 2/24/2017 6:21 PM, jameskuyper@verizon.net wrote: >> >> Note, in particular, that even though the title of section 2.12 in K&R 1 is >> "Precedence and Order of Evaluation", it does not actually say that precedence >> determines the order of evaluation. Instead it says "C, like most languages, >> does not specify in what order the operands of an operator are evaluated.", >> which corresponds pretty closely to what the current standard says in more >> precise terminology in section 6.5p3. >> > > Ok, so I was off a couple of pages. But it did set the order of > precedence and associativity. > > But according to you, order of evaluation of operators is undefined, I guess you failed to read or at least comprehend the note James quoted from that page of K&R? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 21:48 -0500 |
| Message-ID | <o8qr5o$uci$1@jstuckle.eternal-september.org> |
| In reply to | #104670 |
On 2/24/2017 8:15 PM, Ian Collins wrote: > On 02/25/17 02:08 PM, Jerry Stuckle wrote: >> On 2/24/2017 6:21 PM, jameskuyper@verizon.net wrote: >>> >>> Note, in particular, that even though the title of section 2.12 in >>> K&R 1 is >>> "Precedence and Order of Evaluation", it does not actually say that >>> precedence >>> determines the order of evaluation. Instead it says "C, like most >>> languages, >>> does not specify in what order the operands of an operator are >>> evaluated.", >>> which corresponds pretty closely to what the current standard says in >>> more >>> precise terminology in section 6.5p3. >>> >> >> Ok, so I was off a couple of pages. But it did set the order of >> precedence and associativity. >> >> But according to you, order of evaluation of operators is undefined, > > I guess you failed to read or at least comprehend the note James quoted > from that page of K&R? > I read it. But you obviously don't understand the difference between operators and operands. I said NOTHING about the order of evaluation of operands. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-02-25 10:35 +0000 |
| Message-ID | <871sum4kxw.fsf@gmail.com> |
| In reply to | #104670 |
Ian Collins <ian-news@hotmail.com> writes: > I guess you failed to read or at least comprehend the note James > quoted from that page of K&R? One of Jerry's defining traits is his absolute lack of interest in information that contradicts his opinion. The other one is that he used to work at IBM but doesn't like to talk about it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-25 09:12 -0500 |
| Message-ID | <o8s38d$5qj$1@jstuckle.eternal-september.org> |
| In reply to | #104692 |
On 2/25/2017 5:35 AM, Gareth Owen wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> I guess you failed to read or at least comprehend the note James >> quoted from that page of K&R? > > One of Jerry's defining traits is his absolute lack of interest in > information that contradicts his opinion. > > The other one is that he used to work at IBM but doesn't like to talk > about it. > One of my defining traits is to spread ACCURATE INFORMATION. Saying K&R isn't pertinent is bullshit. Most people here can copy/paste the standard (I'm beginning to wonder if they can even read it) but they obviously don't understand it. Try googling for "C precedence associativity". There are 110,000 hits. That's a lot of hits for something which does not exist. And many of them are from some quite respectable sources. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-25 14:24 +0000 |
| Message-ID | <o8s3uv$7tr$1@dont-email.me> |
| In reply to | #104695 |
On 25/02/2017 14:12, Jerry Stuckle wrote: > On 2/25/2017 5:35 AM, Gareth Owen wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> I guess you failed to read or at least comprehend the note James >>> quoted from that page of K&R? >> >> One of Jerry's defining traits is his absolute lack of interest in >> information that contradicts his opinion. >> >> The other one is that he used to work at IBM but doesn't like to talk >> about it. >> > > One of my defining traits is to spread ACCURATE INFORMATION. Saying K&R > isn't pertinent is bullshit. > > Most people here can copy/paste the standard (I'm beginning to wonder if > they can even read it) but they obviously don't understand it. > > Try googling for "C precedence associativity". There are 110,000 hits. > That's a lot of hits for something which does not exist. And many of > them are from some quite respectable sources. The standard doesn't seem to like stating facts that can be deduced by reading the relevant parts. In fact it says exactly that: "The syntax specifies the precedence of operators..." Never mind that it can be a hard slog trying to discover those facts. That why other reference materials exist. (Page 53 of K&R2 for example; my copy seems to fall open at that page.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-25 15:59 -0500 |
| Message-ID | <o8sr3o$rks$1@jstuckle.eternal-september.org> |
| In reply to | #104696 |
On 2/25/2017 9:24 AM, BartC wrote: > On 25/02/2017 14:12, Jerry Stuckle wrote: >> On 2/25/2017 5:35 AM, Gareth Owen wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> I guess you failed to read or at least comprehend the note James >>>> quoted from that page of K&R? >>> >>> One of Jerry's defining traits is his absolute lack of interest in >>> information that contradicts his opinion. >>> >>> The other one is that he used to work at IBM but doesn't like to talk >>> about it. >>> >> >> One of my defining traits is to spread ACCURATE INFORMATION. Saying K&R >> isn't pertinent is bullshit. >> >> Most people here can copy/paste the standard (I'm beginning to wonder if >> they can even read it) but they obviously don't understand it. >> >> Try googling for "C precedence associativity". There are 110,000 hits. >> That's a lot of hits for something which does not exist. And many of >> them are from some quite respectable sources. > > The standard doesn't seem to like stating facts that can be deduced by > reading the relevant parts. In fact it says exactly that: "The syntax > specifies the precedence of operators..." > > Never mind that it can be a hard slog trying to discover those facts. > That why other reference materials exist. (Page 53 of K&R2 for example; > my copy seems to fall open at that page.) > Exactly. People here can copy/paste the standard. But they don't UNDERSTAND the standard. And I'm beginning to wonder if they can even READ the standard. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 13 of 27 — ← Prev page 1 … 11 12 [13] 14 15 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web