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 24 of 27 — ← Prev page 1 … 22 23 [24] 25 26 27 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-01 16:57 +0000 |
| Message-ID | <o96ue4$vuk$2@dont-email.me> |
| In reply to | #105270 |
On 01/03/17 16:40, Jerry Stuckle wrote: > On 2/28/2017 8:26 PM, Ian Collins wrote: >> On 03/ 1/17 09:43 AM, Jerry Stuckle wrote: >>> On 2/28/2017 1:36 PM, Ian Collins wrote: >>>> On 03/ 1/17 07:32 AM, Jerry Stuckle wrote: >>>>> >>>>> Parens are not required for sizeof - although many people use them. >>>>> And >>>>> the parens elevate the precedence of the expression within them. >>>> >>>> Do what? How do you elevate the precedence of something that isn't >>>> evaluated? Oh by the way, are you aware of the case where the brackets >>>> are required? >>>> >>> >>> The increment operator is required to be evaluated. >> >> When it is the operand of sizeof, it is required *not* to be evaluated. >> > > Actually, according to 6.7.6.2(5), it is unspecified as to whether it is > evaluated or not. See 6.5.3.4(2). -- 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 | me <crisdunbar@gmail.com> |
|---|---|
| Date | 2017-03-01 10:19 -0800 |
| Message-ID | <b7e2d44f-d233-4ab1-af86-90248416f78a@googlegroups.com> |
| In reply to | #105270 |
On Wednesday, March 1, 2017 at 8:40:42 AM UTC-8, Jerry Stuckle wrote: > On 2/28/2017 8:26 PM, Ian Collins wrote: > > On 03/ 1/17 09:43 AM, Jerry Stuckle wrote: > >> On 2/28/2017 1:36 PM, Ian Collins wrote: > >>> On 03/ 1/17 07:32 AM, Jerry Stuckle wrote: > >>>> > >>>> Parens are not required for sizeof - although many people use them. > >>>> And > >>>> the parens elevate the precedence of the expression within them. > >>> > >>> Do what? How do you elevate the precedence of something that isn't > >>> evaluated? Oh by the way, are you aware of the case where the brackets > >>> are required? > >>> > >> > >> The increment operator is required to be evaluated. > > > > When it is the operand of sizeof, it is required *not* to be evaluated. > > > > Actually, according to 6.7.6.2(5), it is unspecified as to whether it is > evaluated or not. No, that paragraph is referring to the "size" in an array declarator and whether or not _that_ expression is evaluated when the array declarator is within a sizeof expression. The question at hand was about this: sizeof x++; It is absolutely _required_ that the increment NOT be 'executed' in this case. <snip>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-28 20:25 +0100 |
| Message-ID | <o94io4$jsa$1@dont-email.me> |
| In reply to | #105134 |
On 28/02/17 19:32, Jerry Stuckle wrote: > On 2/28/2017 12:23 PM, jameskuyper@verizon.net wrote: >> On Monday, February 27, 2017 at 11:59:58 PM UTC-5, Jerry Stuckle wrote: >>> That is not a side effect. >> >> "Accessing a volatile object, modifying an object, modifying a file, or calling\ >> a function that does any of those operations are all _side effects_." >> (5.1.2.3p2). The term "side effects" is italicized in that clause, an ISO >> convention indicating that this clause constitutes the official definition of >> the term. Any Stuckle-specific definition of the term "side effect" that might >> exclude modifying the object 'a' is irrelevant to correctly understanding rules >> from the standard, which are written using the definition in 5.1.2.3p2. >> > > If you want to call it a side effect, fine. It is not /James/ that is calling it a side effect. It is the C standards that call it a side effect. That is the authoritative reference. > But it still must be > performed before the sizeof operator due to the parens. Not that it > makes any difference since sizeof is generally evaluated at compile > time, anyway. > The operand for a sizeof expression is /not/ evaluated, regardless of any parentheses, unless it is a VLA type (in which case it /is/ evaluated). So if you write "sizeof(*p++)", then p is not evaluated, *p is not evaluated, and the increment is not done.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 15:45 -0500 |
| Message-ID | <o94ndn$4g2$5@jstuckle.eternal-september.org> |
| In reply to | #105146 |
On 2/28/2017 2:25 PM, David Brown wrote: > On 28/02/17 19:32, Jerry Stuckle wrote: >> On 2/28/2017 12:23 PM, jameskuyper@verizon.net wrote: >>> On Monday, February 27, 2017 at 11:59:58 PM UTC-5, Jerry Stuckle wrote: > >>>> That is not a side effect. >>> >>> "Accessing a volatile object, modifying an object, modifying a file, or calling\ >>> a function that does any of those operations are all _side effects_." >>> (5.1.2.3p2). The term "side effects" is italicized in that clause, an ISO >>> convention indicating that this clause constitutes the official definition of >>> the term. Any Stuckle-specific definition of the term "side effect" that might >>> exclude modifying the object 'a' is irrelevant to correctly understanding rules >>> from the standard, which are written using the definition in 5.1.2.3p2. >>> >> >> If you want to call it a side effect, fine. > > It is not /James/ that is calling it a side effect. It is the C > standards that call it a side effect. That is the authoritative reference. > >> But it still must be >> performed before the sizeof operator due to the parens. Not that it >> makes any difference since sizeof is generally evaluated at compile >> time, anyway. >> > > The operand for a sizeof expression is /not/ evaluated, regardless of > any parentheses, unless it is a VLA type (in which case it /is/ > evaluated). So if you write "sizeof(*p++)", then p is not evaluated, *p > is not evaluated, and the increment is not done. > > > Sigh.. You guys are hopeless. I'm tired of trying to teach the pigs to sing. I've quoted multiple independent, respected resources and you've argued with every one of them. No wonder the real experts on the C language left this group long ago. You spend so much time trying to count the hairs on a gnat's ass tat you fail to see the dog it's sitting on. -- ================== 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-03-01 14:28 +1300 |
| Message-ID | <ehmmegF60pU3@mid.individual.net> |
| In reply to | #105163 |
On 03/ 1/17 09:45 AM, Jerry Stuckle wrote: > On 2/28/2017 2:25 PM, David Brown wrote: >> On 28/02/17 19:32, Jerry Stuckle wrote: >>> On 2/28/2017 12:23 PM, jameskuyper@verizon.net wrote: >>>> On Monday, February 27, 2017 at 11:59:58 PM UTC-5, Jerry Stuckle wrote: >> >>>>> That is not a side effect. >>>> >>>> "Accessing a volatile object, modifying an object, modifying a file, or calling\ >>>> a function that does any of those operations are all _side effects_." >>>> (5.1.2.3p2). The term "side effects" is italicized in that clause, an ISO >>>> convention indicating that this clause constitutes the official definition of >>>> the term. Any Stuckle-specific definition of the term "side effect" that might >>>> exclude modifying the object 'a' is irrelevant to correctly understanding rules >>>> from the standard, which are written using the definition in 5.1.2.3p2. >>>> >>> >>> If you want to call it a side effect, fine. >> >> It is not /James/ that is calling it a side effect. It is the C >> standards that call it a side effect. That is the authoritative reference. >> >>> But it still must be >>> performed before the sizeof operator due to the parens. Not that it >>> makes any difference since sizeof is generally evaluated at compile >>> time, anyway. >>> >> >> The operand for a sizeof expression is /not/ evaluated, regardless of >> any parentheses, unless it is a VLA type (in which case it /is/ >> evaluated). So if you write "sizeof(*p++)", then p is not evaluated, *p >> is not evaluated, and the increment is not done. >> >> >> > Sigh.. You guys are hopeless. Are we? Which of those sources for yours claims the operand for a sizeof expression is evaluated? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-03-01 03:17 +0000 |
| Message-ID | <o95efn$1a4$1@reader1.panix.com> |
| In reply to | #105199 |
In article <ehmmegF60pU3@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:
>On 03/ 1/17 09:45 AM, Jerry Stuckle wrote:
>> Sigh.. You guys are hopeless.
>
>Are we? Which of those sources for yours claims the operand for a
>sizeof expression is evaluated?
All kinds of sources. Great sources. The Best sources. Believe
me; sources like you wouldn't believe. You're going to see so many
amazing sources that you'll get sick of great sources. Bigly.
Phenomenal sources. Look, you're arguing with someone who is is,
like, really smart, OK? No one knows C like him. He worked for IBM
on big machines like mainframes. He's got alternative standards,
alternative compilers and alternative runtime environments. But
not for you losers in comp.lang.c. Don't you know? The fake ISO
standard is lying to you. Believe me. Only he can tell you how C
*really* works. Only Jerry, alone, actually knows C and together
he and his sources are Making C Great Again.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-01 11:43 -0500 |
| Message-ID | <o96tjo$s7a$3@jstuckle.eternal-september.org> |
| In reply to | #105199 |
On 2/28/2017 8:28 PM, Ian Collins wrote: > On 03/ 1/17 09:45 AM, Jerry Stuckle wrote: >> On 2/28/2017 2:25 PM, David Brown wrote: >>> On 28/02/17 19:32, Jerry Stuckle wrote: >>>> On 2/28/2017 12:23 PM, jameskuyper@verizon.net wrote: >>>>> On Monday, February 27, 2017 at 11:59:58 PM UTC-5, Jerry Stuckle >>>>> wrote: >>> >>>>>> That is not a side effect. >>>>> >>>>> "Accessing a volatile object, modifying an object, modifying a >>>>> file, or calling\ >>>>> a function that does any of those operations are all _side effects_." >>>>> (5.1.2.3p2). The term "side effects" is italicized in that clause, >>>>> an ISO >>>>> convention indicating that this clause constitutes the official >>>>> definition of >>>>> the term. Any Stuckle-specific definition of the term "side effect" >>>>> that might >>>>> exclude modifying the object 'a' is irrelevant to correctly >>>>> understanding rules >>>>> from the standard, which are written using the definition in >>>>> 5.1.2.3p2. >>>>> >>>> >>>> If you want to call it a side effect, fine. >>> >>> It is not /James/ that is calling it a side effect. It is the C >>> standards that call it a side effect. That is the authoritative >>> reference. >>> >>>> But it still must be >>>> performed before the sizeof operator due to the parens. Not that it >>>> makes any difference since sizeof is generally evaluated at compile >>>> time, anyway. >>>> >>> >>> The operand for a sizeof expression is /not/ evaluated, regardless of >>> any parentheses, unless it is a VLA type (in which case it /is/ >>> evaluated). So if you write "sizeof(*p++)", then p is not evaluated, *p >>> is not evaluated, and the increment is not done. >>> >>> >>> >> Sigh.. You guys are hopeless. > > Are we? Which of those sources for yours claims the operand for a > sizeof expression is evaluated? > If you will notice, precedence and associativity do not affect unspecified behavior. And the only independent source you have quoted to support your position is a single site run by a single person, with unsubstantiated claims as to how much his site is "peer reviewed". If your position is so correct, you should be able to find thousands of sites to support your position. I can do it for mine. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-01 10:28 -0800 |
| Message-ID | <346d9693-3b39-49e7-838d-38a751ad5436@googlegroups.com> |
| In reply to | #105271 |
On Wednesday, March 1, 2017 at 11:43:33 AM UTC-5, Jerry Stuckle wrote: > On 2/28/2017 8:28 PM, Ian Collins wrote: ... > > Are we? Which of those sources for yours claims the operand for a > > sizeof expression is evaluated? > > > > If you will notice, precedence and associativity do not affect > unspecified behavior. I think you're confusing unspecified behavior with undefined behavior. When behavior is undefined, the standard imposes no requirements on it of any kind - all other requirements that might otherwise apply are cancelled. When behavior is unspecified, the standard specifies (or in some cases, implies) a list of permitted possibilities (which, in some cases, is infinite in length). A conforming implementation must choose one of those possibilities, and must continue to conform to all of the other requirements imposed by the standard. You apparently wrote that thinking that 6.7.6.2p5 applied, in which case the list of options has only two items: evaluate and don't evaluate. However, in reality, 6.5.3.4p2 applies, so "don't evaluate" is the only option.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-28 11:35 -0800 |
| Message-ID | <964bf808-c3ab-4355-a9b5-86b39c25531f@googlegroups.com> |
| In reply to | #105134 |
On Tuesday, February 28, 2017 at 1:32:29 PM UTC-5, Jerry Stuckle wrote: > On 2/28/2017 12:23 PM, jameskuyper@verizon.net wrote: > > On Monday, February 27, 2017 at 11:59:58 PM UTC-5, Jerry Stuckle wrote: > >> On 2/27/2017 8:51 PM, jameskuyper@verizon.net wrote: ... > >>> In the following expression: (a=b) && a++ The relevant operators are =, ... > Parens are not required for sizeof - although many people use them. And sizeof? there's no sizeof operator in that expression. > the parens elevate the precedence of the expression within them. ... > performed before the sizeof operator due to the parens. Not that it > makes any difference since sizeof is generally evaluated at compile sizeof? ... > Whatever you want to say. It doesn't matter, because sizeof is sizeof?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 15:46 -0500 |
| Message-ID | <o94nec$4g2$6@jstuckle.eternal-september.org> |
| In reply to | #105148 |
On 2/28/2017 2:35 PM, jameskuyper@verizon.net wrote: > On Tuesday, February 28, 2017 at 1:32:29 PM UTC-5, Jerry Stuckle wrote: >> On 2/28/2017 12:23 PM, jameskuyper@verizon.net wrote: >>> On Monday, February 27, 2017 at 11:59:58 PM UTC-5, Jerry Stuckle wrote: >>>> On 2/27/2017 8:51 PM, jameskuyper@verizon.net wrote: > ... >>>>> In the following expression: (a=b) && a++ The relevant operators are =, > ... >> Parens are not required for sizeof - although many people use them. And > > sizeof? there's no sizeof operator in that expression. > >> the parens elevate the precedence of the expression within them. > ... >> performed before the sizeof operator due to the parens. Not that it >> makes any difference since sizeof is generally evaluated at compile > > sizeof? > ... >> Whatever you want to say. It doesn't matter, because sizeof is > > sizeof? > Sigh.. You guys are hopeless. I'm tired of trying to teach the pigs to sing. I've quoted multiple independent, respected resources and you've argued with every one of them. No wonder the real experts on the C language left this group long ago. You spend so much time trying to count the hairs on a gnat's ass tat you fail to see the dog it's sitting on. -- ================== 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-28 03:07 +0000 |
| Message-ID | <o92pek$rbo$1@dont-email.me> |
| In reply to | #104976 |
On 28/02/17 00:23, James R. Kuyper wrote: > On 02/27/2017 07:01 PM, Richard Heathfield wrote: >> On 27/02/17 23:04, jameskuyper@verizon.net wrote: >> >> <snip> >> >>> The C standard never talks >>> about evaluating operators, it only ever talks about evaluating >>> expressions. >> >> It does, however, come close to talking about evaluating operators. See >> 6.5 Expressions: >> >> "An expression is a sequence of operators and operands that specifies >> computation of a value, or that designates an object or a function, or >> that generates side effects, or that performs a combination thereof. The >> value computations of the operands of an operator are sequenced before >> the value computation of the result of the operator." >> >> I think "evaluating the operator" is not an entirely unreasonable >> shorthand for "the value computation of the result of the operator". > > Yes, but that doesn't support the distinction he wants to make, because > that same substitution would make "evaluation of the operand's operator" > a reasonable alternative way to say "operand evaluation" - and that > would ruin the distinction he's trying to make between operator > evaluation and operand evaluation. Well, no, I don't think I agree. As far as I can tell, the distinction is there to be drawn, because we have the two expressions (in the above cited text) a) value computations of the operands of an operator b) value computation of the result of the operator and the Standard says that (a) has to happen before (b) can happen, which makes perfect sense. The first might reasonably be called "operand evaluation", and the second "operator evaluation". Sure, that's not the term the Standard uses, but it draws the same distinction that the Standard does. The terms are, in my view, just as useful as "precedence" and "associativity". -- 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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-27 23:56 +0000 |
| Message-ID | <o92e7g$6te$1@dont-email.me> |
| In reply to | #104951 |
On 27/02/17 22:29, Jerry Stuckle wrote:
<snip>
> Function call is not an operator.
Oh, I'm sorry. I must have been very foolish to rely on
https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx which says "The
function-call operator is the set of parentheses following the function
identifier." Obviously you don't trust that source.
Look, either you're right (function calls are not operators), in which
case your "reliable source" is blown out of the water, or you're wrong,
in which case you're wrong. But how can we tell which is which?
Well, why not check the language definition?
6.5.2 Postfix operators
Syntax
1
postfix-expression:
primary-expression
postfix-expression [ expression ]
postfix-expression ( argument-expression-list opt )
Well well well. It looks like function calls are operators after all.
>> And that's what precedence /is/ - a way to decide which operands are
>> associated with which operators.
>>
>
> And which order the expressions are evaluated.
No. Really, truly, no.
>> <snip>
>>
>>>> So precedence and associativity do not govern the order in which
>>>> operations are carried out. There is more to it than that. That's what
>>>> people have been saying, and you've been telling us we're talking
>>>> bullshit even while you're agreeing with us.
>>>>
>>>
>>> Nope. I am not agreeing with you. But you have to look at the
>>> operators and how they affect flow control.
>>
>> Then you have to modify your rules of
>> precedence-and-associativity-determined order of processing to take flow
>> control into account.
>>
>
> Nope. Flow control has nothing to do with precedence or associativity.
Make your mind up. Either precedence and associativity uniquely
determine the order of value computations of the results of operators or
they don't. If they do, then we get the wrong result for operations in
which sequence points appear mid-expression. And if they don't, then
your claim falls.
> So you're disagreeing with the experts at Purdue University?
I'm disagreeing with some of the text on the Web page whose URL you
posted. If you are claiming that that page was written by experts in C,
then they must have been having an off-day, because they're wrong.
> So you're also disagreeing with the experts at University of Hawaii?
Again, I'm disagreeing with some of the text on the Web page whose URL
you posted. Again, if that was written by C experts, they were C experts
who were having a bad hair day.
> So you're also disagreeing with the experts at Microsoft?
When they're wrong, yes, of course I disagree.
>> But if they mean this to be C documentation, and if they mean to
>> describe how it must be rather than how it happens to be in their
>> compiler, then they're wrong.
>>
>> Just for fun, here's some C documentation from MSDN that really is from
>> their C section, not their C# section. It's an illustration of
>> recursion, and it's been broken for about 20 years so far:
>>
>> int factorial( int num ); /* Function prototype */
>>
>> int main()
>> {
>> int result, number;
>> .
>> .
>> .
>> result = factorial( number );
>> }
>>
>> int factorial( int num ) /* Function definition */
>> {
>> .
>> .
>> .
>> if ( ( num > 0 ) || ( num <= 10 ) )
>> return( num * factorial( num - 1 ) );
>> }
>>
>> Count the bugs. (So much for a reliable source.)
>>
>
> Zero, because your code is neither complete nor compilable. So it is
> more bullshit.
Not my code. Their code.
<https://msdn.microsoft.com/en-us/library/4bftz997.aspx>
(So are you saying you disagree with the experts at Microsoft?)
> So let's see you show even ONE site which agrees with your
> interpretation - an independent site from a respected resource.
You can't get more independent than ISO/IEC 9899.
>>> Can you find three reputable sites who say these are wrong?
>>
>> I can find one reputable Standard that says they're wrong.
>>
>
> And that is? It has to be separate from your interpretation of the
> standard.
So let's see your interpretation of the Standard. If you're right, it
will be easy to show from the Standard that you're right. (I could show
how you're wrong, but that would be /my/ interpretation.) Let's see
/your/ interpretation, with chapter and verse support.
>
>>> No, your
>>> interpretation of the standard does not count.
>>
>> What's 1+1? And let's not have any of that nonsense about it being 2.
>> (FCOL)
>>
>
> So you're saying thousands of experts in the C language are wrong, and
> you are right.
I'm certainly saying I'm right, yes. And I don't require experts in C to
agree with /me/ --- I only require them to agree with /the Standard/ (as
I do). If the Standard says I'm wrong, then I'm wrong. Does the Standard
say I'm wrong?
> But you can't provide even one reference from an
> respected independent source to support your claims.
ISO/IEC 9899.
> I'm glad you think you are more knowledgeable than all of those experts.
I'm certainly more knowledgeable about C than the people who wrote the
pages you cited (at least in this one respect) --- and that means they
can't be all that expert after all (at least in this one respect).
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 20:18 -0500 |
| Message-ID | <o92j0r$jo5$1@jstuckle.eternal-september.org> |
| In reply to | #104968 |
On 2/27/2017 6:56 PM, Richard Heathfield wrote:
> On 27/02/17 22:29, Jerry Stuckle wrote:
>
> <snip>
>
>> Function call is not an operator.
>
> Oh, I'm sorry. I must have been very foolish to rely on
> https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx which says "The
> function-call operator is the set of parentheses following the function
> identifier." Obviously you don't trust that source.
>
> Look, either you're right (function calls are not operators), in which
> case your "reliable source" is blown out of the water, or you're wrong,
> in which case you're wrong. But how can we tell which is which?
>
> Well, why not check the language definition?
>
> 6.5.2 Postfix operators
> Syntax
> 1
> postfix-expression:
> primary-expression
> postfix-expression [ expression ]
> postfix-expression ( argument-expression-list opt )
>
> Well well well. It looks like function calls are operators after all.
>
>
I will agree you can call a function call an operator. But it is
generally not considered one.
>>> And that's what precedence /is/ - a way to decide which operands are
>>> associated with which operators.
>>>
>>
>> And which order the expressions are evaluated.
>
> No. Really, truly, no.
>
According to the three references I cited, they are. You have yet to
produce a independent reputable site to dispute that.
>>> <snip>
>>>
>>>>> So precedence and associativity do not govern the order in which
>>>>> operations are carried out. There is more to it than that. That's what
>>>>> people have been saying, and you've been telling us we're talking
>>>>> bullshit even while you're agreeing with us.
>>>>>
>>>>
>>>> Nope. I am not agreeing with you. But you have to look at the
>>>> operators and how they affect flow control.
>>>
>>> Then you have to modify your rules of
>>> precedence-and-associativity-determined order of processing to take flow
>>> control into account.
>>>
>>
>> Nope. Flow control has nothing to do with precedence or associativity.
>
> Make your mind up. Either precedence and associativity uniquely
> determine the order of value computations of the results of operators or
> they don't. If they do, then we get the wrong result for operations in
> which sequence points appear mid-expression. And if they don't, then
> your claim falls.
>
OK, in the case of x && y++, the sequence is:
evaluate x
if x is true:
evaluate y++
AND y++ to x
Precedence holds.
In the case of the ternary operator, all three expressions are
subexpressions of the ternary operator. The first expression is
evaluated. Depending on the result, the second or third expression is
evaluated. Precedence.
>> So you're disagreeing with the experts at Purdue University?
>
> I'm disagreeing with some of the text on the Web page whose URL you
> posted. If you are claiming that that page was written by experts in C,
> then they must have been having an off-day, because they're wrong.
>
So you're disagreeing with the experts at Purdue University. I'm glad
you know more about it than they do.
>> So you're also disagreeing with the experts at University of Hawaii?
>
> Again, I'm disagreeing with some of the text on the Web page whose URL
> you posted. Again, if that was written by C experts, they were C experts
> who were having a bad hair day.
>
So you're disagreeing with the experts at the University of Hawaii. I'm
glad you know more about it than they do.
>> So you're also disagreeing with the experts at Microsoft?
>
> When they're wrong, yes, of course I disagree.
>
So you're disagreeing with the experts at Microsoft. I'm glad you know
more about it than they do.
>>> But if they mean this to be C documentation, and if they mean to
>>> describe how it must be rather than how it happens to be in their
>>> compiler, then they're wrong.
>>>
>>> Just for fun, here's some C documentation from MSDN that really is from
>>> their C section, not their C# section. It's an illustration of
>>> recursion, and it's been broken for about 20 years so far:
>>>
>>> int factorial( int num ); /* Function prototype */
>>>
>>> int main()
>>> {
>>> int result, number;
>>> .
>>> .
>>> .
>>> result = factorial( number );
>>> }
>>>
>>> int factorial( int num ) /* Function definition */
>>> {
>>> .
>>> .
>>> .
>>> if ( ( num > 0 ) || ( num <= 10 ) )
>>> return( num * factorial( num - 1 ) );
>>> }
>>>
>>> Count the bugs. (So much for a reliable source.)
>>>
>>
>> Zero, because your code is neither complete nor compilable. So it is
>> more bullshit.
>
> Not my code. Their code.
>
> <https://msdn.microsoft.com/en-us/library/4bftz997.aspx>
>
OK, so they show partial code to prove a point. I see nothing wrong
with the code as it stands. They are attempting to show recursion, and
are doing so.
> (So are you saying you disagree with the experts at Microsoft?)
>
>
>> So let's see you show even ONE site which agrees with your
>> interpretation - an independent site from a respected resource.
>
> You can't get more independent than ISO/IEC 9899.
>
OK, you posted another link to the standard. That does not answer the
question.
>>>> Can you find three reputable sites who say these are wrong?
>>>
>>> I can find one reputable Standard that says they're wrong.
>>>
>>
>> And that is? It has to be separate from your interpretation of the
>> standard.
>
> So let's see your interpretation of the Standard. If you're right, it
> will be easy to show from the Standard that you're right. (I could show
> how you're wrong, but that would be /my/ interpretation.) Let's see
> /your/ interpretation, with chapter and verse support.
>
I have given you my interpretation of the standard, with links to three
independent reputable sources. I'm not going to try to argue the
standard's syntax with you.
>>
>>>> No, your
>>>> interpretation of the standard does not count.
>>>
>>> What's 1+1? And let's not have any of that nonsense about it being 2.
>>> (FCOL)
>>>
>>
>> So you're saying thousands of experts in the C language are wrong, and
>> you are right.
>
> I'm certainly saying I'm right, yes. And I don't require experts in C to
> agree with /me/ --- I only require them to agree with /the Standard/ (as
> I do). If the Standard says I'm wrong, then I'm wrong. Does the Standard
> say I'm wrong?
>
Thousands of sites say your interpretation of the standard is wrong. I
just linked to three independent, reputable ones. I could give you
thousands more which say the same thing.
>> But you can't provide even one reference from an
>> respected independent source to support your claims.
>
> ISO/IEC 9899.
>
Again, just another link to the standard.
>> I'm glad you think you are more knowledgeable than all of those experts.
>
> I'm certainly more knowledgeable about C than the people who wrote the
> pages you cited (at least in this one respect) --- and that means they
> can't be all that expert after all (at least in this one respect).
>
ROFLMAO! There are thousands of other independent and reputable
organizations which say the same thing. You have some ego to think that
you know more than all of those experts.
Here's a clue - you don't. And now I know why the real C experts left
here and are on their own server. We don't have arguments like this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-27 18:05 -0800 |
| Message-ID | <c9e96a0c-2fd2-4b30-976d-31935295c4b1@googlegroups.com> |
| In reply to | #104989 |
On Monday, February 27, 2017 at 8:18:15 PM UTC-5, Jerry Stuckle wrote: ... > > <https://msdn.microsoft.com/en-us/library/4bftz997.aspx> > > > > OK, so they show partial code to prove a point. I see nothing wrong > with the code as it stands. They are attempting to show recursion, and > are doing so. Did you bother thinking about it? Here's some questions to consider: What is is the value stored in result if number is 11? What result does factorial(0) return? Given that factorial(0) returns that value, and that factorial(1) calls factorial(0), what value does factorial(1) return? Recursing - what value does factorial(10) return? Hint: 6.9.1p12 of the current standard. > > You can't get more independent than ISO/IEC 9899. > > > > OK, you posted another link to the standard. That does not answer the > question. It's the only answer that's relevant. The "authorities" you cite aren't relevant.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 00:02 -0500 |
| Message-ID | <o9304l$baj$2@jstuckle.eternal-september.org> |
| In reply to | #105006 |
On 2/27/2017 9:05 PM, jameskuyper@verizon.net wrote: > On Monday, February 27, 2017 at 8:18:15 PM UTC-5, Jerry Stuckle wrote: > ... >>> <https://msdn.microsoft.com/en-us/library/4bftz997.aspx> >>> >> >> OK, so they show partial code to prove a point. I see nothing wrong >> with the code as it stands. They are attempting to show recursion, and >> are doing so. > > Did you bother thinking about it? Here's some questions to consider: > > What is is the value stored in result if number is 11? > What result does factorial(0) return? > Given that factorial(0) returns that value, and that factorial(1) calls factorial(0), what value does factorial(1) return? > Recursing - what value does factorial(10) return? > All of that is immaterial for the purpose of the example. It is partial code to show recursion. Nothing more. > Hint: 6.9.1p12 of the current standard. > >>> You can't get more independent than ISO/IEC 9899. >>> >> >> OK, you posted another link to the standard. That does not answer the >> question. > > It's the only answer that's relevant. The "authorities" you cite aren't relevant. > The authorities are more relevant than your misinterpretation of the standard. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-27 21:36 +0000 |
| Message-ID | <87efyjs4dv.fsf@bsb.me.uk> |
| In reply to | #104927 |
Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > Here are three reputable organizations who agree with me: They do seem to agree with you, but do you agree with them? (They include errors I've never seen you make.) > Purdue University: https://web.ics.purdue.edu/~cs240/misc/operators.html > University of Hawaii: > https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html I'm surprised you keep quoting these. They are amongst the worst such pages I've seen. I'm sure I've seen pages like this that link precedence with evaluation order but which don't make quite so many other mistakes. > Microsoft: > https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx And this one appears to be about some other language not entirely unlike C. > I can easily find a few hundred more which say the same thing. Sadly true. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 17:32 -0500 |
| Message-ID | <o929ai$jbs$1@jstuckle.eternal-september.org> |
| In reply to | #104939 |
On 2/27/2017 4:36 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >> Here are three reputable organizations who agree with me: > > They do seem to agree with you, but do you agree with them? (They > include errors I've never seen you make.) > >> Purdue University: https://web.ics.purdue.edu/~cs240/misc/operators.html >> University of Hawaii: >> https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html > > I'm surprised you keep quoting these. They are amongst the worst such > pages I've seen. I'm sure I've seen pages like this that link > precedence with evaluation order but which don't make quite so many > other mistakes. > They are completely accurate. You're saying you know more than experts at Purdue University and University of Hawaii? >> Microsoft: >> https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx > > And this one appears to be about some other language not entirely unlike > C. > Yes, wrong link. The correct one is https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx But it says the same thing, because C# was built to the same rules as C. >> I can easily find a few hundred more which say the same thing. > > Sadly true. > Yes, accurate information is available on the internet. Unfortunately, so is information from people who only think they are experts. > <snip> > And you also think you know more than all of these experts. No wonder the real experts in the C language have gone elsewhere. If that is the case, you should be able to find lots of sites which support your claims. Can you provide a link to even ONE respected, independent source that claims the same you do? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-28 01:29 +0000 |
| Message-ID | <87shmzqf0d.fsf@bsb.me.uk> |
| In reply to | #104953 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 2/27/2017 4:36 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> <snip> >>> Here are three reputable organizations who agree with me: >> >> They do seem to agree with you, but do you agree with them? (They >> include errors I've never seen you make.) >> >>> Purdue University: https://web.ics.purdue.edu/~cs240/misc/operators.html >>> University of Hawaii: >>> https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html >> >> I'm surprised you keep quoting these. They are amongst the worst such >> pages I've seen. I'm sure I've seen pages like this that link >> precedence with evaluation order but which don't make quite so many >> other mistakes. > > They are completely accurate. You're saying you know more than experts > at Purdue University and University of Hawaii? Purdue is an excellent institution (I've visited for joint research projects more than once) and I am sure that the University of Hawaii has excellent professors, but I can't see why you think they would know more than me about C -- they might or they might not. I am not a C expert but then very few universities have C experts in them. Anyway, the fact that that page has errors is incontrovertible. Try to work out what it says about sizeof x++ and you'll see. It claims that sizeof is only a C++ operator, and it says nothing about postfix increment. (Either that or it says that both ++ operators are right associative.) And if despite that you work out that the parse is sizeof (x++) (and you take the text literally), you would conclude that the ++ is evaluated before the sizeof. Is it? And what does it mean to evaluate ++ first in this context? But I don't want to be unkind. Someone wrote up a table to help the students and repeated the simplistic and potentially misleading trope about evaluation order. It what time-pressed academics do. I'm sure I've done exactly that in the past myself. But the course "info" pages also reference the comp.lang.c FAQ so the students are getting other sources as well. >>> Microsoft: >>> https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx >> >> And this one appears to be about some other language not entirely unlike >> C. >> > > Yes, wrong link. The correct one is > https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx > > But it says the same thing, because C# was built to the same rules as > C. Is there anything you can't be wrong about? C# explicitly defines the exact order of evaluation of both operands and operators. It's one of the famous *differences* between C and C#. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 00:09 -0500 |
| Message-ID | <o930j4$clr$1@jstuckle.eternal-september.org> |
| In reply to | #104996 |
On 2/27/2017 8:29 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/27/2017 4:36 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> <snip> >>>> Here are three reputable organizations who agree with me: >>> >>> They do seem to agree with you, but do you agree with them? (They >>> include errors I've never seen you make.) >>> >>>> Purdue University: https://web.ics.purdue.edu/~cs240/misc/operators.html >>>> University of Hawaii: >>>> https://ee.hawaii.edu/~tep/EE160/Book/chap5/subsection2.1.4.1.html >>> >>> I'm surprised you keep quoting these. They are amongst the worst such >>> pages I've seen. I'm sure I've seen pages like this that link >>> precedence with evaluation order but which don't make quite so many >>> other mistakes. >> >> They are completely accurate. You're saying you know more than experts >> at Purdue University and University of Hawaii? > > Purdue is an excellent institution (I've visited for joint research > projects more than once) and I am sure that the University of Hawaii has > excellent professors, but I can't see why you think they would know more > than me about C -- they might or they might not. I am not a C expert > but then very few universities have C experts in them. > Actually, I've found a large number of universities have C experts - most of them, in fact. Those in the upper echelons of computer science don't get there without that knowledge. > Anyway, the fact that that page has errors is incontrovertible. Try to > work out what it says about > > sizeof x++ > > and you'll see. It claims that sizeof is only a C++ operator, and it > says nothing about postfix increment. (Either that or it says that both > ++ operators are right associative.) And if despite that you work out > that the parse is > Actually, I agree with you. It looks like an error in the building of the page. They changed the font color one operator too soon. > sizeof (x++) > > (and you take the text literally), you would conclude that the ++ is > evaluated before the sizeof. Is it? And what does it mean to evaluate > ++ first in this context? > In this context it is immaterial which would be evaluated first, because ++ does not change the size of the object. However, the increment operator would be evaluated first, according to the rules. Compiler optimization could change that, though, because the order is immaterial. > But I don't want to be unkind. Someone wrote up a table to help the > students and repeated the simplistic and potentially misleading trope > about evaluation order. It what time-pressed academics do. I'm sure > I've done exactly that in the past myself. But the course "info" pages > also reference the comp.lang.c FAQ so the students are getting other > sources as well. > This is more than "a table to help the students...". It is part of their public site. And being public, it was peer-reviewed before being published. It looks like the problem with sizeof was caused by the person who actually keyed in the page and wasn't caught. >>>> Microsoft: >>>> https://msdn.microsoft.com/en-us/library/aa691323(v=vs.71).aspx >>> >>> And this one appears to be about some other language not entirely unlike >>> C. >>> >> >> Yes, wrong link. The correct one is >> https://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx >> >> But it says the same thing, because C# was built to the same rules as >> C. > > Is there anything you can't be wrong about? C# explicitly defines the > exact order of evaluation of both operands and operators. It's one of > the famous *differences* between C and C#. > > <snip> > And I gave a link to the correct page, also. But you didn't look at that, did you? Hint: it says basically the same thing as the C# page does because C# is just Microsoft's version of C. -- ================== 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-28 05:22 +0000 |
| Message-ID | <o931an$e86$1@dont-email.me> |
| In reply to | #105032 |
On 28/02/17 05:09, Jerry Stuckle wrote: <snip> > This is more than "a table to help the students...". It is part of > their public site. And being public, it was peer-reviewed before being > published. It looks like the problem with sizeof was caused by the > person who actually keyed in the page and wasn't caught. You see, they /can/ make mistakes. Now, a quick question for you. Since these Universities are normally so careful, would I be right in saying that they exercise great care in selecting external sites that offer further advice on C? For example, if a reliable, reputable, respected University's reliable, reputable, respected and peer-reviewed C pages cite <X> as being a usefull [sic] document, would you consider <X> to be a reliable, reputable, respected, peer-reviewed site? -- 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]
Page 24 of 27 — ← Prev page 1 … 22 23 [24] 25 26 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web