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 23 of 27 — ← Prev page 1 … 21 22 [23] 24 25 … 27 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-28 00:01 +0000 |
| Message-ID | <o92egm$7qp$1@dont-email.me> |
| In reply to | #104957 |
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". <snip> -- 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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-27 19:23 -0500 |
| Message-ID | <2d034aad-6974-22aa-5379-f3716ec4e812@verizon.net> |
| In reply to | #104970 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-27 20:05 -0500 |
| Message-ID | <o92i89$h3i$3@jstuckle.eternal-september.org> |
| In reply to | #104976 |
On 2/27/2017 7:23 PM, 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. > Nope. The order in which operands are evaluated is undefined. Evaluating the operator and evaluating the operand are two entirely different things. You don't even understand the difference between an operator and an operand. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-27 17:51 -0800 |
| Message-ID | <2c20f29b-9464-4052-84cc-f83d2f0b1b76@googlegroups.com> |
| In reply to | #104985 |
On Monday, February 27, 2017 at 8:05:08 PM UTC-5, Jerry Stuckle wrote: > On 2/27/2017 7:23 PM, James R. Kuyper wrote: ... > > 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. > > > > Nope. The order in which operands are evaluated is undefined. The term used by the current standard is "unsequenced" - this is important because it's distinct from "indeterminately sequenced". Indeterminately sequenced evaluations can be interleaved with each other. Unsequenced evaluations cannot. Older versions of the standard used "unspecified", not "undefined". The difference is important. > Evaluating the operator and evaluating the operand are two entirely > different things. True: "evaluating the operator" is a meaningless concept that occurs nowhere in the C standard. > You don't even understand the difference between an operator and an > operand. In the following expression: (a=b) && a++ The relevant operators are =, &&, and ++. It is absolutely meaningless to talk about evaluating any of them. The operands of the assignment operator are 'a' and 'b'. The assignment expression cannot start being evaluated until both of those operands have been evaluated. Evaluating 'b' means retrieving the value stored in that object. Evaluating 'a' means determining the location of 'a' for purposes of storing a new value in it. The two operands of && operator are a=b and a++. Evaluation of the logical-AND expression cannot start until the left operand has been evaluated; if that operand has a non-zero result, evaluation of the logical-AND expression cannot complete until the right operand has been evaluated. Evaluating the assignment expression means taking the value stored in b and converting it to the type of a. That converted value is the value of the assignment expression. There is also a side-effect, namely updating the value stored in 'a' - but that side-effect need not occur at the same time as the evaluation. It must, however, be completed before reaching the sequence point associate with the && operator. Evaluating the && operator requires first using the result of it's left operand, the assignment expression, and checking whether it's 0. If not, it then involves evaluating the right operand, the postfix-increment expression. Finally, a value is determined based upon the results of those two expressions. The only operand of the postfix-increment operator is 'a'. Since 'a' is both the source and destination for this operator, evaluating it means both retrieving the value currently stored in it, and determining it's location for the purpose of storing a new value in it. This must be complete before the postfix-increment expression can be evaluated. Evaluating the postfix-increment expression involves nothing more than using the value that was stored in a as it's result. There's also a side-effect in the form of incrementing that value and storing the incremented value back in 'a', but that side-effect need not occur at the same time as the evaluation. It is only constrained to occur at some time after the sequence point associated with the && operator.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 00:00 -0500 |
| Message-ID | <o9300i$baj$1@jstuckle.eternal-september.org> |
| In reply to | #105004 |
On 2/27/2017 8:51 PM, jameskuyper@verizon.net wrote: > On Monday, February 27, 2017 at 8:05:08 PM UTC-5, Jerry Stuckle wrote: >> On 2/27/2017 7:23 PM, James R. Kuyper wrote: > ... >>> 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. >>> >> >> Nope. The order in which operands are evaluated is undefined. > > The term used by the current standard is "unsequenced" - this is important > because it's distinct from "indeterminately sequenced". Indeterminately > sequenced evaluations can be interleaved with each other. Unsequenced > evaluations cannot. > I don't care what words you use. The plain English is that the order of operand evaluation (with limited exceptions) is undefined. > Older versions of the standard used "unspecified", not "undefined". The > difference is important. > And exactly how is the difference important? Does one mean you can guarantee the order of operand evaluation and the other not? This is one of the big problems with you and others in this newsgroup. You get so caught up in the details of the standard that you don't understand what the standard says. >> Evaluating the operator and evaluating the operand are two entirely >> different things. > > True: "evaluating the operator" is a meaningless concept that occurs > nowhere in the C standard. > See above. And "evaluating the operator" is generally accepted terminology for evaluating the expression containing that operator. >> You don't even understand the difference between an operator and an >> operand. > > In the following expression: (a=b) && a++ The relevant operators are =, > &&, and ++. It is absolutely meaningless to talk about evaluating any of > them. > Sure it is. Evaluating the = operator assigns the contents of b in to a. The postfix increment operator increments a. And the && operator evaluates a++ if the new contents of a is non-zero and ANDs that to a. You forgot one other operator. () causes the expression within it to be evaluated before the other expressions. > The operands of the assignment operator are 'a' and 'b'. The assignment > expression cannot start being evaluated until both of those operands have > been evaluated. > True. But whether a or b is evaluated first is undefined. > Evaluating 'b' means retrieving the value stored in that object. > Evaluating 'a' means determining the location of 'a' for purposes of > storing a new value in it. > See above. > The two operands of && operator are a=b and a++. Evaluation of the > logical-AND expression cannot start until the left operand has been > evaluated; if that operand has a non-zero result, evaluation of the > logical-AND expression cannot complete until the right operand has been > evaluated. > True. Logical AND and OR operators and the comma operator are exceptions in that the left hand operand is always evaluated first. > Evaluating the assignment expression means taking the value stored in b > and converting it to the type of a. That converted value is the value of > the assignment expression. There is also a side-effect, namely updating > the value stored in 'a' - but that side-effect need not occur at the same > time as the evaluation. It must, however, be completed before reaching the > sequence point associate with the && operator. > Actually, due to the parens, it must be completed before the && operator. > Evaluating the && operator requires first using the result of it's left > operand, the assignment expression, and checking whether it's 0. If not, > it then involves evaluating the right operand, the postfix-increment > expression. Finally, a value is determined based upon the results of those > two expressions. > True. > The only operand of the postfix-increment operator is 'a'. Since 'a' is > both the source and destination for this operator, evaluating it means > both retrieving the value currently stored in it, and determining it's > location for the purpose of storing a new value in it. This must be > complete before the postfix-increment expression can be evaluated. > Yes, it is part of the evaluation of the operator. > Evaluating the postfix-increment expression involves nothing more than > using the value that was stored in a as it's result. There's also a > side-effect in the form of incrementing that value and storing the > incremented value back in 'a', but that side-effect need not occur at the > same time as the evaluation. It is only constrained to occur at some time > after the sequence point associated with the && operator. > That is not a side effect. But it does have to be completed before the && operator can be evaluated. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-28 09:23 -0800 |
| Message-ID | <4cbd84f5-8049-45b0-95e7-4fd58a0ca410@googlegroups.com> |
| In reply to | #105030 |
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: > > On Monday, February 27, 2017 at 8:05:08 PM UTC-5, Jerry Stuckle wrote: > >> On 2/27/2017 7:23 PM, James R. Kuyper wrote: ... > > In the following expression: (a=b) && a++ The relevant operators are =, ... > > the assignment expression. There is also a side-effect, namely updating > > the value stored in 'a' - but that side-effect need not occur at the same > > time as the evaluation. It must, however, be completed before reaching the > > sequence point associate with the && operator. > > > > Actually, due to the parens, it must be completed before the && operator. Incorrect - there's no sequence point associated with the parentheses, so the side-effect can be delayed past the evaluation of the parenthesized expression. There's no actual activities associated with a parenthesized expression, so that would be a meaningless delay, but for other kinds of expressions that don't have sequence points (which is most of them), the distinction could matter. ... > > Evaluating the postfix-increment expression involves nothing more than > > using the value that was stored in a as it's result. There's also a > > side-effect in the form of incrementing that value and storing the > > incremented value back in 'a', but that side-effect need not occur at the > > same time as the evaluation. It is only constrained to occur at some time > > after the sequence point associated with the && operator. > > > > 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. The only constraint the standard places on the sequencing of side-effects is that "The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B." (5.1.2.3p3). C programs have lots of sequence points, but your typical C expression has very few. I think you suffer from a common misconception, that is equivalent to believing that there are sequence points separating every pair of C expressions; I say "equivalent to", because that misconception is sustainable only by someone who's ignorant of sequence points, so they would never use the term "sequence point" when describing that belief. > But it does have to be completed before the > && operator can be evaluated. No, it doesn't. It doesn't have to be completed until the following sequence point. The only sequence point associated with a logical-AND expression is the one separating the evaluation of the left operand from the evaluation of the right operand, and this is the right operand we're talking about, so we're already past that sequence point by the time this side-effect occurs. There's a sequence point after each full-expression, so if this is a full-expression (I didn't say one way or the other), then the modification to 'a' could not be delayed past that point, but it can be delayed past the end of the evaluation of the logical-AND expression.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 13:32 -0500 |
| Message-ID | <o94fk2$8c4$1@jstuckle.eternal-september.org> |
| In reply to | #105115 |
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: >>> On Monday, February 27, 2017 at 8:05:08 PM UTC-5, Jerry Stuckle wrote: >>>> On 2/27/2017 7:23 PM, James R. Kuyper wrote: > ... >>> In the following expression: (a=b) && a++ The relevant operators are =, > ... >>> the assignment expression. There is also a side-effect, namely updating >>> the value stored in 'a' - but that side-effect need not occur at the same >>> time as the evaluation. It must, however, be completed before reaching the >>> sequence point associate with the && operator. >>> >> >> Actually, due to the parens, it must be completed before the && operator. > > Incorrect - there's no sequence point associated with the parentheses, so the > side-effect can be delayed past the evaluation of the parenthesized expression. > There's no actual activities associated with a parenthesized expression, so > that would be a meaningless delay, but for other kinds of expressions that > don't have sequence points (which is most of them), the distinction could > matter. > Parens are not required for sizeof - although many people use them. And the parens elevate the precedence of the expression within them. > ... >>> Evaluating the postfix-increment expression involves nothing more than >>> using the value that was stored in a as it's result. There's also a >>> side-effect in the form of incrementing that value and storing the >>> incremented value back in 'a', but that side-effect need not occur at the >>> same time as the evaluation. It is only constrained to occur at some time >>> after the sequence point associated with the && operator. >>> >> >> 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. 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 only constraint the standard places on the sequencing of side-effects is > that "The presence of a sequence point between the evaluation of expressions A > and B implies that every value computation and side effect associated with A is > sequenced before every value computation and side effect associated with B." > (5.1.2.3p3). C programs have lots of sequence points, but your typical C > expression has very few. I think you suffer from a common misconception, that > is equivalent to believing that there are sequence points separating every pair > of C expressions; I say "equivalent to", because that misconception is > sustainable only by someone who's ignorant of sequence points, so they would > never use the term "sequence point" when describing that belief. > >> But it does have to be completed before the >> && operator can be evaluated. > > No, it doesn't. It doesn't have to be completed until the following sequence > point. The only sequence point associated with a logical-AND expression is the > one separating the evaluation of the left operand from the evaluation of the > right operand, and this is the right operand we're talking about, so we're > already past that sequence point by the time this side-effect occurs. There's a > sequence point after each full-expression, so if this is a full-expression (I > didn't say one way or the other), then the modification to 'a' could not be > delayed past that point, but it can be delayed past the end of the evaluation > of the logical-AND expression. > Whatever you want to say. It doesn't matter, because sizeof is evaluated at compile time, anyway. So there is no runtime evaluation of it. -- ================== 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 07:36 +1300 |
| Message-ID | <ehlu8pF60pU1@mid.individual.net> |
| In reply to | #105134 |
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? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-28 15:43 -0500 |
| Message-ID | <o94n9s$4g2$4@jstuckle.eternal-september.org> |
| In reply to | #105137 |
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. And yes, I am aware of when the parens (not brackets - two different characters) are required. They were not here, which is the point I was addressing. -- ================== 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 21:21 +0000 |
| Message-ID | <o94php$c8r$4@dont-email.me> |
| In reply to | #105162 |
On 28/02/17 20:43, 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.
Not when it is the operand of sizeof.
#include <stdio.h>
int main(void)
{
int x = 0;
size_t y = sizeof x++;
printf("%d\n", x);
return 0;
}
Try it and see for yourself.
Now add parentheses around x++ and try it again.
What have you learned? Anything?
--
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-03-01 11:39 -0500 |
| Message-ID | <o96tcu$s7a$1@jstuckle.eternal-september.org> |
| In reply to | #105175 |
On 2/28/2017 4:21 PM, Richard Heathfield wrote:
> On 28/02/17 20:43, 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.
>
> Not when it is the operand of sizeof.
>
> #include <stdio.h>
>
> int main(void)
> {
> int x = 0;
> size_t y = sizeof x++;
> printf("%d\n", x);
> return 0;
> }
>
> Try it and see for yourself.
>
> Now add parentheses around x++ and try it again.
>
> What have you learned? Anything?
>
That is interesting, and I learned something today. I didn't realize
that was the case, mainly because it is defined under 6.7.6.2(5) - Array
declarators. Whether it is evaluated or not is unspecified.
Strange place to put it, though.
--
==================
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-03-01 16:56 +0000 |
| Message-ID | <o96ubt$vuk$1@dont-email.me> |
| In reply to | #105269 |
On 01/03/17 16:39, Jerry Stuckle wrote:
> On 2/28/2017 4:21 PM, Richard Heathfield wrote:
>> On 28/02/17 20:43, 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.
>>
>> Not when it is the operand of sizeof.
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> int x = 0;
>> size_t y = sizeof x++;
>> printf("%d\n", x);
>> return 0;
>> }
>>
>> Try it and see for yourself.
>>
>> Now add parentheses around x++ and try it again.
>>
>> What have you learned? Anything?
>>
>
> That is interesting, and I learned something today.
Good. That's a start.
> I didn't realize
> that was the case, mainly because it is defined under 6.7.6.2(5) - Array
> declarators. Whether it is evaluated or not is unspecified.
Mostly it's well-defined (but see below regarding the rather odd
exception in 6.7.6.2(5)). The right place to look for information about
sizeof is 6.5.3.4 and, in this case, specifically 6.5.3.4(2), which says
"If the type of the operand is a variable length array type, the operand
is evaluated; otherwise, the operand is not evaluated and the result is
an integer constant."
What 6.7.6.2(5) says is this:
If the size is an expression that is not an integer constant expression:
if it occurs in a declaration at function prototype scope, it is treated
as if it were replaced by *; otherwise, each time it is evaluated it
shall have a value greater than zero. The size of each instance of a
variable length array type does not change during its lifetime. Where a
size expression is part of the operand of a sizeof operator and changing
the value of the size expression would not affect the result of the
operator, it is unspecified whether or not
the size expression is evaluated.
The meaning of the last sentence is not even remotely clear to me, but
then I don't use VLAs, so I haven't yet had a need to decode it.
> Strange place to put it, though.
Well, it was a strange place to look.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-01 09:12 -0800 |
| Message-ID | <99765079-fb26-4b25-b146-94d3de89339c@googlegroups.com> |
| In reply to | #105276 |
On Wednesday, March 1, 2017 at 10:56:25 AM UTC-6, Richard Heathfield wrote: > Where a > size expression is part of the operand of a sizeof operator and changing > the value of the size expression would not affect the result of the > operator, it is unspecified whether or not > the size expression is evaluated. > > The meaning of the last sentence is not even remotely clear to me, but > then I don't use VLAs, so I haven't yet had a need to decode it. Consider a type like "int (*)[f()][g()]", which is an array of g() pointers to arrays of size f(). The size of that array will be the same as the size of an array of g() pointers to "int", regardless of the value of f(). What the Standard is saying is that a compiler may at its leisure either evaluate f() and ignore the result, or forego such evaluation altogether. Because C99 had mandated evaluation of f(), the authors of C11 didn't want to forbid compilers from doing so, but they saw no reason to require that compilers evaluate such an expression if they weren't going to use the result.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-01 19:07 +0100 |
| Message-ID | <o972h7$g6g$1@dont-email.me> |
| In reply to | #105283 |
On 01/03/17 18:12, supercat@casperkitty.com wrote: > On Wednesday, March 1, 2017 at 10:56:25 AM UTC-6, Richard Heathfield wrote: >> Where a >> size expression is part of the operand of a sizeof operator and changing >> the value of the size expression would not affect the result of the >> operator, it is unspecified whether or not >> the size expression is evaluated. >> >> The meaning of the last sentence is not even remotely clear to me, but >> then I don't use VLAs, so I haven't yet had a need to decode it. > > Consider a type like "int (*)[f()][g()]", which is an array of g() pointers > to arrays of size f(). The size of that array will be the same as the size > of an array of g() pointers to "int", regardless of the value of f(). What > the Standard is saying is that a compiler may at its leisure either evaluate > f() and ignore the result, or forego such evaluation altogether. Because C99 > had mandated evaluation of f(), the authors of C11 didn't want to forbid > compilers from doing so, but they saw no reason to require that compilers > evaluate such an expression if they weren't going to use the result. > Thank you. I had also wondered about the meaning of that sentence (I do occasionally use VLAs, but I limit them to comprehensible ones like "const int size = foo(); char buffer[size];" ) Frankly, I would much rather /not/ consider a type like you suggest, but that does give an explanation for what the standard is saying here.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-30 08:34 -0700 |
| Message-ID | <kfnshkp29ka.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #105283 |
supercat@casperkitty.com writes: > Consider a type like "int (*)[f()][g()]", which is an array of > g() pointers to arrays of size f(). No, it isn't.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-01 18:00 +0100 |
| Message-ID | <o96uir$v2$1@dont-email.me> |
| In reply to | #105269 |
On 01/03/17 17:39, Jerry Stuckle wrote:
> On 2/28/2017 4:21 PM, Richard Heathfield wrote:
>> On 28/02/17 20:43, 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.
>>
>> Not when it is the operand of sizeof.
>>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> int x = 0;
>> size_t y = sizeof x++;
>> printf("%d\n", x);
>> return 0;
>> }
>>
>> Try it and see for yourself.
>>
>> Now add parentheses around x++ and try it again.
>>
>> What have you learned? Anything?
>>
>
> That is interesting, and I learned something today. I didn't realize
> that was the case, mainly because it is defined under 6.7.6.2(5) - Array
> declarators. Whether it is evaluated or not is unspecified.
>
> Strange place to put it, though.
>
It is under ยง6.5.3.4p2, at least in the C11 standards:
> The sizeof operator yields the size (in bytes) of its operand, which
> may be an expression or the parenthesized name of a type. The size is
> determined from the type of the operand. The result is an integer. If
> the type of the operand is a variable length array type, the operand
> is evaluated; otherwise, the operand is not evaluated and the result
> is an integer constant.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-01 09:49 -0800 |
| Message-ID | <8237c464-7a18-4b1c-910c-decdc6814b2d@googlegroups.com> |
| In reply to | #105269 |
On Wednesday, March 1, 2017 at 11:40:00 AM UTC-5, Jerry Stuckle wrote:
> On 2/28/2017 4:21 PM, Richard Heathfield wrote:
...
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > int x = 0;
> > size_t y = sizeof x++;
> > printf("%d\n", x);
> > return 0;
> > }
> >
> > Try it and see for yourself.
> >
> > Now add parentheses around x++ and try it again.
> >
> > What have you learned? Anything?
> >
> That is interesting, and I learned something today. I didn't realize
> that was the case, mainly because it is defined under 6.7.6.2(5) - Array
> declarators. Whether it is evaluated or not is unspecified.
6.7.6.2p5 is specifically for the case of arrays declared with a size that "is an expression that is not an integer constant expression". It says that "it is unspecified whether or not the size expression is evaluated." In x++, x cannot have an array type, much less a VLA type, and it certainly does not have an array type in Richard's example code. Here's an example where 6.7.6.2p5 would be relevant:
int vla[count++];
size_t size = sizeof vla;
In this case, the "size expression" that it's referring to is "count++". What 6.7.6.2p5 is saying is that it's unspecified whether count++ gets evaluated as a result of the sizeof.
That misunderstanding is repeated in several of your other messages - I won't go into any detail about it in any of the other messages. I'll just refer you to 6.5.3.4p2, the section that's actually relevant.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-16 20:52 -0700 |
| Message-ID | <kfno9vv7ksw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #105288 |
jameskuyper@verizon.net writes:
> [.. under what circumstances are operands of sizeof evaluated? ..]
>
> 6.7.6.2p5 is specifically for the case of arrays declared with a size
> that "is an expression that is not an integer constant expression".
> It says that "it is unspecified whether or not the size expression is
> evaluated." [...] Here's an example where 6.7.6.2p5 would be relevant:
>
> int vla[count++];
> size_t size = sizeof vla;
>
> In this case, the "size expression" that its referring to is
> "count++". What 6.7.6.2p5 is saying is that its unspecified whether
> count++ gets evaluated as a result of the sizeof.
That statement is wrong, for two different reasons. Here is the
relevant excerpt from 6.7.6.2 p5:
Where a size expression is part of the operand of a sizeof
operator and changing the value of the size expression would
not affect the result of the operator, it is unspecified
whether or not the size expression is evaluated.
The reasons are: one, the size expression is not /part of/ the
operand of a sizeof operator; and two, changing the value of the
of the size expression certainly /would/ affect the result of the
sizeof.
In fact, the size expression (ie, 'count++') must not be evaluated
when the 'sizeof' is done; this expression already was evaluated,
as part of the declaration for 'vla'. The 'sizeof' is reached
after an intervening sequence point, and must compute a size for
an int array whose extent is the value of 'count' before the ++
was done.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-01 14:26 +1300 |
| Message-ID | <ehmma6F60pU2@mid.individual.net> |
| In reply to | #105162 |
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. > And yes, I am aware of when the parens (not brackets - two different > characters) are required. The name depends on which side of Trump's wall you happen to have been born. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-01 11:40 -0500 |
| Message-ID | <o96tee$s7a$2@jstuckle.eternal-september.org> |
| In reply to | #105198 |
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. >> And yes, I am aware of when the parens (not brackets - two different >> characters) are required. > > The name depends on which side of Trump's wall you happen to have been > born. > The right side. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 23 of 27 — ← Prev page 1 … 21 22 [23] 24 25 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web