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 14 of 27 — ← Prev page 1 … 12 13 [14] 15 16 … 27 Next page →
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 18:03 -0800 |
| Message-ID | <98b131c2-8bde-4558-a41b-cbdb935ec684@googlegroups.com> |
| In reply to | #104667 |
On Friday, February 24, 2017 at 8:08:21 PM UTC-5, Jerry Stuckle wrote: > On 2/24/2017 6:21 PM, jameskuyper@verizon.net wrote: ... > > 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, I never said anything of the kind - but it happens to be true. As far as the C standard is concerned, operators are not evaluated. It's expressions that get evaluated. You can't evaluate an operator such as "+", but you can evaluate an expression such as "1+2". "evaluation" means "determining the value of" - how do you determine the value of an addition operator without combining it with the operands that turn the operator into an expression? But I also never said that the order of evaluation of expressions is undefined. I pointed out that 6.5p1 does impose some requirements on the order of evaluations of expressions. I also pointed out that 6.5p3 specifies that "Except as specified later, side effects and value computations of subexpressions are unsequenced." However, there are several cases "specified later" where sub-expressions are sequenced. Specifically, the sequence is specified for the function call, logical and, logical or, conditional, and comma expressions. The sequence is also specified for declarations, full expressions, and format specifiers (see Annex C). How can you have read my previous citations of these clauses, and concluded that I was claiming that there were no such requirements? Implementations have a lot of freedom to reorder the evaluation of expressions, but that freedom is not unconstrained. It's constrained by rules connected to the syntax, but those rules are not precedence rules - and that's what I DID say.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 21:50 -0500 |
| Message-ID | <o8qr8r$uci$2@jstuckle.eternal-september.org> |
| In reply to | #104680 |
On 2/24/2017 9:03 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 8:08:21 PM UTC-5, Jerry Stuckle wrote: >> On 2/24/2017 6:21 PM, jameskuyper@verizon.net wrote: > ... >>> 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, > > I never said anything of the kind - but it happens to be true. As far as the C > standard is concerned, operators are not evaluated. It's expressions that get > evaluated. You can't evaluate an operator such as "+", but you can evaluate an > expression such as "1+2". "evaluation" means "determining the value of" - how > do you determine the value of an addition operator without combining it with > the operands that turn the operator into an expression? > OK, so every compiler manufacturer can define their own order of operator evaluation. I'm really glad to know you think that way. > But I also never said that the order of evaluation of expressions is undefined. > I pointed out that 6.5p1 does impose some requirements on the order of > evaluations of expressions. I also pointed out that 6.5p3 specifies that > "Except as specified later, side effects and value computations of > subexpressions are unsequenced." However, there are several cases "specified > later" where sub-expressions are sequenced. Specifically, the sequence is > specified for the function call, logical and, logical or, conditional, and > comma expressions. The sequence is also specified for declarations, full > expressions, and format specifiers (see Annex C). How can you have read my > previous citations of these clauses, and concluded that I was claiming that > there were no such requirements? > > Implementations have a lot of freedom to reorder the evaluation of expressions, > but that freedom is not unconstrained. It's constrained by rules connected to > the syntax, but those rules are not precedence rules - and that's what I DID > say. > Those rules are determined by precedence and associativity - as indicated in K&R. But don't mix up the evaluation of operators with the evaluation of operands. The latter is not defined. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-24 19:04 -0800 |
| Message-ID | <09db8f4a-0f9e-4089-962a-7acc4fb57797@googlegroups.com> |
| In reply to | #104683 |
On Friday, February 24, 2017 at 9:49:58 PM UTC-5, Jerry Stuckle wrote: ... > OK, so every compiler manufacturer can define their own order of > operator evaluation. I'm really glad to know you think that way. I suppose they could. Operator evaluation is a meaningless term in the context of the C standard. As long as those implementations give the term a definition, and if they define those rules in a way that doesn't conflict with any of the\ other requirements of the C standard, they can evaluate operators in any order they like. However, they must obey all of the restrictions the C standard impose on the order of evaluation of expressions, and there's quite a few of those. ... > Those rules are determined by precedence and associativity - as > indicated in K&R. K&R doesn't apply to modern C. And K&R didn't tie the order of evaluation of expressions to precedence and associativity any more than the C standard does. And it didn't say anything about the order of evaluation of operators. It only ever talks about evaluation of expressions. > But don't mix up the evaluation of operators with the evaluation of > operands. The latter is not defined. It's the former that's not defined - operators can't be evaluated. The evaluation of expressions (with some expressions being operands of other expressions) occurs in an order that is partially, but no completely, specified by the C standard.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-24 23:20 -0500 |
| Message-ID | <o8r0i3$931$2@jstuckle.eternal-september.org> |
| In reply to | #104686 |
On 2/24/2017 10:04 PM, jameskuyper@verizon.net wrote: > On Friday, February 24, 2017 at 9:49:58 PM UTC-5, Jerry Stuckle wrote: > ... >> OK, so every compiler manufacturer can define their own order of >> operator evaluation. I'm really glad to know you think that way. > > I suppose they could. Operator evaluation is a meaningless term in the context > of the C standard. As long as those implementations give the term a definition, > and if they define those rules in a way that doesn't conflict with any of the\ > other requirements of the C standard, they can evaluate operators in any order > they like. However, they must obey all of the restrictions the C standard > impose on the order of evaluation of expressions, and there's quite a few of those. > That would make C completely unusable as a language. Once could not guarantee the result of any expression containing two or more operators. > ... >> Those rules are determined by precedence and associativity - as >> indicated in K&R. > > K&R doesn't apply to modern C. And K&R didn't tie the order of evaluation of > expressions to precedence and associativity any more than the C standard does. > And it didn't say anything about the order of evaluation of operators. It only > ever talks about evaluation of expressions. > Everything in C is based on K&R, and much of it - including operator precedence and associativity - are as valid today as they were in the 1970's. >> But don't mix up the evaluation of operators with the evaluation of >> operands. The latter is not defined. > > It's the former that's not defined - operators can't be evaluated. The > evaluation of expressions (with some expressions being operands of other > expressions) occurs in an order that is partially, but no completely, specified > by the C standard. > No, operators cannot be evaluated. But expressions containing operators are evaluated in a very specific order. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-02-25 21:26 -0700 |
| Message-ID | <1befylefw1.fsf@pfeifferfamily.net> |
| In reply to | #104645 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > 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. What *you* fail to understand is that the standard describing the language, and your interpretation of that standard, aren't the same thing. So if anyone pulls back to the actual standard, or has a different interpretation of it, you immediately claim they don't UNDERSTAND. No, they may well understand, but they don't agree. There really is a difference -- one which, near as I can tell from your posts, you don't grasp at all.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-26 10:09 -0500 |
| Message-ID | <o8uqvo$758$1@jstuckle.eternal-september.org> |
| In reply to | #104742 |
On 2/25/2017 11:26 PM, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> 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. > > What *you* fail to understand is that the standard describing the > language, and your interpretation of that standard, aren't the same > thing. So if anyone pulls back to the actual standard, or has a > different interpretation of it, you immediately claim they don't > UNDERSTAND. No, they may well understand, but they don't agree. There > really is a difference -- one which, near as I can tell from your posts, > you don't grasp at all. > My interpretation is supported by many reputable people and organizations. For instance - Purdue University: http://web.ics.purdue.edu/~cs240/misc/operators.html University of Hawaii: http://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html Microsoft: https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx And K&R. And thousands of others. So you're saying all of those are interpreting the standard wrong, also? No, there are several people here who can copy and paste the standard, but don't understand it. I'm not sure they can even read it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-26 17:41 +0000 |
| Message-ID | <87d1e4alzc.fsf@bsb.me.uk> |
| In reply to | #104763 |
<snip> ... stuff about the frequently quoted "precedence and associativity determine the order in which the operations are done" rule. I've stayed out if this for the time being because I think my view is slightly different to Richard's and James's and I did not want to complicate matters. But matters are already out of hand, so I hope that some people will find this helpful. There are two problems with the oft-quoted rule. First, it's simply wrong as stated. There are lots of cases where it ignores the most important element of the semantics: sizeof *NULL 0 && 1/0 0 ? 1 : 1/0 are all well-defined because the operator that, according to the "rule", *should* be done first is not done at all. Secondly, it's unhelpful. Where it applies, it only makes sense in some abstract view of expressions. The best you can say is that in the basic cases (where the rules is not actually wrong), an implementation must behave *as if* the higher precedence operator is done fist. But since you can't tell what operations happen when, that's not a very helpful thing to know. Without the "as if" the rule suggests that C can't optimise or re-order operator evaluation. And as an explanation of the semantics it's no better than simply explaining how precedence and associativity can be seen as determining where parentheses go (or are not needed depending on your preference). It says something that is not useful instead of something that is. So the best explanation is that precedence and associativity are a way to explain how the C grammar causes an expression to be parsed. I.e. it should be explained in textual terms: a + b + c is parsed as (a + b) + c rather than pointlessly explaining that unhelpfully saying that the first addition is "done before the second". > My interpretation is supported by many reputable people and > organizations. For instance - Unfortunately best practice is not always common practice. > Purdue University: > http://web.ics.purdue.edu/~cs240/misc/operators.html Well, that table has several significant errors (I count three but it depends on what you call a separate error). The errors don't relate to the rule, but it is obviously not a carefully prepared table. > University of Hawaii: > http://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html This one really nails it's colours to the precedence mast, stating the rule in such a clear and categorical way that the reader must conclude that in 0 ? 1 : 1/0 the division must be done before the ?:. This error is corrected in relation to && and || (right at the bottom of the page), but nothing is said to correct the misinformation about ?:. The author(s) go further and make another error which you avoided. It states that the right hand side of an assignment is evaluated first (because, bizarrely, assignment is right associative). I think even you would agree that that is going too far, even taking the "as if" rule into account. > Microsoft: https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx Dreadful. It has a version of the rule that I can't interpret. It says "Expressions with higher-precedence operators are evaluated first", but gives no way to determine the precedence of a general expression. It that goes on to make the more serious error that "The following table summarizes the precedence and associativity (the order in which the operands are evaluated) of C operators". Apart from being bad writing, that's wrong. > And K&R. I could not find an example of "the rule" in K&R. I did find a counter example which says that a compiler may reorder the evaluation of an expression involving a commutative and associative operator, even when parenthesised (Note: that's only true in modern C if the compiler can prove that it makes no difference), but not the actual rule. Many examples are explained as I would do it by adding parentheses. Where is the rule stated? (I only have K&R1.) > And thousands of others. Yes, you picked bad examples, but there are lots more and some must be better than these. > So you're saying all of those are interpreting > the standard wrong, also? Yes, every operator table I've seen is wrong because you can't represent the grammar of C expressions in terms of simple precedence and associativity. For example, sizeof (int) f appears to be (from the limited view of these tables) two 1-place prefix operators acting on f. The associativity rules would give the parse sizeof ((int) f) but that is not correct. The MSDN page has obviously been written by someone looking at the grammar, because they've split off what they call typecasts (yuck) as a separate operator from the other unary ones, as the grammar does. But that just makes matters worse because the extra grammar rule does not correspond to a new precedence level. What does it even mean to have two 1-place prefix operators with different precedence? But I still think an operator table is a good way to summarise the grammar, and it is so close to being correct that it's well worth these minor wrinkles. But I would not make matters worse by saying anything about order of evaluation in relation to precedence and associativity. I'd always explain it terms of parsing. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2017-02-26 12:56 -0500 |
| Message-ID | <o8v4ok$9pi$1@dont-email.me> |
| In reply to | #104772 |
On Sunday February 26 2017 12:41, in comp.lang.c, "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote: [snip] >> And K&R. > > I could not find an example of "the rule" in K&R. [snip] > Where is the rule stated? (I only have K&R1.) FWIW, in K&R1, see 2.12 "Precedence and Order of Evaluation" (pp 48-50), where they include a table summarizing "the rules for precedence and associativity of all operators". -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-27 00:23 +0000 |
| Message-ID | <87zih88ork.fsf@bsb.me.uk> |
| In reply to | #104773 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > On Sunday February 26 2017 12:41, in comp.lang.c, "Ben Bacarisse" > <ben.usenet@bsb.me.uk> wrote: > > [snip] > >>> And K&R. >> >> I could not find an example of "the rule" in K&R. > [snip] >> Where is the rule stated? (I only have K&R1.) > > FWIW, in K&R1, see 2.12 "Precedence and Order of Evaluation" (pp 48-50), where > they include a table summarizing "the rules for precedence and associativity > of all operators". I know about the table, but are you saying there is an example of the claim being made somewhere as well? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2017-02-26 19:02 +0100 |
| Message-ID | <87r32kkey5.fsf@news.bourguet.org> |
| In reply to | #104772 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Yes, every operator table I've seen is wrong because you can't represent > the grammar of C expressions in terms of simple precedence and > associativity. For example, > > sizeof (int) f > > appears to be (from the limited view of these tables) two 1-place prefix > operators acting on f. The associativity rules would give the parse > > sizeof ((int) f) > > but that is not correct. sizeof (int) + 42 is an interesting example as both readings would be viable. A precedence&associativity reading interprets it as (sizeof((int)(+42))), the grammar one as (sizeof(int))+42. BTW, could someone with access to the first edition of K&R check if sizeof can be applied to types there? It can't in the version of the C Reference Manual that came with 6th Edition Unix (which is linked in the late DMR's home page) and was later expanded to be the white book. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-26 13:49 -0500 |
| Message-ID | <4735a82c-1753-b663-d2ce-9c52ee1fc62c@verizon.net> |
| In reply to | #104775 |
On 02/26/2017 01:02 PM, Jean-Marc Bourguet wrote: ... > BTW, could someone with access to the first edition of K&R check if sizeof > can be applied to types there? It can't in the version of the C Reference > Manual that came with 6th Edition Unix (which is linked in the late DMR's > home page) and was later expanded to be the white book. The grammar in 7.2 has both "sizeof expression" and "sizeof ( type-name )", which matches the detailed description of the sizeof operator at the bottom of the same section. Code examples in the book contains many examples of both forms. However, sizeof(type-name) is missing from the grammar in 18.1.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2017-02-26 19:55 +0100 |
| Message-ID | <87lgsskcij.fsf@news.bourguet.org> |
| In reply to | #104782 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 02/26/2017 01:02 PM, Jean-Marc Bourguet wrote: > ... >> BTW, could someone with access to the first edition of K&R check if sizeof >> can be applied to types there? It can't in the version of the C Reference >> Manual that came with 6th Edition Unix (which is linked in the late DMR's >> home page) and was later expanded to be the white book. > > The grammar in 7.2 has both "sizeof expression" and "sizeof ( type-name )", > which matches the detailed description of the sizeof operator at the bottom > of the same section. Code examples in the book contains many examples of > both forms. However, sizeof(type-name) is missing from the grammar in 18.1. Thanks. Thus it was a quite new at the time. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-26 12:05 -0800 |
| Message-ID | <c9644f95-3955-4568-a6eb-c274f3d3b808@googlegroups.com> |
| In reply to | #104775 |
On Sunday, February 26, 2017 at 12:03:05 PM UTC-6, Jean-Marc Bourguet wrote: > sizeof (int) + 42 is an interesting example as both readings would be > viable. A precedence&associativity reading interprets it as > (sizeof((int)(+42))), the grammar one as (sizeof(int))+42. A variation on that provides a nice example of a situation where it's impossible to parse C syntax without knowing how things are defined. The expression "sizeof (fnord)+3" could have two different meanings depending upon whether fnord is defined in the current scope as an object or as a type. Using `sizeof` expressions within array bounds within nested function pointer types can create some interesting scoping challenges for a compiler; I'm not really sure that any useful purpose is served by requiring that compilers keep track of nested scopes for such things rather than merely validating the general syntax of [ and ] within a function pointer, but C99's VLA rules seem to require that compilers expend the extra effort.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-27 00:52 +0000 |
| Message-ID | <87mvd88nfa.fsf@bsb.me.uk> |
| In reply to | #104775 |
Jean-Marc Bourguet <jm@bourguet.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Yes, every operator table I've seen is wrong because you can't represent >> the grammar of C expressions in terms of simple precedence and >> associativity. For example, >> >> sizeof (int) f >> >> appears to be (from the limited view of these tables) two 1-place prefix >> operators acting on f. The associativity rules would give the parse >> >> sizeof ((int) f) >> >> but that is not correct. > > sizeof (int) + 42 is an interesting example as both readings would be > viable. A precedence&associativity reading interprets it as > (sizeof((int)(+42))), the grammar one as (sizeof(int))+42. Yes, that's a nicer example. <snip question already answered> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-26 22:01 -0500 |
| Message-ID | <o904ml$bmi$1@dont-email.me> |
| In reply to | #104804 |
On 02/26/2017 08:21 PM, Stefan Ram wrote: ... > I don't know whether this was already mentioned in this thread: I have made reference to this issue, but have not given a detailed explanation. > Say, one intends the behavior of > > 0 ?( x = 0 ):( y = 0 ); > > . This can be worded in C as follows: > > 0 ? x = 0 : ( y = 0 ); [My newsreader was displaying :( as a sad face, I inserted a space to prevent that.] > . The left pair of parentheses can be omitted, because on > the left of the �:�, the precendence of the ternary operator > is a little bit smaller than on the right of the �:�, where > the parentheses are still needed. > > So we cannot simply say that the precendence of the ternary > operator is "larger" or "smaller" than that of the assignment > operator, we need to look at the grammar. Yes - that's the one key feature of the grammar of C expressions that cannot be explain purely by using precedence and associativity. Precedence and associativity otherwise provide a very good way of describing C expression syntax. Jerry's lies to the contrary notwithstanding, I've never denied that. What I have said, correctly, is that the C standard itself never uses either of those concepts to explain C's expression syntax, nor does it use them in any of it's rules concerning the order of evaluation of expressions.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 10:42 -0500 |
| Message-ID | <o91h9s$kpc$1@jstuckle.eternal-september.org> |
| In reply to | #104816 |
On 2/26/2017 10:01 PM, James Kuyper wrote: > On 02/26/2017 08:21 PM, Stefan Ram wrote: > ... >> I don't know whether this was already mentioned in this thread: > > I have made reference to this issue, but have not given a detailed > explanation. > >> Say, one intends the behavior of >> >> 0 ?( x = 0 ):( y = 0 ); >> >> . This can be worded in C as follows: >> >> 0 ? x = 0 : ( y = 0 ); > > [My newsreader was displaying :( as a sad face, I inserted a space to > prevent that.] > >> . The left pair of parentheses can be omitted, because on >> the left of the �:�, the precendence of the ternary operator >> is a little bit smaller than on the right of the �:�, where >> the parentheses are still needed. >> >> So we cannot simply say that the precendence of the ternary >> operator is "larger" or "smaller" than that of the assignment >> operator, we need to look at the grammar. > > Yes - that's the one key feature of the grammar of C expressions that > cannot be explain purely by using precedence and associativity. > Precedence and associativity otherwise provide a very good way of > describing C expression syntax. Jerry's lies to the contrary > notwithstanding, I've never denied that. What I have said, correctly, is > that the C standard itself never uses either of those concepts to > explain C's expression syntax, nor does it use them in any of it's rules > concerning the order of evaluation of expressions. > Precedence and associativity have not changed. But unlike most languages, some C operators also have an effect on flow control. In the case of the ternary operator, only one of the subordinate clauses is evaluated. This is flow control, not precedence and associativity. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 08:51 -0500 |
| Message-ID | <o91ap7$q14$1@jstuckle.eternal-september.org> |
| In reply to | #104804 |
On 2/26/2017 8:21 PM, Stefan Ram wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Jean-Marc Bourguet <jm@bourguet.org> writes: >>> sizeof (int) + 42 is an interesting example as both readings would be >>> viable. A precedence&associativity reading interprets it as >>> (sizeof((int)(+42))), the grammar one as (sizeof(int))+42. >> Yes, that's a nicer example. > > I don't know whether this was already mentioned in this thread: > > Say, one intends the behavior of > > 0 ?( x = 0 ):( y = 0 ); > > . This can be worded in C as follows: > > 0 ? x = 0 :( y = 0 ); > > . The left pair of parentheses can be omitted, because on > the left of the »:«, the precendence of the ternary operator > is a little bit smaller than on the right of the »:«, where > the parentheses are still needed. > > So we cannot simply say that the precendence of the ternary > operator is "larger" or "smaller" than that of the assignment > operator, we need to look at the grammar. > > I found this example on this page > > http://www.purl.org/stefan_ram/pub/ternaerer_c > > from my German-language C course. (I don't give the proper > grammar there because it would be too difficult for the > intended audience of this course for beginners.) > Again, incorrect. With the ternary operator, only one of the two subordinate expressions are evaluated, never both. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-27 13:59 +0000 |
| Message-ID | <o91b7n$t1n$1@dont-email.me> |
| In reply to | #104853 |
On 27/02/2017 13:51, Jerry Stuckle wrote:
> Again, incorrect. With the ternary operator, only one of the two
> subordinate expressions are evaluated, never both.
If I compile:
printf("%d\n", rand() ? 2+3 : 4+5*6);
with gcc, then the output code contains both '5' and '34', the two
possible expressions.
So both have been evaluated in this case.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-02-27 15:36 +0000 |
| Message-ID | <slrn3vfsob8hv8.aue.ike@iceland.freeshell.org> |
| In reply to | #104854 |
On 2017-02-27, BartC <bc@freeuk.com> wrote:
> On 27/02/2017 13:51, Jerry Stuckle wrote:
>
>> Again, incorrect. With the ternary operator, only one of the two
>> subordinate expressions are evaluated, never both.
>
> If I compile:
>
> printf("%d\n", rand() ? 2+3 : 4+5*6);
>
> with gcc, then the output code contains both '5' and '34', the two
> possible expressions.
>
> So both have been evaluated in this case.
Are you talking about both '5' and '34' appearing in a single run,
or '5' appearing in one run, and '34' appearing in another run?
Can you show the complete code, plus the output of a few runs?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-27 10:01 -0800 |
| Message-ID | <lnfuizfr8a.fsf@kst-u.example.com> |
| In reply to | #104873 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2017-02-27, BartC <bc@freeuk.com> wrote:
>> On 27/02/2017 13:51, Jerry Stuckle wrote:
>>> Again, incorrect. With the ternary operator, only one of the two
>>> subordinate expressions are evaluated, never both.
>>
>> If I compile:
>>
>> printf("%d\n", rand() ? 2+3 : 4+5*6);
>>
>> with gcc, then the output code contains both '5' and '34', the two
>> possible expressions.
>>
>> So both have been evaluated in this case.
>
> Are you talking about both '5' and '34' appearing in a single run,
> or '5' appearing in one run, and '34' appearing in another run?
>
> Can you show the complete code, plus the output of a few runs?
He's talking about the generated assembly or machine code, not the
run-time output. And he's assuming that if the constant 34 appears in
the assembly code output, then the expression has been "evaluated".
In fact, since 4+5*6 is a constant expression, it makes no difference in
run-time behavior whether it's evaluated or not. If the output happens
to be 5, then the generated code that loads the value 34 is not
executed, and vice versa.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 14 of 27 — ← Prev page 1 … 12 13 [14] 15 16 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web