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 12 of 27 — ← Prev page 1 … 10 11 [12] 13 14 … 27 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-17 12:32 -0700 |
| Message-ID | <ad8c19fe-7342-4eda-946c-ac260d3f92d2@googlegroups.com> |
| In reply to | #108238 |
On Monday, April 17, 2017 at 1:56:53 PM UTC-5, Tim Rentsch wrote: > To my way of thinking a better question is Why do you think > they /should/ be constraint violations? Or to say that a bit > differently, what reasons might you offer that would convince > other (presumably skeptical) people they should be constraint > violations? FWIW I myself am on the side of undefined > behavior. The Standard does not recognize a category of constructs which implementations would be free to accept or not, but which would have defined behavior if accepted. Clearly programs using such constructs will not be portable to platforms that cannot support them, but non- portability is not in and of itself a defect. To say that a construct represented a constraint violation would imply that code using it was defective; by contrast, saying that it invokes UB would merely say that code using it was non-portable. A quality implementation should either process such constructs so as to yield the obvious behavior (e.g. making a [] access to a register-qualified array work like an array access, while possibly using the register qualifier as an indication that the array would not be accessed except via the [] operator) or else reject code which uses them. The Standard may not forbid an implementation from using such constructs as an excuse to launch nasal demons, but that doesn't mean that such behavior would be appropriate in a quality implementation.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-26 14:36 -0800 |
| Message-ID | <6315a499-460e-4737-b872-48b4dcc97f17@googlegroups.com> |
| In reply to | #104776 |
On Sunday, February 26, 2017 at 12:06:20 PM UTC-6, Tim Rentsch wrote: > Now let's look at N1256 section 6.3.2.1 paragraph 2. Here we > have another case of undefined behavior, namely, when there is an > lvalue-to-value conversion with the lvalue being of incomplete > type. Does the Standard make any distinction between constructs which may at an implementations' leisure prevent a program from executing whether or not any input would cause them to be reached, versus those which should not affect the behavior of a program except when inputs are received that would cause execution to reach them?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-04-30 08:30 -0700 |
| Message-ID | <kfnwpa129rq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104793 |
supercat@casperkitty.com writes: > On Sunday, February 26, 2017 at 12:06:20 PM UTC-6, Tim Rentsch wrote: >> Now let's look at N1256 section 6.3.2.1 paragraph 2. Here we >> have another case of undefined behavior, namely, when there is an >> lvalue-to-value conversion with the lvalue being of incomplete >> type. > > Does the Standard make any distinction between constructs which may at an > implementations' leisure prevent a program from executing whether or not > any input would cause them to be reached, versus those which should not > affect the behavior of a program except when inputs are received that would > cause execution to reach them? After giving the matter a fair bit of thought, I've decided to adopt a policy of not responding to your postings when I get the impression you aren't really interested in what I have to say.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-01 09:34 -0700 |
| Message-ID | <96f574fa-45aa-4a9d-901c-7dd43edc0342@googlegroups.com> |
| In reply to | #108773 |
On Sunday, April 30, 2017 at 10:30:24 AM UTC-5, Tim Rentsch wrote:
> supercat writes:
>
> > On Sunday, February 26, 2017 at 12:06:20 PM UTC-6, Tim Rentsch wrote:
> >> Now let's look at N1256 section 6.3.2.1 paragraph 2. Here we
> >> have another case of undefined behavior, namely, when there is an
> >> lvalue-to-value conversion with the lvalue being of incomplete
> >> type.
> >
> > Does the Standard make any distinction between constructs which may at an
> > implementations' leisure prevent a program from executing whether or not
> > any input would cause them to be reached, versus those which should not
> > affect the behavior of a program except when inputs are received that would
> > cause execution to reach them?
>
> After giving the matter a fair bit of thought, I've decided
> to adopt a policy of not responding to your postings when
> I get the impression you aren't really interested in what I
> have to say.
Perhaps I was unclear why my question was relevant to your statement. You
note that an lvalue-to-lvalue conversion of incomplete type is Undefined
Behavior. I would expect that was written to avoid suggesting that all
implementations must demand that complete structure definitions be available
when code declares or assigns structure objects, *even if they could process
the code usefully without them*, but at the same time avoid mandating
support for a feature that would only be practical on a minority of
applications.
My question is whether there is any distinction made between situations
where a piece of code which does not violate any constraints and is never
executed may legitimately prevent any part of a program from running. I.e.
is there anything that would suggest that an implementation should be
required to output "Hello world!" if given:
#include <stdio.h>
int foo(int x, int y) { x &= 1; y &= 2; x &= y; return 1/x; }
int main(void) { return printf("Hello world!\n"); }
but not:
#include <stdio.h>
void foo(struct s *p, struct s *q) { *p = *q; }
int main(void) { return printf("Hello world!\n"); }
Common practice seems to be to accept the first but not the second; is there
anything in the Standard that would imply that implementations must process
the first, but would not be required to process the second?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-19 15:54 -0800 |
| Message-ID | <lnr32tn3da.fsf@kst-u.example.com> |
| In reply to | #104230 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> (x,C) is invalid because x and C are of integer and pointer type,
>> respectively.
>
> I don't follow this. (x,C) is a comma expression and looks valid to me.
You're right. (I was thinking of the requirements on the 2nd and 3rd
operands of the ?: operator.)
[...]
>> I believe that an array member of a function call of struct type is the
>> *only* case where it's possible to have an array expression that's not
>> an lvalue in C90. In C90, the array-to-pointer conversion rules
>> implicitly assumed that the array expression refers to an array object
>> (to whose initial element the resulting pointer points). To fix that
>> oversight, C99 introduced objects of *temporary lifetime*, so now
>> there's an object for the resulting pointer to point to.
>
> (I think you mean C11.)
Right again.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-23 13:02 -0800 |
| Message-ID | <kfn1suovcw6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104224 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 19/02/2017 03:20, Keith Thompson wrote:
>>>
>>>> struct {int a, C[10];} S;
>>>> sizeof S.C
>>>>
>>>> is actually quite straightforward. `S.C` is an expression of
>>>> array type. Since that expression is the operand of `sizeof`, it
>>>> is not converted to a pointer expression. (`C` by itself is not an
>>>> expression at all.)
>>>
>>> Given:
>>>
>>> int A[10], B[10], C[10], D[10][6], x,i,j;
>>>
>>> aren't (A,B,C) and (x?B?C) and D[i] expressions of array type too?
>>
>> There is certainly some problem here although I'm not sure where the
>> problem lies. S.C is usually thought of an expression with array type
>> (as are B and C in the declaration above), but it can't be that simple
>> or (x?B:C) would be illegal because array types are not allowed in the
>> second and third operand positions of ?:
>
> No, there's not really a problem.
>
> Given the declarations above, S.C is an expression of array type. It
> may or may not decay to a pointer expression, depending on its context.
>
> In (x?B:C), B and C are array expressions, and they decay to pointer
> expressions (since the ?: operator is neither sizeof nor &).
>
>> Maybe when the standard talks about the type of an expression it
>> normally refers to the type after the array-to-pointer conversion -- a
>> conversion that sizeof suppresses.
>
> Yes. The fact that array-to-pointer decay is described using the word
> "converted" might be a bit confusing. In the expression (x?B:C), the
> subexpression B *is* an expression of pointer type. The "conversion"
> ("adjustment" might have been a better word) happens at compile time.
To me "conversion" seems okay because there is conceptually a
conversion of sorts. In all (allowed) cases where array conversion
happens, the array has an address of sorts (even if the expression
isn't an lvalue), which we might call an "array locator". The
Standard says the array _expression_ is converted, but that isn't
right exactly - the expression stays the same, what changes is how
the expression is interpreted (eg, its type). Part of that change
is to convert the "array locator" into a pointer value. Of course
the "conversion" is effected at compile time, but that isn't all
that different from other optimizations.
To be clear, I'm not claiming any sort of "truth" to my comments,
only that it's a way of thinking about it, and I find that point of
view helpful on occasion. Needless to say YMMV.
> I believe that an array member of a function call of struct type is the
> *only* case where it's possible to have an array expression that's not
> an lvalue in C90. [...]
Do you? I count three others. Didn't we talk about this before?
I seem to recall that we did, but then I don't always remember when
I might have forgotten something.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-23 14:53 -0800 |
| Message-ID | <lnr32oiknq.fsf@kst-u.example.com> |
| In reply to | #104530 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> Yes. The fact that array-to-pointer decay is described using the word
>> "converted" might be a bit confusing. In the expression (x?B:C), the
>> subexpression B *is* an expression of pointer type. The "conversion"
>> ("adjustment" might have been a better word) happens at compile time.
>
> To me "conversion" seems okay because there is conceptually a
> conversion of sorts. In all (allowed) cases where array conversion
> happens, the array has an address of sorts (even if the expression
> isn't an lvalue), which we might call an "array locator". The
> Standard says the array _expression_ is converted, but that isn't
> right exactly - the expression stays the same, what changes is how
> the expression is interpreted (eg, its type). Part of that change
> is to convert the "array locator" into a pointer value. Of course
> the "conversion" is effected at compile time, but that isn't all
> that different from other optimizations.
>
> To be clear, I'm not claiming any sort of "truth" to my comments,
> only that it's a way of thinking about it, and I find that point of
> view helpful on occasion. Needless to say YMMV.
Taking a concrete example:
int arr[5];
int *ptr = arr;
The expression `arr`, if you initially ignore the context in which it
appears, is an array expression (i.e., an expression of array type).
That expression is "converted" to a pointer expression (6.3.2.1p1).
The kind of conversion specified by a cast operator is a conversion
of a *value* to some type. The result of this "conversion" is
not a value, but an expression. After this conversion is applied,
`arr` is a pointer expression. (The standard is *slightly* sloppy
in saying that the expression "points to" the initial element of
the array object, rather than that the value that results from
evaluating the expression points to that object, but I consider
that an acceptable verbal shorthand.)
I suspect that at least some people have been misled by the word
"conversion" to assume that this tranformation is, at least
logically, a run-time operation.
I consider "adjusted" to be a clearer description of the compile-time
operation being described. It would also be consistent with the
use of "adjusted" in 6.7.6.3, describing the transformation of
array parameters to pointer parameters.
It's not a huge deal, and the current usage is within a reasonable
interpretation of the English word "converted", but I find the
suggestion to use the word "adjusted" useful in understanding what's
really going on.
>> I believe that an array member of a function call of struct type is the
>> *only* case where it's possible to have an array expression that's not
>> an lvalue in C90. [...]
>
> Do you? I count three others. Didn't we talk about this before?
> I seem to recall that we did, but then I don't always remember when
> I might have forgotten something.
We may have, but I don't remember. What are the other cases?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-25 18:33 -0800 |
| Message-ID | <kfnfuj1r88d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104545 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> Yes. The fact that array-to-pointer decay is described using the word
>>> "converted" might be a bit confusing. In the expression (x?B:C), the
>>> subexpression B *is* an expression of pointer type. The "conversion"
>>> ("adjustment" might have been a better word) happens at compile time.
>>
>> To me "conversion" seems okay because there is conceptually a
>> conversion of sorts. In all (allowed) cases where array conversion
>> happens, the array has an address of sorts (even if the expression
>> isn't an lvalue), which we might call an "array locator". The
>> Standard says the array _expression_ is converted, but that isn't
>> right exactly - the expression stays the same, what changes is how
>> the expression is interpreted (eg, its type). Part of that change
>> is to convert the "array locator" into a pointer value. Of course
>> the "conversion" is effected at compile time, but that isn't all
>> that different from other optimizations.
>>
>> To be clear, I'm not claiming any sort of "truth" to my comments,
>> only that it's a way of thinking about it, and I find that point of
>> view helpful on occasion. Needless to say YMMV.
>
> Taking a concrete example:
>
> int arr[5];
> int *ptr = arr;
>
> The expression `arr`, if you initially ignore the context in which it
> appears, is an array expression (i.e., an expression of array type).
> That expression is "converted" to a pointer expression (6.3.2.1p1).
> The kind of conversion specified by a cast operator is a conversion
> of a *value* to some type. The result of this "conversion" is
> not a value, but an expression. After this conversion is applied,
> `arr` is a pointer expression. (The standard is *slightly* sloppy
> in saying that the expression "points to" the initial element of
> the array object, rather than that the value that results from
> evaluating the expression points to that object, but I consider
> that an acceptable verbal shorthand.)
I need to raise a small objection here (not to your comments, but
about the Standard). The wording used in the Standard says the
expression is converted, but the expression -- `arr` -- actually
is the same both before and after. What _is_ different is some
sort of derived property, or we might say the derived property is
different when the expression is considered in isolation, as
compared with when the expression is considered in its context in
the program. Furthermore the ultimate result of an array
conversion is a value (ie a pointer value), which might not
already be present in the runtime state and so may require some
computation to be generated.
> I suspect that at least some people have been misled by the word
> "conversion" to assume that this tranformation is, at least
> logically, a run-time operation.
Almost certainly true, although I don't think much harm occurs as
a result. Also it isn't completely wrong, since the pointer
value does need to be produced, and sometimes such productions
do incur a runtime cost.
> I consider "adjusted" to be a clearer description of the compile-time
> operation being described. It would also be consistent with the
> use of "adjusted" in 6.7.6.3, describing the transformation of
> array parameters to pointer parameters.
To me "adjusted" seems a little off because it suggests that
there is something that is being mutated, which isn't really the
case here. I agree that array conversions have a different
character than other conversions, but right now I don't know
a better word than conversion.
The point about "adjusted" in 6.7.6.3 hadn't occurred to me, and
now that it does I count it as a strike against using "adjusted"
for array conversions. The two cases are just not the same, and
so they shouldn't use the same word.
> It's not a huge deal, and the current usage is within a reasonable
> interpretation of the English word "converted", but I find the
> suggestion to use the word "adjusted" useful in understanding what's
> really going on.
I'm sympathetic to what you're trying to do. I still would like
to find a better phrasing than using "adjusted".
>>> I believe that an array member of a function call of struct type is the
>>> *only* case where it's possible to have an array expression that's not
>>> an lvalue in C90. [...]
>>
>> Do you? I count three others. Didn't we talk about this before?
>> I seem to recall that we did, but then I don't always remember when
>> I might have forgotten something.
>
> We may have, but I don't remember. What are the other cases?
The other cases where a struct (or union) type is produced as a
value but not an lvalue:
conditional expression with struct-valued choices
assignment expression of struct value
comma expression with a struct value on the RHS
(Obviously we then need to select a member of the struct/union
which has array type.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-19 10:58 -0800 |
| Message-ID | <kfnlgt2vwgl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104184 |
BartC <bc@freeuk.com> writes:
> On 19/02/2017 03:20, Keith Thompson wrote:
>
>> struct {int a, C[10];} S;
>> sizeof S.C
>>
>> is actually quite straightforward. `S.C` is an expression of
>> array type. Since that expression is the operand of `sizeof`, it
>> is not converted to a pointer expression. (`C` by itself is not an
>> expression at all.)
>
> Given:
>
> int A[10], B[10], C[10], D[10][6], x,i,j;
>
> aren't (A,B,C) and (x?B?C) and D[i] expressions of array type too?
>
> All, including S.C, can have [j] appended, and effect in all cases is
> to index what had been declared as an actual array.
I think this is easy to understand if looked at the right way.
In high-level pseudo-code we might say this:
1. Start with the parse tree of a whole expression. We will
walk the parse tree recursively.
2. When the tree, or subtree, is an operator, recursively
find the types of each operand, without doing any array
to pointer conversion. Then, unless the operator is
sizeof or _Alignof or &, convert any operand that has
an array type to a pointer to its first element. The
type returned is the "yield" type of the operator (and
array types remain array types). (Here it is worth
remembering that the right operand of '.' or '->' is
a member name, and does not have a type as such.)
3. When a subtree is a primary expression, the type returned
is the type of the expression (and array types remain
array types). See also the next rule for when a primary
expression is at the top of the parse tree.
4. When the topmost level of an expression is a primary
expression, and it has array type, the array is
converted to a pointer in the usual way, except in
the case of a string literal being used as an initializer
for a character array.
I kind of rushed through this, so I may have missed a corner case
or two, but if so I am confident others will correct me. :)
Does this let you answer all your questions?
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-02-19 09:06 +0000 |
| Message-ID | <slrn3vfsoaio3m.90l.ike@iceland.freeshell.org> |
| In reply to | #104160 |
On 2017-02-18, BartC <bc@freeuk.com> wrote:
> sizeof x?B:C B,C both converted to pointers
The sizeof operator takes a unary-expression as its operand, so
the expression above is interpreted as:
(sizeof x) ? B : C
Is that what you intended, or did you mean
sizeof (x ? B : C)
?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-19 10:53 +0000 |
| Message-ID | <o8btbk$7ji$1@dont-email.me> |
| In reply to | #104177 |
On 19/02/2017 09:06, Ike Naar wrote: > On 2017-02-18, BartC <bc@freeuk.com> wrote: >> sizeof x?B:C B,C both converted to pointers > > The sizeof operator takes a unary-expression as its operand, so > the expression above is interpreted as: > > (sizeof x) ? B : C > > Is that what you intended, or did you mean > > sizeof (x ? B : C) > > ? > The latter. (My actual code always has ?: with parentheses, but it seems to be fashionable to leave them off.)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-19 09:06 -0500 |
| Message-ID | <o8c8lb$fv7$1@jstuckle.eternal-september.org> |
| In reply to | #104177 |
On 2/19/2017 4:06 AM, Ike Naar wrote: > On 2017-02-18, BartC <bc@freeuk.com> wrote: >> sizeof x?B:C B,C both converted to pointers > > The sizeof operator takes a unary-expression as its operand, so > the expression above is interpreted as: > > (sizeof x) ? B : C > > Is that what you intended, or did you mean > > sizeof (x ? B : C) > > ? > You are correct, but not for the reason you stated. x ? B : C returns a single value, so sizeof (x ? B : C) is valid. However, unary operators such as sizeof have a higher precedence than the ternary operator, so sizeof is evaluated before ?:. -- ================== 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-19 16:25 +0000 |
| Message-ID | <87mvdib11n.fsf@bsb.me.uk> |
| In reply to | #104190 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> On 2/19/2017 4:06 AM, Ike Naar wrote:
>> On 2017-02-18, BartC <bc@freeuk.com> wrote:
>>> sizeof x?B:C B,C both converted to pointers
>>
>> The sizeof operator takes a unary-expression as its operand, so
>> the expression above is interpreted as:
>>
>> (sizeof x) ? B : C
>>
>> Is that what you intended, or did you mean
>>
>> sizeof (x ? B : C)
>>
>> ?
>
> You are correct, but not for the reason you stated. x ? B : C returns a
> single value, so sizeof (x ? B : C) is valid.
>
> However, unary operators such as sizeof have a higher precedence than
> the ternary operator, so sizeof is evaluated before ?:.
Ike Naar is correct (the hyphen is a clue). C's expressions are defined
in terms of a grammar and, as stated,
unary-expression:
postfix-expression
++ unary-expression
-- unary-expression
unary-operator cast-expression
sizeof unary-expression
sizeof ( type-name )
_Alignof ( type-name )
You can, of course, re-phrase the grammar in terms of precedence and
associative, but that does not mean that the original explanation was
wrong.
(There's a small error in your explanation in that you conflate higher
precedence with evaluation order.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-02-19 11:42 -0500 |
| Message-ID | <o8chq3$gr2$1@jstuckle.eternal-september.org> |
| In reply to | #104203 |
On 2/19/2017 11:25 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 2/19/2017 4:06 AM, Ike Naar wrote: >>> On 2017-02-18, BartC <bc@freeuk.com> wrote: >>>> sizeof x?B:C B,C both converted to pointers >>> >>> The sizeof operator takes a unary-expression as its operand, so >>> the expression above is interpreted as: >>> >>> (sizeof x) ? B : C >>> >>> Is that what you intended, or did you mean >>> >>> sizeof (x ? B : C) >>> >>> ? >> >> You are correct, but not for the reason you stated. x ? B : C returns a >> single value, so sizeof (x ? B : C) is valid. >> >> However, unary operators such as sizeof have a higher precedence than >> the ternary operator, so sizeof is evaluated before ?:. > > Ike Naar is correct (the hyphen is a clue). C's expressions are defined > in terms of a grammar and, as stated, > > unary-expression: > postfix-expression > ++ unary-expression > -- unary-expression > unary-operator cast-expression > sizeof unary-expression > sizeof ( type-name ) > _Alignof ( type-name ) > > You can, of course, re-phrase the grammar in terms of precedence and > associative, but that does not mean that the original explanation was > wrong. > > (There's a small error in your explanation in that you conflate higher > precedence with evaluation order.) > Nope. Every operation is based on precedence and associativity. x?B:C is an expression which returns a unary result, which is why sizeof(x?B:C) works. However, in the absence of parens, there are two operators - the uniary sizeof and ternary ?:. Precedence rules require the unary operator be evaluated before the ternary operator. -- ================== 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-19 17:45 +0000 |
| Message-ID | <o8clgp$usr$1@dont-email.me> |
| In reply to | #104206 |
On 19/02/17 16:42, Jerry Stuckle wrote:
> On 2/19/2017 11:25 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 2/19/2017 4:06 AM, Ike Naar wrote:
>>>> On 2017-02-18, BartC <bc@freeuk.com> wrote:
>>>>> sizeof x?B:C B,C both converted to pointers
>>>>
>>>> The sizeof operator takes a unary-expression as its operand,
>>>> so the expression above is interpreted as:
>>>>
>>>> (sizeof x) ? B : C
>>>>
>>>> Is that what you intended, or did you mean
>>>>
>>>> sizeof (x ? B : C)
>>>>
>>>> ?
>>>
>>> You are correct, but not for the reason you stated. x ? B : C
>>> returns a single value, so sizeof (x ? B : C) is valid.
>>>
>>> However, unary operators such as sizeof have a higher precedence
>>> than the ternary operator, so sizeof is evaluated before ?:.
>>
>> Ike Naar is correct (the hyphen is a clue). C's expressions are
>> defined in terms of a grammar and, as stated,
>>
>> unary-expression: postfix-expression ++ unary-expression --
>> unary-expression unary-operator cast-expression sizeof
>> unary-expression sizeof ( type-name ) _Alignof ( type-name )
>>
>> You can, of course, re-phrase the grammar in terms of precedence
>> and associative, but that does not mean that the original
>> explanation was wrong.
>>
>> (There's a small error in your explanation in that you conflate
>> higher precedence with evaluation order.)
>>
>
> Nope. Every operation is based on precedence and associativity.
> x?B:C is an expression which returns a unary result, which is why
> sizeof(x?B:C) works.
>
> However, in the absence of parens, there are two operators - the
> uniary sizeof and ternary ?:. Precedence rules require the unary
> operator be evaluated before the ternary operator.
You are making the same mistake again. Precedence determines which
operators operate on which operands. Evaluation order in C is, for the
most part, unspecified. The only guarantee you get about evaluation
order is that all evaluations after a given sequence point will be
complete (or, at least, as complete as necessary) by the next sequence
point.
Take, for example, the following code:
#include <stdio.h>
int calc_A(void)
{
printf("A\n");
return 1;
}
int calc_B(void)
{
printf("B\n");
return 2;
}
int calc_C(void)
{
printf("C\n");
return 3;
}
int main(void)
{
int x = calc_A() + calc_B() * calc_C();
printf("%d\n", x);
return 0;
}
Now, *precedence* requires that the result of calc_B() be multiplied by
the result of calc_C(), and the product should then be added to the
result of calc_A() --- thus 2 * 3 = 6, + 1 = 7. So main() *must* print 7
--- there is no choice about that.
But, if you were correct to associate precedence with evaluation order,
we would expect to see one of the following outputs:
B
C
A
7
or possibly
C
B
A
7
And yet, when I run this on my own system, I get:
A
B
C
7
This shows that calc_A() is being evaluated *first*.
I deduce that one of two conclusions pertains:
a) gcc is non-conforming in this regard (and gcc is such a widely-used
compiler that it would mean it would not be safe in practice to rely on
this 'rule' of C that precedence determines evaluation order; OR
b) there is no such rule.
The Standard's description of evaluation order has been massively
complicated by the inclusion of threads. It used to say that "the order
of evaluation of subexpressions and the order in which side effects take
place are both unspecified", which is certainly enough to prove my point
for C90. But even in C11 we find in 5.1.2.3:
/Sequenced before/ is an asymmetric, transitive, pair-wise relation
between evaluations executed by a single thread, which induces a partial
order among those evaluations. Given any two evaluations A and B, if A
is sequenced before B, then the execution of A shall precede the
execution of B. (Conversely, if A is sequenced before B, then B is
/sequenced after/ A.) If A is not sequenced before or after B, then A
and B are /unsequenced/. Evaluations A and B are /indeterminately
sequenced/ when A is sequenced either before or after B, but it is
unspecified which. 13) The presence of a /sequence point/ between the
evaluation of expressions A and B implies that every value computation
and side effect associated with A is sequenced before every value
computation and side effect associated with B.
(I have added /italics/ to correspond with the italics in the Standard,
which indicate that a term is being defined.)
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-23 11:57 -0800 |
| Message-ID | <kfnefyovfwn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104212 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 19/02/17 16:42, Jerry Stuckle wrote:
>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 2/19/2017 4:06 AM, Ike Naar wrote:
>>>>> On 2017-02-18, BartC <bc@freeuk.com> wrote:
>>>>>> sizeof x?B:C B,C both converted to pointers
>>>>>
>>>>> The sizeof operator takes a unary-expression as its operand,
>>>>> so the expression above is interpreted as:
>>>>>
>>>>> (sizeof x) ? B : C
>>>>>
>>>>> Is that what you intended, or did you mean
>>>>>
>>>>> sizeof (x ? B : C)
>>>>>
>>>>> ?
>>>>
>>>> You are correct, but not for the reason you stated. x ? B : C
>>>> returns a single value, so sizeof (x ? B : C) is valid.
>>>>
>>>> However, unary operators such as sizeof have a higher precedence
>>>> than the ternary operator, so sizeof is evaluated before ?:.
>>>
>>> Ike Naar is correct (the hyphen is a clue). C's expressions are
>>> defined in terms of a grammar and, as stated,
>>>
>>> unary-expression: postfix-expression ++ unary-expression --
>>> unary-expression unary-operator cast-expression sizeof
>>> unary-expression sizeof ( type-name ) _Alignof ( type-name )
>>>
>>> You can, of course, re-phrase the grammar in terms of precedence
>>> and associative, but that does not mean that the original
>>> explanation was wrong.
>>>
>>> (There's a small error in your explanation in that you conflate
>>> higher precedence with evaluation order.)
>>
>> Nope. Every operation is based on precedence and associativity.
>> x?B:C is an expression which returns a unary result, which is why
>> sizeof(x?B:C) works.
>>
>> However, in the absence of parens, there are two operators - the
>> uniary sizeof and ternary ?:. Precedence rules require the unary
>> operator be evaluated before the ternary operator.
>
> You are making the same mistake again. Precedence determines
> which operators operate on which operands. Evaluation order in C
> is, for the most part, unspecified. The only guarantee you get
> about evaluation order is that all evaluations after a given
> sequence point will be complete (or, at least, as complete as
> necessary) by the next sequence point. [...]
Many aspects of evaluation order in C are indeed unspecified.
However, the guarantees about sequence points are not the only
guarantees given with regard to sequencing. Take the example
expression
(a + b) * c
The operands of * are (a+b) and c. The C11 standard requires
the value computations of these two operands to be sequenced
before the multiply operation of *. Since (a+b) has only value
computations, and no side effects, that expression must be
completely evaluated before the multiply operation begins.
In this example expression that rule may seem like a moot point,
but in other cases the difference can matter. A well-known
example is
a[ a[0] ] = 3;
Here it is important that the value of a[0], and which index of
the array 'a' to store in, must be determined before the
assignment operation (=) starts. Before C11 there was extensive
debate about whether this assignment had undefined behavior (by
which I mean whether it might have undefined behavior if a[0]
were zero). There are some sequencing constraints that affect
evaluation order beyond those given by the sequence point rules.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-23 21:27 +0000 |
| Message-ID | <o8nk08$uf9$1@dont-email.me> |
| In reply to | #104517 |
On 23/02/17 19:57, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 19/02/17 16:42, Jerry Stuckle wrote: >>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 2/19/2017 4:06 AM, Ike Naar wrote: >>>>>> On 2017-02-18, BartC <bc@freeuk.com> wrote: >>>>>>> sizeof x?B:C B,C both converted to pointers >>>>>> >>>>>> The sizeof operator takes a unary-expression as its operand, >>>>>> so the expression above is interpreted as: >>>>>> >>>>>> (sizeof x) ? B : C >>>>>> >>>>>> Is that what you intended, or did you mean >>>>>> >>>>>> sizeof (x ? B : C) >>>>>> >>>>>> ? >>>>> >>>>> You are correct, but not for the reason you stated. x ? B : C >>>>> returns a single value, so sizeof (x ? B : C) is valid. >>>>> >>>>> However, unary operators such as sizeof have a higher precedence >>>>> than the ternary operator, so sizeof is evaluated before ?:. >>>> >>>> Ike Naar is correct (the hyphen is a clue). C's expressions are >>>> defined in terms of a grammar and, as stated, >>>> >>>> unary-expression: postfix-expression ++ unary-expression -- >>>> unary-expression unary-operator cast-expression sizeof >>>> unary-expression sizeof ( type-name ) _Alignof ( type-name ) >>>> >>>> You can, of course, re-phrase the grammar in terms of precedence >>>> and associative, but that does not mean that the original >>>> explanation was wrong. >>>> >>>> (There's a small error in your explanation in that you conflate >>>> higher precedence with evaluation order.) >>> >>> Nope. Every operation is based on precedence and associativity. >>> x?B:C is an expression which returns a unary result, which is why >>> sizeof(x?B:C) works. >>> >>> However, in the absence of parens, there are two operators - the >>> uniary sizeof and ternary ?:. Precedence rules require the unary >>> operator be evaluated before the ternary operator. >> >> You are making the same mistake again. Precedence determines >> which operators operate on which operands. Evaluation order in C >> is, for the most part, unspecified. The only guarantee you get >> about evaluation order is that all evaluations after a given >> sequence point will be complete (or, at least, as complete as >> necessary) by the next sequence point. [...] > > Many aspects of evaluation order in C are indeed unspecified. > However, the guarantees about sequence points are not the only > guarantees given with regard to sequencing. Take the example > expression > > (a + b) * c > > The operands of * are (a+b) and c. The C11 standard requires > the value computations of these two operands to be sequenced > before the multiply operation of *. Yes, but you may be missing the point. The Standard doesn't (as far as I am aware) require (a + b) to be evaluated before /c/ is evaluated. Consider the substitution of a, b, and c with functions fa(), fb() and fc() that return a, b, and c respectively, but which printf a, b, or c respectively before returning. As far as I can tell, any of these outputs: abc acb bac bca cab cba would be permissible. > Since (a+b) has only value > computations, and no side effects, that expression must be > completely evaluated before the multiply operation begins. Yes, but not before /c/ is evaluated. Jerry Stuckle is confusing evaluation order and precedence, and I was attempting to unconfuse him. You seem to be trying to reconfuse him! :-) Obviously one must (usually) evaluate operands before attempting to apply an operator to them, but there is no constraint on the order in which those operands are evaluated. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-25 05:03 -0800 |
| Message-ID | <kfn60jys9qg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104532 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 23/02/17 19:57, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 19/02/17 16:42, Jerry Stuckle wrote:
>>>> On 2/19/2017 11:25 AM, Ben Bacarisse wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>>
>>>>>> On 2/19/2017 4:06 AM, Ike Naar wrote:
>>>>>>> On 2017-02-18, BartC <bc@freeuk.com> wrote:
>>>>>>>> sizeof x?B:C B,C both converted to pointers
>>>>>>>
>>>>>>> The sizeof operator takes a unary-expression as its operand,
>>>>>>> so the expression above is interpreted as:
>>>>>>>
>>>>>>> (sizeof x) ? B : C
>>>>>>>
>>>>>>> Is that what you intended, or did you mean
>>>>>>>
>>>>>>> sizeof (x ? B : C)
>>>>>>>
>>>>>>> ?
>>>>>>
>>>>>> You are correct, but not for the reason you stated. x ? B : C
>>>>>> returns a single value, so sizeof (x ? B : C) is valid.
>>>>>>
>>>>>> However, unary operators such as sizeof have a higher precedence
>>>>>> than the ternary operator, so sizeof is evaluated before ?:.
>>>>>
>>>>> Ike Naar is correct (the hyphen is a clue). C's expressions are
>>>>> defined in terms of a grammar and, as stated,
>>>>>
>>>>> unary-expression: postfix-expression ++ unary-expression --
>>>>> unary-expression unary-operator cast-expression sizeof
>>>>> unary-expression sizeof ( type-name ) _Alignof ( type-name )
>>>>>
>>>>> You can, of course, re-phrase the grammar in terms of precedence
>>>>> and associative, but that does not mean that the original
>>>>> explanation was wrong.
>>>>>
>>>>> (There's a small error in your explanation in that you conflate
>>>>> higher precedence with evaluation order.)
>>>>
>>>> Nope. Every operation is based on precedence and associativity.
>>>> x?B:C is an expression which returns a unary result, which is why
>>>> sizeof(x?B:C) works.
>>>>
>>>> However, in the absence of parens, there are two operators - the
>>>> uniary sizeof and ternary ?:. Precedence rules require the unary
>>>> operator be evaluated before the ternary operator.
>>>
>>> You are making the same mistake again. Precedence determines
>>> which operators operate on which operands. Evaluation order in C
>>> is, for the most part, unspecified. The only guarantee you get
>>> about evaluation order is that all evaluations after a given
>>> sequence point will be complete (or, at least, as complete as
>>> necessary) by the next sequence point. [...]
>>
>> Many aspects of evaluation order in C are indeed unspecified.
>> However, the guarantees about sequence points are not the only
>> guarantees given with regard to sequencing. Take the example
>> expression
>>
>> (a + b) * c
>>
>> The operands of * are (a+b) and c. The C11 standard requires
>> the value computations of these two operands to be sequenced
>> before the multiply operation of *.
>
> Yes, but you may be missing the point. [..example(s) where
> operand evaluation order has some leeway..]
I understood the point you were making. My intention was only to
identify a small inaccuracy in your description regarding
sequencing guarantees. Your basic point is correct and well
worth making, and I didn't mean to imply otherwise.
>> Since (a+b) has only value
>> computations, and no side effects, that expression must be
>> completely evaluated before the multiply operation begins.
>
> Yes, but not before /c/ is evaluated. Jerry Stuckle is confusing
> evaluation order and precedence, and I was attempting to unconfuse
> him. You seem to be trying to reconfuse him! :-)
Certainly I did not mean to do that. But there is another
problem here. Some of what Jerry has said is right, and I think
that may have been missed. I don't want to get into a "who is
right" argument (not now, and pretty much not ever), so instead
I tried to focus on what precisely the Standard's rules are. Not
quite as successfully as I would have liked, unfortunately. :(
> Obviously one must (usually) evaluate operands before attempting to
> apply an operator to them, but there is no constraint on the order in
> which those operands are evaluated.
In fact, in some cases there are (and of course you meant to
exclude operators like && or ?: that impose sequence points, and
so do I). Suppose there is a global variable g and a function
f() that both reads and writes g. The expression
g++ + f()
might look like it has undefined behavior, but actually it
doesn't. The reason is function calls are special: the ++
operation on g may be done entirely _before_ f() runs, or it may
be done entirely _after_ f() runs, but it cannot be done during
the time that f() is running. Compare that expression to this
one:
g++ + (g *= 10)
The second expression is analogous to the first, except that the
first takes advantage of the specialness of function calls, and
the second does not. The second case is undefined behavior.
However, if we take the (g *= 10) and put it inside a function
void f(){ g *= 10; }
the function can be used to avoid undefined behavior:
g++ + f()
What this gives us is unspecified behavior, but not undefined
behavior. Function calls are "indeterminately sequenced", in the
parlance of the Standard, unlike other forms of expression which,
like you say, do not offer any sequencing guarantees relating
the two operand expressions.
The key point is that the Standard does impose /some/ constraints
on evaluation order beyond those deriving from sequence points.
It's important not to forget those, even if some of them may seem
obvious. I find the phrasing used in C11 to be the most helpful
of the several versions of the Standard, ie, with regard to
answering questions regarding evaluation order. So I recommend
looking there, for anyone who is interested.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-23 13:39 -0800 |
| Message-ID | <acdede98-215d-4d00-9df1-27a9fac87f99@googlegroups.com> |
| In reply to | #104517 |
On Thursday, February 23, 2017 at 1:57:52 PM UTC-6, Tim Rentsch wrote:
> The operands of * are (a+b) and c. The C11 standard requires
> the value computations of these two operands to be sequenced
> before the multiply operation of *. Since (a+b) has only value
> computations, and no side effects, that expression must be
> completely evaluated before the multiply operation begins.
In C, evaluation of a value expression is not an "action" as such. The
statement "d=(a+b)*c;" is required to store into d the value that would
be obtained by adding variables a and b and multiplying their sum by c.
A compiler may use any sequence of steps that would achieve that result.
If the types in question were unsigned, for example, or if hardware used
silent wraparound on overflow, a compiler could at its leisure replace
the expression with (a*c)+(b*c) which on some platforms would be faster.
Your later example with a[a[0]]++ is more interesting. A compiler wouldn't
be able to know what element to act upon without fetching a[0], but that
wouldn't imply that having fetched a[0] it would never need to do so again.
Changing the example slightly, given "uint8_t arr[2],*ptr" and changing the
statement to "arr[ptr[0]]++;", would the following be a legitimate
substitution?
uint8_t * FSR = ptr; // FSR is a CPU pointer-access register
// Remainder of code is four instructions on some processors
if (!(*FSR & 1))
arr[0]++;
if (*FSR & 1)
arr[1]++;
On some processors, it would be faster to evaluate the (*FSR & 1) condition
in each of two conditional-skip instructions than to evaluate it once and
latch the result.
I'd rather have a compiler that would treats the fetch of ptr[0] as
sequenced before the write to arr[ptr[0]] than one which would apply the
above "optimization". It's plausible, however, that some compilers may
apply such optimizations in the absence of any rule that would forbid them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-25 17:42 -0800 |
| Message-ID | <kfnk28dralx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #104535 |
supercat@casperkitty.com writes: > On Thursday, February 23, 2017 at 1:57:52 PM UTC-6, Tim Rentsch wrote: >> The operands of * are (a+b) and c. The C11 standard requires >> the value computations of these two operands to be sequenced >> before the multiply operation of *. Since (a+b) has only value >> computations, and no side effects, that expression must be >> completely evaluated before the multiply operation begins. > > In C, evaluation of a value expression is not an "action" as such. > The statement "d=(a+b)*c;" is required to store into d the value > that would be obtained by adding variables a and b and multiplying > their sum by c. A compiler may use any sequence of steps that > would [..further remarks in a similar vein..] Your comments and questions are about what goes on in an actual machine. My statements are concerned solely with what goes on in the abstract machine.
[toc] | [prev] | [next] | [standalone]
Page 12 of 27 — ← Prev page 1 … 10 11 [12] 13 14 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web